Comparision of Git & Bzr [was Re: Short HOWTO on using git for Samba development]

Jelmer Vernooij jelmer at
Tue Jun 26 17:18:58 GMT 2007

On Tue, Jun 26, 2007 at 09:27:07AM -0500, Gerald (Jerry) Carter wrote:
> Jelmer Vernooij wrote:
> I mentioned this before but I'm curious, do people
> consider win32 support a requirement for our SCM?
No, I don't think it is. People with Windows already have a SMB
server. Also, git does work on Windows, it just can't be as fast as it
is on Linux.

> >> * What would the resulting size be?
> > I think it was about half the size of the Samba Subversion 
> > repository last time I tried it.  Obviously, it would be a
> > lot less when lazy repositories would be supported.
> Really ?  Does the revision sharing in a repository gain
> you that much? My SAMBA_4_0.bzr diff/patch mirror from svn is
> 312MB alone.  And the entire Samba svn repo is only about
> 550MB.
That's odd, I recall my just-Samba 4 import into bzr was around 200 Mb
last I tried (but that's a while ago now).

> Help me to understand something about repositories.  The way
> I read things, "bzr init-repo" just gives me a way of sharing
> revision history between branches but does not provide a way
> to do the equivalent of "git-clone" where I get the entire
> repo and branches.  I can only "bzr clone" a single branch
> at a time.

> So a repo is a nice for a single developer or a shared
> repository where people do checkouts, but not as a means of
> publicaly sharing branches in a project.

> Am I right?
Right. Shared repositories are just a storage optimization. They're
not a UI thing (yet). I've heard people talking about allowing you to
push repositories and all the branches in them at once, but haven't
seen any actual implementations.

On Tue, Jun 26, 2007 at 10:01:15AM -0500, Gerald (Jerry) Carter wrote:
> Jelmer Vernooij wrote:
> I would be very concerned about scaling a bzr repo with our
> existing number of svn commits.  Granted that we coud drop
> the svn history and that a DSCM system may not see the same
> high number f commits as the "svn-commit-to-save" pattern
> we have here, but long term this could be a real problem.
Bazaar is working on getting better performance, it's just not there
yet. It will work with large trees in the future, just not yet. I also
don't think we should adopt it (even by truncating history) until it
can handle the larger histories.

> I don't want to start out with performance issues.
> And I don't see rsync as a valid means of initial branching.
> bzr should stand on its own without alternative means of
> obtaining the initial tree.



Jelmer Vernooij <jelmer at> -

More information about the samba-technical mailing list