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 _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
