switch to a past revision

Aaron Bentley aaron.bentley at utoronto.ca
Wed Aug 2 19:33:19 BST 2006

Hash: SHA1

John Arbash Meinel wrote:
>>I think this is the kind of problem I was trying to avoid when I argued
>>for having just one revno per location.
> The only way we could do that is to expressly forbid pushing to a branch
> that has a tree we can't update. Otherwise, things are out of sync
> anyway, and we just have no way to tell that they are. And especially no
> way to update the tree and preserve local changes.
> Having 2 last_revision indicators does complicate things. But it is also
> the only way to solve certain problems.

It's only a problem if you insist on having the branch and the working
tree in exactly the same location, and on updating only the branch.

It seems pretty clear that when people have a tree, they want to update
the tree as well as the branch.

And if the tree is in a slightly different location from the branch,
like in a subdirectory or in the parent directory, again you don't have
a problem.

>>If it gives only one, shouldn't it always produce the branch revno?  If
>>there's a workingtree, there's guaranteed to be a branch, but there's no
>>guarantee that there's a workingtree if a branch is present.

> I disagree, because if you are in a working tree, you want to know the
> current state of the tree, not the state of the branch.
> I think it should use the branch revno if there is no tree, but the tree
> should take precedence.

This sounds very inconsistent to me.  I would like people to be able to
predict what bzr will do.

If you want to show the working tree revno by default, then I think it
should fail if there's no working tree present, unless a --branch switch
is given.

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


More information about the bazaar mailing list