[crossfire] crossfire source code control systems

[Alex Schultz]

Lalo Martins wrote:
> - Poor support for file renaming and moving; this mean merging my pupland
> work wouldn't be any bit less painful on hg than cvs.  Can't be solved by
> extensions.
>   
Well, it would remember the history, which is a step up from cvs, but
indeed it doesn't deal with merging nicely with that. Also in theory,
could be solved by an extension, because despite merges not following
renames, it does track them, and an extension could be written to look
at all renamed files, and pull/merge changes from the original files in
another repository, not a nice solution, but could be done as an
extension in theory.

> - Uses three-way merge, as opposed to bzr's weave merge ("codeville"
> style merge).  This means we'd spend more time resolving merges manually. 
> Can't be solved by extensions (it seems).
>   
I'm not certain, but I'm betting it would be possible to write an
extension for a "codeville" style merge. Manually resolving merges is
rather easy IMHO though when using a nice tool such as meld which works
well with hg.

> - Local branches don't share storage.  Since hg best practises encourage
> you to keep many branches around, that means you'll soon have a few
> gigabytes of arches and maps storage lying around.  Can't be solved by
> extensions (it seems).
>   
Actually from what I have heard, hg uses hardlinks to save disk space on
local branches where available, haven't verified this myself. (It even
apparently supports using hardlinks on windows if the windows system is
using ntfs). I think the hardlinking is what makes a "hg clone" localy,
take 5 seconds, as opposed the "hg init && hg pull" locally taking a
minute. (See http://wiki.metalforge.net/doku.php/user:rednaxela:scms for
my timing of those two methods of locally coping in hg)


Alex Schultz