rfc: 'bzr compare' command

[John A Meinel]

Martin Pool wrote:
> On Mon, 2005-07-25 at 17:08 -0500, John A Meinel wrote:
>
>
>>Isn't this basically what I wrote as "bzr missing"? I realize you didn't
>>prefer the name.
>
>
> Yes, it is; I'll pull that code into a builtin.
>
> I'm not totally satisfied with "compare" as a name either.

"missing" is a carry over from arch land. Specifically it looks for what
revisions are missing.
"compare" to me means compare everything, including the working tree.

I suppose "missing-revisions" is more exact, but it seems too verbose.

...

>>I guess my "bzr missing" only said what was missing in this that was
>>present in other, and your "bzr compare" is trying to do both ways at once.
>>My only concern is that it be obvious which one is presented when.
>>(Probably just in order is okay.)
>
>
> Right, one could get the same results by running missing twice.  I'm not
> sure if it's better to show both in the same output, with some kind of
> headers to separate them, or just have the person run the commands
> twice.
>

I prefer to run it twice. Perhaps with a "--reverse" flag, so that if
you have an 'x-pull' location you can do:
bzr missing
bzr missing --reverse

I'm not 100% against doing them both at the same time (the above is a
little bit ugly).

If you do both ways, probably missing is the wrong command name. Since
to me it implies more of a one way check. But maybe that is just from
usage, and not intrinsic in the name.

I do know that historically, when I ran it, I didn't care what other was
missing, because I just wanted to be up-to-date with it.

On the other hand, with bzr, when I use rpull/rpush to keep my working
tree up-to-date with some remote tree (and vice versa) it would make
sense to have a command to run to check whether push or pull needs to be
called. (who is missing what).
Currently my rpush and rpull commands do the check, such that if you
call "bzr rpush", it lets you know if local is not up-to-date with
remote so you know to call "bzr rpull".


>
>>Also, will you compare their complete revision ancestry, or just
>>revision-history?
>>If I merge your branch, you need to look at the ancestry. But ancestry
>>might be missing (as is the case of the current bzr mainline tree).
>>
>>I guess I would suggest a hybrid. Only 'revision-history' can be
>>missing, but it is present if it exists in the ancestry. Otherwise you
>>can't use simple revision numbers to reference the logs.
>
>
> Right.  So we pass though A's revision history and see if it has been
> merged anywhere into B, and then vice versa.

Exactly. Go through revision history, and not the complete ancestry.

As an aside, would it make sense to have a "revision-set" file, which is
the complete set of all revisions which exist in the ancestry. I find
that with the new ancestry model, we frequently have to traverse the
revision tree to find all of the history (which I frequently just load
into a set for testing existence), and it might be nice if we could do a
single load, rather than having to read all of the revisions.
It would probably help "bzr missing" and certainly could help "bzr merge".
It seems fairly cheap to keep up-to-date, but fairly expensive to
regenerate (hence a valid thing to cache).
It could also be possible to store it as the current "revision-history"
+ a "merged-revisions" file which only stores the entries not in
"revision-history".

It would complicate my "bzr uncommit" plugin which pops off the last
revision, and optionally removes the entries from the stores. Trying to
figure out exactly what is being removed gets a little complicated since
it might have been merged from some other branch (double merging ...).
Worst case I just regenerate it from scratch. (Though if you have
missing revision entries, you again have problems).

And finally, in the future, are you planning on keeping the revision
entries for merges? Right now the bzr mainline tree doesn't have any of
Aaron's (or my) revision entries. Which means you could never use them
as merge points (and currently causes bzr merge to fail).

If you don't you could keep the entry in merged-revisions, but it would
mean merged-revisions cannot be regenerated from scratch.

John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050725/e9af75ac/attachment.pgp