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

[Zack Brown]

On Sun, Sep 07, 2003 at 08:05:02PM +0300, Shlomi Fish wrote:
> 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).

You could just ask on their mailing lists like you did with tla.

> 
> 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.

Perforce is really fast, so you might want to add a "speed" category.
Speed has a big impact on a tool's ability to handle a large project.
tla, for instance, has the features to support truly vast arrays of
developers, but it doesn't yet have the speed to handle that situation.

> 
> > * 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.

This may have something to do with the way you phrase the questions, as
well.

> 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.

My point was that you should be more verbose. It doesn't take many more
words to assume that the reader knows very little about these things.

> > * 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.

Availability seems like a pretty big part of deployment to me. If I can just
do an 'apt-get install tla' and get a solid working system, that's easy. If
I can't, then I have to go get the sources, manage all the dependencies,
compile the beast, put all the generated files in their proper locations, make
provisions for upgrading, etc etc etc, and that's not nearly as easy. There
is also the possibility that I'll introduce bugs during setup, which Debian
or some other distribution would track among many users and possibly fix
before I'm even aware of the problem. Doing a local compile and install,
I'm on my own.

Be well,
Zack

-- 
Zack Brown