[crossfire] crossfire source code control systems

[Alex Schultz]

Raphaël Quinet wrote:
> By "partial checkout", I mean the ability to check out only a part of a
> module.  For example, if you are not using your usual computer that has
> all the modules checked out and you just want to fix a bug in one map, it
> is possible to do a "cvs checkout crossfire-maps-bigworld/some/map".  Then
> you only transfer what you need, make the changes and commit them without
> having to check out the whole tree.
>   
Well, Mercurial currently does not support 'lightweight checkouts', and
you must pull the whole branch history (recently for fun I made an
extension for Mercurial for 'lightweight checkouts' however it only
supports making checkouts from local branches, and it will be a long
time till lightweight checkouts from remote locations could be
supported), as I noted on my table on the wiki. Darcs doesn't either.
Bzr supports lightweight checkouts, however it doesn't support partial
lightweight checkouts.
Also, none of them support partial local branches (don't know of any
that do), however Mercurial does have some plans for implementing that.

> By "partial update", I mean the ability to synchronize only the files that
> you want to update from the repository without having to update all files.
> For example, if I am in a hurry while traveling or if I do not want to
> spend too much time online, I can just go in my ~/cvs/crossfire directory
> and do a "cvs checkout Changelog" to update only that file.  Then I have
> a quick look at it and I can decide if I want to transfer anything else.
> Even if some files are part of an atomic commit, some systems allow you to
> synchronize only a subset of these files if you do not intend to work on
> the other ones.
>   
In terms of lightweight checkouts, which only bzr supports, it doesn't
support partial updates.
Other than that an update, with distributed SCMs is considered just
updating the working directory of a local branch (to get the latest
changes from somewhere, you do a pull, and to update the working
directory, do an update), which is a completely offline operation, so in
terms of speed, it doesn't make a significant difference.
> Partial checkouts and partial updates are more useful for those who want
> to limit the amount of data to be transfered.  I do not know if these
> features would be useful to all developers, but I use them rather often
> so I am curious to know if the systems proposed as alternatives to CVS
> are also able to do that.
Well, with the working practices of CVS, it is rather useful, however
the working practice of distributed SCMs makes it IMHO unnecessary. With
distributed SCMs, it is typical to keep a local "incoming" branch, which
is a perfectly clean clone of the mainline remote repository, as well as
an "outgoing" branch pulling changes from all of your local branches you
are working on, and then make a temporary local branch for each feature
you're working on. Making your incoming branch of the crossfire server
would take 77MB of bandwidth, however pulling changes from the mainline
to it in the future takes a matter of seconds. Making the other local
branches can just be done by cloning the incoming branch, an offline
operation which takes a mere 5 seconds on Mercurial for the crossfire
server tree. So really, local branching and distributed SCM practices
despite increasing the data stored locally, greatly decreases the
necessary bandwidth in the long run (a checkout of the crossfire server
takes 10-20 MB on CVS, not long before it exceeds the initial investment
of a incoming local branch on distributed systems), so really, the
usefulness of partial checkouts and updates is near zero IMHO.

Alex Schultz