gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Zack Brown
Subject: Re: [Gnu-arch-users] Ongoing Comparison Between Version Control Systems
Date: Sun, 7 Sep 2003 08:59:52 -0700
User-agent: Mutt/1.5.4i

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.

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

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

* 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?"

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

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

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

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

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

Overall, very nice document.

Be well,
Zack

> 
> http://better-scm.berlios.de/comparison/comparison.html
> 
> The original XML and perl script that renders it, can be found here:
> 
> http://better-scm.berlios.de/comparison/
> 
> I am contacting you to make sure Arch is properly represented there. Note
> that there were some things I did not there, and possibly some
> incorrections.
> 
> Regards,
> 
>       Shlomi Fish
> 
> ----------------------------------------------------------------------
> 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
> 
> 
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnu-arch-users
> 
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/

-- 
Zack Brown




reply via email to

[Prev in Thread] Current Thread [Next in Thread]