Re: What have the Romans done for us? (Bazaar)

["Stephen J. Turnbull" <stephen@xemacs.org>]

Alan Mackenzie writes:

 > It seems the time taken is only weakly dependent on what you're logging
 > over.  I was just getting logs for a single file,
 > .../lisp/progmodes/cc-engine.el.

As Eli points out, you need to learn (at least a little bit) how to
"think Bazaar".  In CVS getting logs for a single file is faster than
for the whole project because you only get the logs you want, from one
,v file.  In Bazaar, getting logs for a single file is more costly
than getting them for the whole project because you have to get all
the logs, then filter out the uninteresting ones.

This is because you do not commit changes to a file in Bazaar (or any
of the other dVCSes); you commit all the changes to the tree.  There's
only one log for all the history of the branch.

Also, "bzr log -n0" is *much* slower than "bzr log" because the former
needs[1] to compute the whole history DAG to decide where to put each
commit before displaying them, while the latter just chases the
principal parent chain, and can start displaying log entries
immediately.

 > This vagueness is prevalent over much or all of 'bzr help <cmd>'.
 > Is it too much to expect these man pages (in effect) to be precise?

Currently, yes.  The developers are aware that the docs have some
problems, and some progress is being made.

 > > >So, yes, bzr is wonderful, because it's a DISTRIBUTED VCS, and
 > > >distributed VCSs are Good Things.  Would somebody please remind me why?

Sure.  The direct benefit is that you can work on a branch with little
effort, temporarily isolating the changes you're working on from
interference with others' work.  You can choose when to pull upstream
changes into your branch, and which changes to accept.  In CVS (or SVN
up to 1.4 or so), pulling multiple times will usually result in
annoying, unnecessary merge conflicts.  You can also choose to pull
from multiple upstreams (which all must be branches off the same
mainstream, of course), and integrate those changes.  It is this last
integrative function that is most characteristic of dVCS (SVN still
can't do this very well, and not at all across separately administered
mirrors).

The indirect benefit is a substantial savings in time and frustration
for developers who enjoy the direct benefits, and that means more
rapid delivery of new code to all users, including you.

 > My question wasn't rhetorical.  ;-)  I'd like having local history if I
 > could access it in less than historical time,

That way of stating it is quite rhetorical, though.


Footnotes: 
[1]  "Needs" in the current implementation.  It's possible to improve
this, and some work is being done at the moment.