[MERGE] loosen the constraints on WorkingTree.set_last_revision.

[Robert Collins]

On Tue, 2006-08-08 at 14:32 -0400, Aaron Bentley wrote:
> -----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.

Uhm, if you uncommit the last branch tip referring to a revision, its
expected that all it, and all unreferenced merges from it will be
cleaned up.

I dont see any accidental data loss scenario here.

Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060809/6542f524/attachment.pgp