[crossfire] crossfire source code control systems

[Alex Schultz]

Lalo Martins wrote:
> On Sat, 12 Aug 2006 18:59:55 +0800, Lalo Martins wrote:
>   
>> On Sat, 12 Aug 2006 03:13:14 -0600, Alex Schultz wrote:
>>     
>>> I know bzr used to be really slow but apparently has been improved alot,
>>> however I have heard it is not bandwidth efficent still.
>>>       
>> They released 0.9 which is supposedly much faster yesterday.  I've yet to
>> try it out... I'll let you know what I find when I do :-)
>>     
>
> lalo:~SRC/crossfire>  time bzr get http://bazaar.launchpad.net/~vcs-imports/crossfire-server/main server-launchpad
> Branched 2690 revision(s).
> bzr get http://bazaar.launchpad.net/~vcs-imports/crossfire-server/main   73.19s user 12.43s system 1% cpu 1:59:20.98 total
>
> guess it's not quite there yet.
I just did some benchmarks on Mercurial and bzr (thinking about also
benchmarking some others at some point perhaps) and the results are here:
http://wiki.metalforge.net/doku.php/user:rednaxela:scms
In terms of performance and such, Mercurial is a little better, of
course, the time difference between the two is not very significant in
practical usage *except* that bzr is very slow pulling repositories over
http, because it establishes separate connections many many times and
when going over the internet spends much time establishing connections
and doing the dns lookups, which is why the time Lalo points out is so
large, and since local branches are so commonly used on distributed
systems I think that matters alot and is a strong point against bzr on
trees with large histories (like crossfire).

Mercurial however doesn't have the ability to get a "checkout" in a
traditional CVS manner, it has no way of downloading a working directory
without the history, except if the server is set up to generate
downloadable tarballs, and that still doesn't allow changes to be
directly "checked in" from such working directories. That is largely
because people most people would use it anyways, uses local branches,
which IMHO are much nicer to develop on than a checkout. That said, if
we do choose to move to mercurial, it would be a fairly trivial task for
me to make a robust wrapper script for mercurial to allow
checkout/checkin style development over mercurial ssh, so if we do go
with mercurial and anyone wishes for that, I could make such a script.

Btw, one thing I'd like to mention, is the way that Mercurial/bzr (and
many/most distributed SCMs) keep track of merging branches. Revisions
get cryptographic IDs that should be unique regardless of which branch
they are in and will be preserved when merging into a different branch
however revision numbers would be different, that allows one to find
where the same revisions are in different branches. Also, revisions keep
track of their parent revision, so when branches diverge and one is
merged into another, it would keep track of the point at which diverge
and where they merge back again, which is good for history and also
makes the merge work nicely.

One note on using such systems with the crossfire branch, I believe it
would be best to make any changes that are wanted in both branches, on
the stable branch first, because they one can just merge the stable
branch into the 2.0 branch, and it will account for where they diverged,
where they merged, however one would need to manually deal with conflict
resolution, however many SCMs can use external tools (i.e. meld) to make
conflict resolution easier and really, dealing with conflict resolution
shouldn't be harder than manually porting the changes to 2.0. That model
would also ensure that all fixes in the stable branch are not forgotten
in the 2.0 branch because the merge would merge what it can and allow
the user to resolve conflicts fairly easily.

Currently I'm not advocating any specific SCM (however the more I look
at distributed SCMs the more I like their branching methods), so just
mentioning what I see as the biggest issues with bzr, with Mercurial, as
well as explaining a little about how distributed systems such as them
deal with branching.

Alex Schultz