I recently listened to Randal Schwartz‘ (aka merlyn) and Leo Laporte‘s podcast interview with Junio Hamano, maintainer of the git version control system, on FLOSS weekly episode 19. Mr. Schwartz revealed that he is using git for his source code management, either directly (“anything I get to choose, I use git”), or as a front-end to CVS or Subversion through git’s interface layers (“they don’t know I’m using git”).
I was intrigued by some of the features of git, for instance the ability to track the child-parent relationship for every commit using cryptographic hashes.
I’ve been using CVS up until now, but the way it prevents moving and renaming files makes me want to consider alternatives. Until I heard the above podcast that alternative has been Subversion only.
The Perl projects I work on are neither very large nor distributed. Should I consider git as my future SCM for Perl projects? What are the Monks’ experience with using git in Perl projects?
Andreas brings up an interesting question: What should we use for Perl development. I replied to Andreas with:
Re: git for Perl projects?
by jfroebe on Sep 28, 2007 at 21:24 GMT-6
For the most part, it really doesn’t matter which version control system you use. Think about it.. for most open source or even commercial projects, you have a small number of developers that are active on the project. Usually in the single digits. The level of sophistication required of the version control system isn’t pretty high – checkout/checkin/comment/etc. It isn’t until you have a lot more developers, a very complex project, or some other thing. Using CVS, Subversion, GIT, rcs, or even SCCS will work fine for most projects.
GIT is just the revision control system flavor of the week for primarily the Linux kernel developers. If you want to use it, do so. If not, don’t worry about it. Use what feels comfortable to you.
hope this helps,
Jason L. Froebe
We use subversion a great deal but I don’t understand why there are people that refuse to use it. The TechRepublic article, Avoid these six common development mistakes, sheds a bit of light:
4. Failing to see the value in a version control system
Most developers are all-too-familiar with this scenario: You roll out a new version of a critical Web application, and your cell phone rings constantly the next morning with cries of site problems.
As long as you’re willing to admit that you may have made a mistake or two, a version control system can be your best friend in this situation. By using version control systems, such as CVS, IBM Rational ClearCase, or Microsoft Visual SourceSafe, you can easily revert to the previous version of the application and move it to production. This gives you time to locate the problems within the development environment while the production site is readily available. This beats frantically searching through production code to locate the problem.
In addition, a source control system allows concurrent development so different team members may work with the same code. When the developers check their changes into the system, the changes are merged together.
One reason why some developers don’t like version control systems is because it adds a layer to the development process, which means the submission and retrieval of code to and from the source control system can be slow. This extra waiting time can tax the patience of some developers.
Hmmm. It might be more of a matter of convenience for some developers not to use or learn how to use a revision control system. Looks like I’ll have to write a few wrappers to simplify it.
Remember my Sybase Replication Server: custom built RepAgents with Perl! post back last year? Well, not only am I the new maintainer, but I finally have it working in a test environment. It isn’t ready for a new release for Sybase::TdsServer and Sybase::RepAgent, yet, but expect one soon.
My main development environment for these two modules is:
- Windows XP SP2
- ActiveState Perl 5.8.8
- Sybase Workspace 1.7 (Eclipse based)
- EPIC Perl plugin
- Subclipse (subversion client)
I’m hoping to get out my first CPAN release to the perl testers within the next month or so. Why the delay? My wife and I are expecting family and friends to stay with us for the next few weeks. That’s a very good thing 🙂
If you try to add the subversion plugin Subclipse to Sybase’s Workspace version 1.6 or 1.7, you will receive the following error:
To work around this problem, you need to start Eclipse.exe directly, usually located in your %SYBASE%\Workspace\Eclipse directory. Go to Help -> Software Updates -> Find and Install -> Search for new features. Add the url (http://subclipse.tigris.org/update_1.0.x) and Name (subclipse). When you’re given the option to install, uncheck the “Show the latest version of a feature only”.
We need to use version 1.0.5 of subclipse because Sybase’s Workspace is running on top of the older Eclipse version 3.1 software. The newer subclipse requires Eclipse 3.2 or higher to work.
Uncheck “Subclipse 1.2.0” and check “Subclipse 1.0.5”.
Continue installing, ignore any warnings.
The other option, of course, is to install Eclipse 3.2x separately and point Workspace to it during the install of Workspace. That way we are able to use the current version of Eclipse. I have not tried this with the new Workspace 1.7 release yet. Sybase Workspace is hardcoded to work only with Eclipse 3.1.x releases. 🙁
This seems to only happen on Workspace 1.6 and 1.7 that was upgraded from 1.6. I’m investigating it some more.
UPDATE: Sybase is going to create a techdoc explaining this behavior. This is somewhat expected behavior because of the older 3.1x Eclipse version.
Mark Phippard, over at CollabNet, compiled a list of blog posts that are well worth the time to read. A snippet from his “Subversion blog posts to read” blog post:
Computing the Differences Between Tags by Mark Phippard
In this post I show the new svn diff –summarize command and how you can use it to get a list of files that changed between two repository locations.
Authz and Anon Authn Agony by Mike Pilato
In this post Mike explains a difficult problem you can run into when you want to provide anonymous access but also have private folders within the repository structure.
Multiple Subversion Repositories? by Guido Haarmans
This post touches on the issue of having multiple replicated repositories to support globally distributed development. More specifically, why you may not really need this with Subversion as you do with other tools I will not mention.
Subversion LDAP Authentication with Apache by Jeremy Whitlock
Jeremy gives a primer on how to configure Apache to authenticate users via an LDAP directory, such as Microsoft Active Directory.
How Subversion Conserves Disk Space by Guido Haarmans
This is a high-level overview of how the Subversion repository stores your data.
Mark is a well respected member of the Subversion community. You can read more about him on his blog.