[crossfire] crossfire source code control systems

[Raphaël Quinet]

On Mon, 14 Aug 2006 15:19:22 -0600, Alex Schultz <alex_sch at telus.net> wrote:
> Ok, I just made up a table of the criteria that Mark listed, and a
> couple others, for CVS, SVN, Mercurial, Bzr, and Darcs (anyone want any
> others on the table?). If anyone has any revisions or wants to add any
> other SCMs feel free to make them.
> Currently storing it in my namespace on the wiki at:
> http://wiki.metalforge.net/doku.php/user:rednaxela:scmtable
> Make sure to read the numerous footnotes when looking at the table.

I think that the rename support should be in the "top features".  This
is one of the weak points of CVS and (from my point of view) would be
the main reason to look at something else.

Being able to move files and directories around while preserving their
full revision history could be important for the maps.  For example,
if the kandora maps are moved out of the "unliked" directory, their
revision history would be lost.  This is even more important for
bigger changes such as re-organizing the mlab maps.  The only way to
do it with CVS (if you do not play tricks with the repository) is to
delete and re-create all files, which generates very large diffs and
causes problems with the revision history.

One thing that could be added in the "nice to have" list is the
support for migrating local branches to another repository.  This
would only apply to the systems that support local branches.  So the
choices could be "Easy", "Hard" or "Not applicable".  Or maybe just
"Yes", "No", "N/A".  As I mentioned in my previous message, local
branches could cause some availability problems.  So if a system
supports local branches, it would be interesting to know whether it is
easy or hard to move these branches to a different place (which could
be the central server or some other server used as failover).  I would
consider that a system does not support relocating local branches if
it is necessary to do a full archive of the repository and then
extract it in the new location.  I would also consider it insufficient
if the main way to move a local branch requires a merge with the main
branch and/or only preserves the last entry in the revision history.
Good support for relocating local branches would be offered if the
system allows anybody (not just the owner of that branch) to extract
all information about that branch (including the history of all
changes) and create an exact copy of that branch on another server.

-Raphaël