Re: [Gnu-arch-users] Ongoing Comparison Between Version Control Systems

[Shlomi Fish]

On Sun, 7 Sep 2003, Zack Brown wrote:

> On Sun, Sep 07, 2003 at 05:53:26PM +0300, Shlomi Fish wrote:
> >
> > I started composing a comparison between several prominent and accessible
> > version control systems on a feature-by-feature basis. The comparison can
> > be found here:
>
> Looks great! Some comments:
>
> * darcs and opencm seem worthy of inclusion in your chart. Also
>   commercial products like perforce and others, since you already include BK.
>

I am looking for someone experienced in Darcs and OpenCM to fill in the
details on them. I for one, had little experience with either one. (I do
have Darcs installed and can play with it).

I suppose it would be worthwhile to mention Perforce and ClearCase as
well. From what I understood Perforce is pretty much a CVS-like system,
and so its inclusion may lower the SNR of the document. I have only heard
of ClearCase, and never experienced with it, so I'll need someone of more
expertise.

> * you often use slightly different wording to say the same thing. For 
> instance,
>   in the section on the ability to move files and directories, for most
>   of them you say "Yes. Renames are supported," but for BitKeeper you
>   only say "Yes. There is a possibility of moving a file to a different
>   location." So directory renames are not possible with BK? I suggest that
>   for each category, you either give a flat "yes", "no", or "yes but with
>   the following exceptions: etc".
>

Actually, someone else commented that saying just Yes or No is a bit
confusing because you don't know if you answer the question or the
opposite. But I'll try to use identical wording whenever possible. Thanks.

> * Some of your explanations are not so clear to novice users. For instance,
>   in the "atomic commits" section, you might say "Support for atomic commits
>   means that if an operation on the repository is interrupted in the middle,
>   the repository will not be left in an inconsistant state. Are the check-in
>   operations atomic?" This is slightly better than what you had, because
>   it puts the explanation at the front of the question, while you currently
>   put it at the end.
>
>   In the "File and Directories Copies" section, you could say, "Does
>   the version control system supports copying files or directories to a
>   different location at the repository level, while retaining the history?
>   This is different from the 'Files and Directories Moves or Renames'
>   section because in this case two versions of the same file are retained,
>   each with an identical history."
>

I don't understand you. I'm already saying that.

> * In the "Propagating Changes to Parent Repositories" section, it seems
>   like you don't need to specify that changes are propagating only to derived
>   repositories. You can just say, "Can the system propagate changes from
>   one repository to another?"
>

Thanks, applied.

> * In the "Documentation" section, you should say the arch documentation
>   is old and out of date. I imagine that will change one day, but it's the
>   truth now.
>

Done.

> * In the "Ease of Deployment" section, you say arch is "excellent" while
>   CVS is only "Good". I think CVS is probably the easiest to deploy, partly
>   because it is shipped standard on all decent operating systems.  If any of
>   them are going to have an ease of deployment rating of "excellent", it 
> should
>   be CVS. Arch is included in the unstable Debian, but Debian testing has an
>   older version with different features. I think that makes arch deployment
>   "good" at best, probably only "fair". I would personally categorize CVS as
>   "Excellent", Aegis and BK as "Good", and arch and svn as "Fair".
>

I'll think about it. The problem is that setting up Arch hosting only
involves allocating a remote filesystem space which is quite easy to do.
The client is very easy to install. Availability is a different matter.

> * The "Command Set" section is completely biased in favor of CVS, the
>   one tool all the rest were created to replace. If you want to have a command
>   set section, I'd suggest finding a different yardstick. The section as it
>   is punishes new ideas like distributed repositories. Why don't you compare
>   equivalencies in command sets? So for each significant command offered
>   by one tool, which of the other tools offer an equivalent command? That
>   will at least indicate which tools have more scope than others, and in
>   what particular areas.
>

The problem is that most existing developers are already used to CVS,
whose command set is ubiquitous and easy.

> * In the licensing section, for BitKeeper it may only be necessary to
>   say, "Proprietary, but may be used without charge by open source projects
>   under certain conditions." There's no need to go into details.
>

I disagree. It's important to note the problematics of the license because
it is problematic, and I don't want people deciding it is acceptable fo
ruse.

> * You may want to add another section somewhere, called "repository
>   format stability". In it, analyze how often repository formats change, what
>   problems can be expected by using old tools with new repos, and what the
>   recovery path is like.

This is a bit hard to define and anticipate. From example, the Subversion
repository format is subject to change, while its remote access protocol
is AFAIK, quite stable. Both of them are not guaranteed to remain the
same until version 1.0.

Also, will this trend continue in the future? Can anyone tell in advance?

> You could also add a "command set (or API) stability"
>   section, mapping how often user wrapper-scripts are likely to break.
>

Again, it's hard to anticipate changes in this.

> Overall, very nice document.

Thanks.

Regards,

        Shlomi Fish

>
> Be well,
> Zack
>



----------------------------------------------------------------------
Shlomi Fish        address@hidden
Home Page:         http://t2.technion.ac.il/~shlomif/

An apple a day will keep a doctor away. Two apples a day will keep two
doctors away.

        Falk Fish