cmpilato wrote on 05/20/2004 03:35:57 PM:
> John Peacock <jpeacock@rowman.com> writes:
>
> > If the LOCK tracked both who locked it and the revision at which the
> > LOCK was issued, then it would indeed be trivial to revert the
> > changes. But I'm with Brane and Mark that this is not the correct
> > way to handle it. If we are to support cancelling a LOCK and
> > reverting the changes, I cannot see any way to get around having the
> > changes be part of a private transaction and not exposed as HEAD.
> > Otherwise the interim changes will lead to inconsistent views for
> > all users except those who had the LOCK.
>
> I don't see why this will lead to inconsistent views. Can you
> clarify?
I believe John is referring to the way that was originally proposed where
a PUT would be visible to people doing a GET of HEAD without having
commited that PUT until some other command came along later to commit it.
In that scenario, if the user cancelled the lock and never "committed"
then people would have been retrieving something from HEAD that is now not
referenced in the repository in any manner. It would be like it never
existed, hence the inconsistent views.
This is solved by the later proposal to cause PUT to always commit.
Mark
Received on Thu May 20 21:43:25 2004