[MERGE] loosen the constraints on WorkingTree.set_last_revision.

[Aaron Bentley]

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

Robert Collins wrote:
> On Mon, 2006-08-07 at 20:30 -0400, Aaron Bentley wrote:
>>That's only legitimate if having a last_revision not in the branch is an
>>illegal state.  I'm not saying 'unreachable' here, but 'illegal'.  If
>>it's not an illegal state, then you can destroy legitimate working trees
>>with clean-my-repo, and that's very bad.
> 
> Perhaps we are talking past each other. I'm saying that creating a tree
> whose last-revision is not in the branch, and not in the repo, is
> supported behaviour *because* you can do it using the standard bzr
> commands, without plugins. [ignoring that clean-my-repo does not exist,
> it is after all planned].

I'm saying that just because our tool makes something possible, doesn't
mean we must condone it.  We would prevent it from happening if we
could, but we can't.  It's like saying the availablity of crowbars makes
burglary legal.

If it's supported behaviour, then it is immoral for us to allow working
trees in that state to lose data.  So if you insist that having
functionality in core means anything you can do with that functionality
is supported, then it's immoral to provide both uncommit and clean-my-repo.

> I dont know what you mean by 'destroy' the tree though - its current
> inventory is available, so if its first parent is not available, falling
> back to using an emptytree as a the common ancestor for update (which is
> how you get the tree back to a committable point after an uncommit on
> the branch) seems reasonable to me.

It's not just the first parent, it's a potentially large number of past
revisions.  Losing your history is not a trivial situation.  It's what
VCSes are supposed to prevent.

> (And is how the baz-import workaround
> works, though its not in the core (it should be)).

Which "should" do you mean here?  "We should do this" or "It should be
like this, but it can't be, because..."

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

iD8DBQFE2NjQ0F+nu1YWqI0RAlH5AJwPtvsLLh+E0zEbj2JzGOk/jfS43gCcDCz8
9sp79j5XbvPaFkv4pJgiGBA=
=Lzik
-----END PGP SIGNATURE-----