|
Nkuvu has asked for the wisdom of the Perl Monks concerning the following question:
In response to the recent poll, I started wondering about different qualities of version control systems.
From my own experience, I can only really address Rational ClearCase. I've used ClearCase for a few years on projects at work (on Windows machines) and it has done just about everything that the company has wanted to do. Labels, version history, branches, and even protecting versions from checkout without a problem report number.
The syntax for finding a particular version can be rather complex1, although the command-line ClearTool provides a decent approach to writing Perl scripts to simplify the process. Some co-workers have written scripts that take two version labels and produce a list of every version of every file that changed between those versions.
It's possible that this is actually considered to be a failing of ClearCase -- perhaps other version control systems have built in tools to do these types of processes. But it's also possible that other version control systems do not provide command-line access to allow programmers to write tools to make up for any deficiencies.
In short, what makes a good version control system "good?" What are some of the things you look for when evaluating a new version control system?
1For a specific example of the cleartool syntax, I have a snippet from a script used to describe a ClearCase object:
## The following can be found from within the cleartool environment (t
+ype man fmt_ccase)
## %l = Labels - For versions, all attached labels; the null string ot
+herwise.
## %En = Element name
## %Sn = Short name
## %u = Login name of the user associated with the event.
## %Fu = Full name of the user.
## %a = All attached attributes.
my $command = qq/cleartool find $object -version "version(\\main\\LATE
+ST)" /;
$command .= qq/-exec "cleartool describe -fmt """%n %Fu %a %l\\n""" "
+"%CLEARCASE_XPN%"""/;
The formatting command is certainly not something I would want to write up every time, but in a script it's all quite simple.
Notes: I was originally thinking that this should go in Meditations, but tye pointed out that it's more of a question than a presentation of information. Also, jdporter reminded me to search for an existing node on the subject, but I didn't see anything relevant when searching for "version control" (and looked back through nodes to March 2006). Finally, this has been a subject that I've been pondering for a few days -- I decided to just write something up, even if I don't feel that it's very eloquent.
Added: An additional question. I've looked at the links from andreas1234567 and eyepopslikeamosquito (both links very helpful, thanks) and I'd like to know how many of these features are actually used. For instance, do you typically work with Signed Revisions? Symlinks? EOL conversions?
My own experience has been that these things are almost never encountered -- however I am basing this experience from one company's practices, on only a few different projects. We've never had to deal with EOL conversions because all systems are Windows. Nor have symlinks entered the picture. Even file renames are rare.
Do you run into the limits of your VCS often? |
Re: Evaluating version control systems
by andreas1234567 (Vicar) on May 22, 2008 at 19:12 UTC
|
There are probably as many opinions on this subject as there are people using it, but Wikipedia's comparison of revision control software is a start.
--
No matter how great and destructive your problems may seem now, remember, you've probably only seen the tip of them. [1]
| [reply] |
|
|
| [reply] |
Re: Evaluating version control systems
by dragonchild (Archbishop) on May 22, 2008 at 19:57 UTC
|
In the OSS community, you're generally going to hear the following suggested - svn (Subversion), svk, darcs, or git. CVS used to be the standard, but it sucked. For most OSS projects, all four are perfectly good. Very few Perl projects are in darcs, but that's probably just cultural. Git is the new kid on the block and several people I respect are starting to migrate, thus prompting me to consider the migration myself. But, I still use SVK over Subversion and it works just fine.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
Re: Evaluating version control systems
by samtregar (Abbot) on May 22, 2008 at 21:13 UTC
|
In short, what makes a good version control system "good?" What are some of the things you look for when evaluating a new version control system?
#1 for me is reliability. Version control is often my only backup and the code I store there is my most valuable product. I took a long time to switch from CVS to Subversion because I didn't want to deal with any instability in my version control.
Flexiblity is important - being able to add scripts that run when various events happen is very useful. I like to have a commit mailing-list, for example.
Speed is an attractive quality, particularly since I spend my days using Subversion on a very large codebase. I wish it was a lot faster.
I also like the idea of a distributed system like SVK. Unfortunately SVK failed hard for me and one time losing work was enough for me.
Frankly though, all this is icing on the cake. Using version control - any version control - is so much better than not using any that it doesn't make a lot of difference to me. I'd grumble a bit if I had to go back to CVS, but life would go on. Going without any version control though, now that's unthinkable!
-sam
| [reply] |
Re: Evaluating version control systems
by moritz (Cardinal) on May 22, 2008 at 18:59 UTC
|
In short, what makes a good version control system "good?"
The things that I (and others) stuff into it should come out in exactly the same way. Byte by byte, bit by bit. (SVN has some munging for newlines on different OS' - thinks like that are OK if they are optional. Likewise for ID strings.). Sadly quite many version control systems don't adhere to that rule.
The rest are rules that mostly apply to all other programs as well: they should be fast, use little other resources, are easy to understand, easy to use, modular to use, easy to integrate, flexible etc.
| [reply] |
Re: [OT] Evaluating version control systems
by Zadeh (Beadle) on May 22, 2008 at 22:10 UTC
|
I've used ClearCase for years as well as many others. Perforce being the other big commercial one. What I don't like about it are:
1) The high cost for licensing
2) The complexity involved - config-specs is a language in itself.
3) Difficulty in training employees to understand and use it properly.
4) Interoperability issues between remote sites.
One feature I can't find in any other VCS system is the build auditing CC does. With clearaudit, you can monitor any I/O that occurs while a program accesses ClearCase. We have automated builds that record every single file/version that goes into experimental builds and the product, for all time.
If we needed to apply a 1-line fix to a product released 5 years ago, we can do it in a couple clicks, compare against the last release and be assured nothing else changed.
The API provided by ClearCase is really extensive too, which I don't see as much in other VCS - Perforce being an exception. So now we've got tons of custom little tools all built around CC that'd make it difficult to switch.
At home I play around with SVN, Mercurial, Git etc. What I really like about SVN is the 3rd party support it has. When I fire up different IDEs, typically they have built-in support for only a few VCSs: CVS, Perforce, ClearCase, and SVN. Can't say that for mercurial/git.
I see lots of people praising git but if I was going to use something like that I really prefer Mercurial over it by a longshot. Git is simply way too cumbersome to understand & use than mercurial which "just works" way more often. I shouldn't have to become an expert in VCS internals and waste my time banging in the right magic commands and switches just to do something that should be easy.
Recently spent some considerable time trying to figure out if we could switch away from ClearCase to something like SVN, Git or Mercurial and the conclusion was unfortunately 'no'. Ideally I'd really like a system that:
1) Had an extensive API
2) Had build auditing
3) Worked well on Windows as well as *nix (git fails here)
4) Had great easy-to-use GUIs so 'normal' people could actually use th
+e system to do most tasks.
5) Had some authentication/cryptographic guarantees built into the sys
+tem by design (git, mercurial do - nearly everything else doesn't)
6) Had an efficient way to work in a distributed way among disparate o
+ffices/developers
7) Had the ability to do renames and merges at a very granular level,
+while also retaining historical info.
8) Provided granular access privileges to parts of the system (some th
+ings must be secret - think gov't work)
9) Changes can be applied/reverted/rolled-back in a single transaction
+ (atomicity) if desired.
| [reply]
[d/l]
[select] |
Re: Evaluating version control systems
by EvanCarroll (Chaplain) on May 22, 2008 at 20:00 UTC
|
As far as I'm concerned everyone must know how to use svn because it is currently the standard. And, as far as productivity is concerned everyone should know how to use git. Other VCS just serve to tell you a little about the person that uses them. Bazaar: work at Canonical, CVS: you're enduring brain damage, Microsoft SourceSafe: you think of coding as a job. Etc,.
On a slightly more realistic note, other than ease of use, I can't see anything that git lacks in. -- Maybe some of the super archive support.
| [reply] |
Re: Evaluating version control systems
by starbolin (Hermit) on May 24, 2008 at 03:00 UTC
|
Nkuvu writes:
Symlinks? EOL conversions? ... Nor have symlinks entered the picture.
Yes, on *nix you need symlinks. Maybe on Windows they're not used cause they didn't have symlinks for a long time. EOL conversions would be useful if you have to sync code to outside sources.
s//----->\t/;$~="JAPH";s//\r<$~~/;{s|~$~-|-~$~|||s
|-$~~|$~~-|||s,<$~~,<~$~,,s,~$~>,$~~>,,
$|=1,select$,,$,,$,,1e-1;print;redo}
| [reply]
[d/l] |
|
|
