Comparision of Git & Bzr [was Re: Short HOWTO on using git for Samba
Gerald (Jerry) Carter
jerry at samba.org
Mon Jun 25 21:25:10 GMT 2007
-----BEGIN PGP SIGNED MESSAGE-----
Jelmer Vernooij wrote:
> Mercurial doesn't have anything as complete as bzr-svn yet.
That puts Mercurial out of the running for me. I don't
really want to do the same diff/patch mirror script like
I did for bzr to maintain branch history.
> Bazaar and Mercurial are very different from Git in that
> they use strings (revision ids / file ids) to define the
> identity of revisions and files (and their history). Git
> defines a tree or files' identity by just a hash of
> their contents (excluding their history).
> However, this model also has the disadvantage that
> git isn't able to store rename information. All it has is
> a best guess as to which file was renamed to which
> based on the contents of those files - and this can have
> consequences for merges. Other disadvantages are
> disambiguouty over the history of a tree and slow
> (and non-ambiguous?) performance of annotation.
I think I can live with this based on the reasoning at
"Why does git not track renames?"
Git has to interoperate with a lot of different
workflows, for example some changes can come from
patches, where rename information may not be
available. Relying on explicit rename tracking
makes it impossible to merge two trees that have
done exactly the same thing, except one did it as
a patch (create/delete) and one did it using
some other heuristic.
But if anyone hasn't read Mark Shuttleworth's blog
on the different in design choice, you probably should:
Although I think Mark's estimation on performance
based on number of files is probably less important than
the number of commits. It's the Samba history that
seems to be bogging down Samba bzr trees across a network.
I agree that local performance is generally acceptable.
I'll have to play more with renames to fully convince
myself that I'm ok with git's approach.
> I really think Bazaar has the best approach of the
> various DVCS systems. They are also the (only?) one that
> focussed on correctness of model first rather than speed
> and that's really breaking them up at the moment.
Other than tracking renames, what else do you mean by
"correctness". I haven't followed all the DSCM bake-offs
> For the last half year I've used Bazaar for my Samba
> code, but while local performance has improved it's really,
> really slow to push across the full history of Samba over the
> wire all the time. Until lazy repositories/history horizons
> (being able to push/pull a tree without its history) land,
> I'll go back to Subversion for my Samba code.
I truly like bzr as a project. I do however, find the
branch checkouts in git much more intuitive and having
all branches in < 100M is a huge deal for me. I haven't
played with bzr's smart server to compare it with the
git-daemon but the latter seems pretty snappy.
Both projects have the necessary branch, merge, and tag
features we need. The lack of Win32 support in git is
not an issue for me. Maybe someone else cares about that
The things I like about git are:
* git-svnimport and git-svn (for now)
* fast-forwards and rebasing branches
* disk and RAM footprint
Questions about bzr are
* Will svn2bzr.py actually work on the Samba sv repo now ?
* What would the resulting size be?
* What is the status of bzr repositories and cheap branching?
> P.S. I'm a VCS n00b, please point out errors.
Me too :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the samba-technical