[Top][All Lists]
[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
Re: [Gnu-arch-users] Ongoing Comparison Between Version Control Systems, Andrew Suffield, 2003/09/07
Re: [Gnu-arch-users] Ongoing Comparison Between Version Control Systems,
Zack Brown <=
Re: [Gnu-arch-users] Ongoing Comparison Between Version Control Systems, Zack Brown, 2003/09/07
[Gnu-arch-users] Ongoing Comparison Between Version Control Systems, Mark A. Flacy, 2003/09/07