bzr branch -r

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John A Meinel wrote:
> Unfortunately not quite the right fix (because you can now supply stuff
> like 'date:yesterday' or 'revid:aoe at utnhauoeu-234234-234234' to the
> --revision command.
> 
> The correct fix is:
> 
> if revision is None:
>   revision = [None]
> else:
>   # Check for the right number of revision arguments
>   ...
> 
> revno, rev_id = br_to.get_revision_info(revision[0])
> if revno == 0:
>   revno = None
> 
> This has been fixed in my bzr-split-storage branch, but it might be a
> while before that is merged, since it is a pretty big change.

I was going to say that's wrong-- that since I call lookup_revision
later on, it doesn't matter whether a number or id:foofa is used.  But
you're right, because while merge doesn't care, update-revisions wants a
revision that's in the history of the relevent branch.  We could
probably support branching from a revision not in the revision-history
of the branch, but it's a pretty obscure use case, and the results could
be pretty arbitrary.

It might be nice to include a unique branch identifier in revisions, so
that we could reconstruct a revision history from the revisions alone.
But now that I think of it, there would be a lot of problems
guaranteeing the uniqueness of the branch id and uncommits would
probably mess it up too.

As an aside, it's hella confusing that the partial fix was merged with
the message "- merge john's plugins-have-test_suite.patch:...".  I
assumed Martin hadn't fixed it at all, yet.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC1o3F0F+nu1YWqI0RAupmAKCGw1U2LV1BuCmmH6GW75ytNcfWaACePXLw
PrKOyA1uW8QfqniSydlC/48=
=jqrK
-----END PGP SIGNATURE-----