Whose distributed VCS is the most distributed?

[John Goerzen]

On Mon, Aug 14, 2006 at 07:24:26AM +0200, Matthieu Moy wrote:
> John Goerzen <jgoerzen at complete.org> writes:
> 
> > Well, not just that (I tried it); you have to also know the revid of the
> > previous changeset on the same branch.  There doesn't appear to be any
> > nice way to discover that automatically.
> 
> What's "-r before:revid:foo" meant for then?

I don't know; where is it documented?  It certainly isn't in the bzr
manpage.  But then, neither was the ability to specify the SHA1 ids of
two items on the original merged branch to -r.

Don't get upset at me for not knowing that bzr has a feature that isn't
documented.  Perhaps you need to do some revision in that area.

I will say that before writing my original post, I went through the bzr
tutorial on the wiki, read through the relevant parts of the manpage,
and searched for relevant pages on the wiki (and read anything that
seemed relevant).

... after poking about a bit, I see a file out under
/usr/share/doc/bzr/txt on Debian that mentions it, though the example it
gives is not very informative.  (The manual says the syntax is
"before:rev", but then we see an example for "before:before:rev" -- can
a persion list "before" an arbitrary number of times to go back an
arbitrary number of revisions?)

It would be better to have this documented in the manpage.  I guess the
bzr manpage does not fully document all bzr options.  (Does anything?)

> Not all DVCS are Darcs, and not all DVCS are patch-based. Bazaar is
> snapshot-based, that is, the revision identifier refers to the state
> of your project at a given stage. The notion of patch of Darcs does
> not really exist in Bazaar.

I understand, but bzr should still be able to preserve the original
history in a way that is easily accessible after merging.  Other tools,
such as Git and Hg, can do that and also aren't Darcs ;-)

> It seems all you're interested is to view the diff introduced by a
> revision. There are many things one may want to do with it. You can
> get the content of a file at this point, view the diff between this
> revision and any other one (in a distributed environment, people
> usually commit very often, and individual revisions usually introduce
> too few changes to be actually useful), revert your tree to that
> revision, ...

These are all good points.  Getting the diff seemed to be the easiest
way to prove whether the history of the individual merged items came
across.