[PATCH]: Optional explanation for options

[John Arbash Meinel]

Robey Pointer wrote:
> 
> On 20 Sep 2005, at 21:16, John A Meinel wrote:
> 

...

> 
> Yes, actually.  Thanks. :)
> 
> Since this might not be obvious to some users -- it wasn't obvious to 
> me until you explained it -- it would be cool if the "cset" command 
> could take another branch as an argument, and use the merging code to 
> find the common base automatically.  Maybe it already does this (I 
> can't check right now because I'm on a train).
> 
> In other words:
> robey at ralph:code/bzr.dev.robey$ bzr cset --from ../bzr.dev

I'm not sure what version of the code you have. But that is how the
current code works.

bzr cset ../other

Should generate the changeset which lets you recreate "." from "../other".

I also may not have kept everything up-to-date. bzr is maintaining a
relatively high development rate right now.

You can also do this:

bzr cset other this

Or specify revisions with
bzr cset other/@100 this/@25

But that syntax is going out of style, so it may change soon.


bzr cset -r 25
Just displays the current directories version 25 against it's ancestor
(revno=24).
Or you could do bzr cset -r 15..25 which gives base as revno=15.

I mostly implemented that part, because I use cset to see what the
mainline has done, and bzr cset -r 1000 is easier than
bzr diff -r 999..1000
(And at one point, bzr diff did not allow a range).

> 
> 
>>>
>>> One of the interesting things, is that BASE can be anything. So I can
>>> create a changeset of your tree, against mine, or a common  ancestor, or
>>> whatever makes the most sense. The default in the code is to take your
>>> tree and find the common ancestor, and then produce the changeset that
>>> will let you generate my tree from the common ancestor.
> 
> 
> I don't quite understand this paragraph but you might be saying  exactly
> what I'm suggesting above, in which case ignore me.  I've  been dealing
> with Microsoft all day and it's left my brain like month- old mashed
> potatoes. :)

In general a changeset only makes sense when you compare against
ancestry. So the idea is that if we have these trees:

A - B - C - D - E - F - G
          \
            H - I - J

If I want to send you G, the obvious changeset would be to send C->G
(base=C, this=G).
But since all I'm actually trying to do is to give you the contents of
G, I can send J->G.

Which would actually tell you what you would be merging into your tree,
rather than telling you what changes I have made. (say the changes in E
and F are (almost) identical to I, changing the base would mean you need
to look at less garbage in the diff).

Now, we have been discussing some issues with the above. Namely that it
would be nice if changesets gave as much information as "bzr merge".
Since bzr merge has access to the working trees, it can also pull all of
D, E, and F into the working branch. Which would mean that a changeset
should bundle those revisions as well.

The current code bundles enough information to regenerate the Revision
XML, but not enough to generate all of the texts and inventories.

Does that make more sense?

John
=:->


> 
> robey
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050921/8e0fe8c5/attachment.pgp