[MERGE] loosen the constraints on WorkingTree.set_last_revision.

[Aaron Bentley]

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

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

One scenario is when you have checkouts and you forget about one of them.

Another scenario is when you have a shared repo, and you you uncommit in
a branch that someone else is using.  A related scenario comes up when
we support read-only checkouts, and someone who you don't know has a
checkout of one of your public branches.  Shallow branching also relates
to this, because shallow branches will need to retrieve historical data
from their parent branch occasionally.

So I think that the rule should be "you should not uncommit unless you
are *sure* that you won't break your own or someone else's data." If you
break that rule, you're in the realm of unsupported behavior, and it's
not our fault that the system can't work the way you might like it to.

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

iD8DBQFE2SRF0F+nu1YWqI0RAkrmAJ48Xzom9/IYqrGZKIBK/3E9bwwdRgCfba4A
CJrQR2e9wjjC5wUBHVzud48=
=wDZ9
-----END PGP SIGNATURE-----