Re: bzr vs. git repository

[David Kastrup]

Eli Zaretskii <address@hidden> writes:

>> Date: Sat, 01 Jan 2011 09:28:38 +0100 (CET)
>> From: Werner LEMBERG <address@hidden>
>> 
>> As you can see, bzr still needs about three times more bandwidth in
>> both receiving and sending...
>
> So what?  In my testing, both on GNU/Linux and on MS-Windows,
> update/pull times are very similar (with bzr slightly _faster_ on
> GNU/Linux).  That includes the initial "bzr branch" vs "git clone" (10
> min for bzr vs 15 for git).  Other common operations are mostly
> comparable as well.  (A great surprise was "annotate", which, for
> xdisp.c, took 1 minute with bzr, but a whopping 4.5 minutes with git.
> But I see that as a curiosity.)

That is not a curiosity but a consequence of git's design choices.  git
stores file system snapshots and a DAG of commits.  Everything else is
reconstructed on-the-fly when you ask for it.  As a result, renaming
files in git is indistinguishable from deleting the old file and
creating a new file with the old content.

That makes git a handy tool for analyzing, say, a progression of
distribution tarballs.  You just check in all the tarballs into a git
repository, and you get renames, moves, copied content, tracking of
material and so on out _gratis_ because git never stores those kind of
things but instead knows how to make them up.

Now "git annotate" is an example where git constructs a history of
content through file renaming and subfile copying, and does it at the
time of "git annotate".  That's the reason git annotate is _expected_ to
be an expensive operation, and you have various options to tell it just
how expensive it may do its work, depending on the amount of
reconstructed information you'd like to see.

Bazaar does not do this.  It just reproduces the history according to
the file operation history that has been explicitly stored into Bazaar
by the user.

If you store a sequence of unpacked tarballs into Bazaar and ask for the
history of some content, Bazaar will not track the content across
subfile copying and file renames because it has not been _told_ about
them explicitly.

-- 
David Kastrup