You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2004/05/19 21:54:19 UTC
Exclusive Locking: design in a nutshell
Here's the general jist of our original locking design for libsvn_fs.
I'm using casual language to describe it, purposely not going into too
much detail, so that it can be easily compared to other designs. (We
*have* done some detailed API spec'ing, which we can describe later.)
Also, remember that this is not a UI discussion. For the moment,
we're deliberately avoiding chat about how a Subversion client would
create/destroy/discover locks.
---------------
The main idea is: a user "locks" a file in the filesystem. This means
than a new (potentially) long-lived transaction is created in the
filesystem which represents this one locked file. There's a 1-to-1
mapping between a locked file and a lock-txn. We keep this mapping in
a new 'locks' table that maps a path to a txn-id.
* When somebody tries to write to any path, the filesystem checks to
see if a lock-txn already exists for it. If so, and if the writer
owns the lock-txn, then the new data is put into the lock-txn,
overwriting whatever was previously there. (And obviously, if the
writer doesn't own the lock-txn, the write is rejected.)
* When somebody tries to read from a non-HEAD revision, everything
is normal. When somebody tries to read from the HEAD revision,
the system treats locked paths specially: instead of pulling the
file's data out of the HEAD revision, it gets pulled out of the
appropriate lock-txn.
* The lock-owner ultimately ends up "unlocking" the file, which
causes the lock-txn to be committed. Either that, or the lock
owner destroys the lock, which aborts the lock-txn, and all
changes are lost.
The net affect of this (from a WebDAV client's point of view) is that
a user can LOCK a file indefinitely and do any number of PUTs to it.
People who do checkouts of HEAD, or just GETs of the file, will always
see the file's latest text (that is, whatever text was most recently
PUT by the lock-owner.) If somebody else tries to do a normal
Subversion commit which includes a change the locked file, the entire
commit will be rejected. Ultimately the owner UNLOCKs the file and a
new revision is created.
Really, we envision at least two APIs to end the lifecycle of a
lock-txn:
1. A call to svn_fs_unlock() will attempt to commit a single
lock-txn and create a new revision.
2. A new svn_fs_commit_txn2() function will take a "main" txn as
usual, but also take a list of lock-txns. It would first merge
the lock-txns into the main txn, then merge the whole thing with
the HEAD revision.
Depending on how we design the new commit function, we might also want
to give users the option to "hold on" to their lock-txns after the
commit completes. (In other words, delete the temporary main txn, but
not the lock-txns.)
There's at least one annoyance with this design: operations like
'move' and 'delete' must verify that no locks exist for paths below
the deleted/moved thing. This requires scanning the table of locked
paths, or doing a 'reverse directory walk'. Actually, it may be slow
in general to scan a locks-table -- we're talking about doing it for
every read of a path@HEAD and every write of a path.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Josh Pieper <jp...@ece.cmu.edu>.
My first impression is that this scheme adds significant complexity,
where a simpler method would suffice. The simpler method:
- Have the a locks table which any client may access. Only one
client may hold a lock for a given path.
- At commit time, the server may check the committed paths to see if
any of them are protected by locks. Conceivably if all clients
that wanted to edit a file were "nice" and held the lock before
modifying it, then this check would not be necessary.
I talked on IRC with Ben about why the long-lived transactions were
chosen over this simpler scheme. The motivation seemed to be that
with DAV mounts, every single "auto-save" of a file would create a new
revision. With committing a revision automatically upon UNLOCK,
hopefully the number of revisions would decrease as most clients only
issue an UNLOCK when they are truly done with the file.
I think a simpler solution would be to attack this at the higher
layers: either through DAV autoversioning, or the application layer.
To fix it at the DAV lyer, you would just have the DAV layer perform a
commit for every PUT, except if that resource was locked, then perform
a commit every time a lock is release. This scheme does break the
property that every PUT is immediately seen by other clients, however
I think it is unwise to allow unversioned data to be transparently
propagated to other clients. How would the text-base work in that
case? The client would have no idea what version of a file it had
locally and thus no means for transmitting diffs to/from the server.
Alternatively this could be fixed at the application layer, but
turning off the "auto-save" feature.
-Josh
Ben Collins-Sussman wrote:
> Here's the general jist of our original locking design for libsvn_fs.
> I'm using casual language to describe it, purposely not going into too
> much detail, so that it can be easily compared to other designs. (We
> *have* done some detailed API spec'ing, which we can describe later.)
>
> Also, remember that this is not a UI discussion. For the moment,
> we're deliberately avoiding chat about how a Subversion client would
> create/destroy/discover locks.
>
> ---------------
>
> The main idea is: a user "locks" a file in the filesystem. This means
> than a new (potentially) long-lived transaction is created in the
> filesystem which represents this one locked file. There's a 1-to-1
> mapping between a locked file and a lock-txn. We keep this mapping in
> a new 'locks' table that maps a path to a txn-id.
>
> * When somebody tries to write to any path, the filesystem checks to
> see if a lock-txn already exists for it. If so, and if the writer
> owns the lock-txn, then the new data is put into the lock-txn,
> overwriting whatever was previously there. (And obviously, if the
> writer doesn't own the lock-txn, the write is rejected.)
>
> * When somebody tries to read from a non-HEAD revision, everything
> is normal. When somebody tries to read from the HEAD revision,
> the system treats locked paths specially: instead of pulling the
> file's data out of the HEAD revision, it gets pulled out of the
> appropriate lock-txn.
>
> * The lock-owner ultimately ends up "unlocking" the file, which
> causes the lock-txn to be committed. Either that, or the lock
> owner destroys the lock, which aborts the lock-txn, and all
> changes are lost.
>
> The net affect of this (from a WebDAV client's point of view) is that
> a user can LOCK a file indefinitely and do any number of PUTs to it.
> People who do checkouts of HEAD, or just GETs of the file, will always
> see the file's latest text (that is, whatever text was most recently
> PUT by the lock-owner.) If somebody else tries to do a normal
> Subversion commit which includes a change the locked file, the entire
> commit will be rejected. Ultimately the owner UNLOCKs the file and a
> new revision is created.
>
> Really, we envision at least two APIs to end the lifecycle of a
> lock-txn:
>
> 1. A call to svn_fs_unlock() will attempt to commit a single
> lock-txn and create a new revision.
>
> 2. A new svn_fs_commit_txn2() function will take a "main" txn as
> usual, but also take a list of lock-txns. It would first merge
> the lock-txns into the main txn, then merge the whole thing with
> the HEAD revision.
>
> Depending on how we design the new commit function, we might also want
> to give users the option to "hold on" to their lock-txns after the
> commit completes. (In other words, delete the temporary main txn, but
> not the lock-txns.)
>
> There's at least one annoyance with this design: operations like
> 'move' and 'delete' must verify that no locks exist for paths below
> the deleted/moved thing. This requires scanning the table of locked
> paths, or doing a 'reverse directory walk'. Actually, it may be slow
> in general to scan a locks-table -- we're talking about doing it for
> every read of a path@HEAD and every write of a path.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
--
Function reject.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Ben Collins-Sussman <su...@collab.net>.
On Fri, 2004-05-21 at 08:28, Josh Pieper wrote:
> I think you are proposing intermingling the implementation of two
> distinct and parallel features. If they are both implemented
> separately, you gain flexibility and decrease the complexity of
> implementation.
+1. You've said it better than I can. I don't see the reason for
lock-txns anymore. (And it doesn't seem intuitive to me at all for a
lock-holder to enter a "pocket universe" where she's the only person
able to write *or* read what she's locked.)
Branko, can you comment on my 2nd draft proposal? Yes, I know it's
phrased in a webdav-y way, but I can just easily formulate it in a
libsvn_fs-y way if you want me to.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Josh Pieper <jj...@pobox.com>.
Branko ??ibej wrote:
> Ben Collins-Sussman wrote:
> >Yes, you're right. That's how I understand it.
> >
> >A "lock", whether it be shared or not, is just a row in a table that
> >means, "this person (or persons) has exclusive rights to commit to the
> >HEAD version of this path."
> >
> >
>
> Can we now please stop letting DAV specifics drive our FS design? We've
> moved from FS functionality to LOCK/PUT/UNLOCK semantics as if there's
> no difference between the two. Basing the FS functionality on the DAV
> functionality can never be the right way to go about this, for one thing
> because DAV is stateless and web-centric and therefore has to make all
> sorts of compromises. It is *not* a good example for desigining version
> control features.
>
> I insist we should approach this the other way around: decide first
> about how we want the FS to behave, from the point of view of a
> versionable transaction-based filesystem. Then we can decide how to map
> that to DAV.
Looking at it from the svn_fs.h viewpoint is what I was trying to do.
We already export functions from svn_fs.h that allow end users to
collaborate on transactions without committing. The generic
transaction begin/modify routines do this. What we don't do is export
functionality that allows them to gain exclusive access to a path.
Why try and overload already existing functionality onto the new
locking semantics?
Re: Exclusive Locking: design in a nutshell
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>On Thu, 2004-05-20 at 15:15, Josh Pieper wrote:
>
>
>
>>>The DAV spec speaks of shared (read and write) locks, but doesn't
>>>specify how they behave. Therefore we can do anything that's reasonable.
>>>IMHO the only thing that's reasonable is for all clients that have a
>>>shared lock on the same object to see the same contents. Ergo,
>>>transaction-per-lock.
>>>
>>>
>>If every PUT caused a commit without using shared transactions, the
>>same result would occur, correct? All clients who hold the shared
>>lock would see the results as soon as a PUT is issued. It would just
>>have the side effect of allowing clients who don't have the shared
>>lock to see the results of each PUT as well.
>>
>>
>
>Yes, you're right. That's how I understand it.
>
>A "lock", whether it be shared or not, is just a row in a table that
>means, "this person (or persons) has exclusive rights to commit to the
>HEAD version of this path."
>
>
Can we now please stop letting DAV specifics drive our FS design? We've
moved from FS functionality to LOCK/PUT/UNLOCK semantics as if there's
no difference between the two. Basing the FS functionality on the DAV
functionality can never be the right way to go about this, for one thing
because DAV is stateless and web-centric and therefore has to make all
sorts of compromises. It is *not* a good example for desigining version
control features.
I insist we should approach this the other way around: decide first
about how we want the FS to behave, from the point of view of a
versionable transaction-based filesystem. Then we can decide how to map
that to DAV.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Ben Collins-Sussman <su...@collab.net>.
On Thu, 2004-05-20 at 15:15, Josh Pieper wrote:
> > The DAV spec speaks of shared (read and write) locks, but doesn't
> > specify how they behave. Therefore we can do anything that's reasonable.
> > IMHO the only thing that's reasonable is for all clients that have a
> > shared lock on the same object to see the same contents. Ergo,
> > transaction-per-lock.
>
> If every PUT caused a commit without using shared transactions, the
> same result would occur, correct? All clients who hold the shared
> lock would see the results as soon as a PUT is issued. It would just
> have the side effect of allowing clients who don't have the shared
> lock to see the results of each PUT as well.
Yes, you're right. That's how I understand it.
A "lock", whether it be shared or not, is just a row in a table that
means, "this person (or persons) has exclusive rights to commit to the
HEAD version of this path."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Josh Pieper <jj...@pobox.com>.
Branko ??ibej wrote:
> Josh Pieper wrote:
>
> >Speaking of shared locking, is there some specific semantics for
> >shared locking that you're referring too? How would that work, a
> >client requests a lock and states that at most N other clients may
> >hold the lock at the same time? I was unable to find anything
> >resembling that in the WebDAV spec.
> >
> >
> The DAV spec speaks of shared (read and write) locks, but doesn't
> specify how they behave. Therefore we can do anything that's reasonable.
> IMHO the only thing that's reasonable is for all clients that have a
> shared lock on the same object to see the same contents. Ergo,
> transaction-per-lock.
If every PUT caused a commit without using shared transactions, the
same result would occur, correct? All clients who hold the shared
lock would see the results as soon as a PUT is issued. It would just
have the side effect of allowing clients who don't have the shared
lock to see the results of each PUT as well.
-Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Julian Reschke <ju...@gmx.de>.
Branko Čibej wrote:
> ...
> The DAV spec speaks of shared (read and write) locks, but doesn't
> specify how they behave. Therefore we can do anything that's reasonable.
> IMHO the only thing that's reasonable is for all clients that have a
> shared lock on the same object to see the same contents. Ergo,
> transaction-per-lock.
That's incorrect. RFC2518 defines behaviour both for shared and
exclusive locks (see previous mail).
Best regards, Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Michael W Thelen <th...@cs.utah.edu>.
* Greg Hudson <gh...@MIT.EDU> [2004-05-21 10:21]:
> On Fri, 2004-05-21 at 02:41, Branko Čibej wrote:
> > OTOH it is the most logical thing in the world for a locker to see
> > different contents of the locked resource than anyone else, after all
> > that's one of the reasons to lock it in the first place.
>
> It is? I thought the reason to lock a resource was so no one else could
> modify it (unless they're allowed to steal the lock, which I suppose is
> ACL fodder). Nothing more, nothing less.
That was my understanding, too. I agree with what Josh Pieper has said,
that the idea of collaborating on an uncommitted transaction (even if
it's just collaborating with yourself, I suppose) is orthogonal to
locking. I don't see why they need to be tied together.
-- Mike
--
Michael W. Thelen
It is the duty of every citizen according to his best capacities to give
validity to his convictions in political affairs.
-- Albert Einstein, "Treasury for the Free World", 1946
Re: Exclusive Locking: design in a nutshell
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2004-05-21 at 02:41, Branko Čibej wrote:
> OTOH it is the most logical thing in the world for a locker to see
> different contents of the locked resource than anyone else, after all
> that's one of the reasons to lock it in the first place.
It is? I thought the reason to lock a resource was so no one else could
modify it (unless they're allowed to steal the lock, which I suppose is
ACL fodder). Nothing more, nothing less.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>On Thu, 2004-05-20 at 13:23, Branko Čibej wrote:
>
>
>
>>The DAV spec speaks of shared (read and write) locks, but doesn't
>>specify how they behave. Therefore we can do anything that's reasonable.
>>IMHO the only thing that's reasonable is for all clients that have a
>>shared lock on the same object to see the same contents. Ergo,
>>transaction-per-lock.
>>
>>
>
>I really don't like the idea of "lock holders" seeing one thing when
>they GET, and the rest of the world seeing something else. It goes
>against the very principles of Subversion, as Jani pointed out.
>
>
That's not how I understood his post. What he said was that if a PUT on
a locked file were visible at once to everyone, then you could see
different trees for the _same_ revision depending on when you looked.
OTOH it is the most logical thing in the world for a locker to see
different contents of the locked resource than anyone else, after all
that's one of the reasons to lock it in the first place. Remember that
from the SVN command-line client's point of view, that will never happen
because the write is part of a commit. But it is a useful notion for
filesystem behaviour, and the different-contents-at-same-revision arent
a problem because the locker _expects_ the contents to change after a write.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2004-05-21 at 02:44, Branko Čibej wrote:
> >This is my only concern with the current proposal. It would seem,
> >though, that LOCK cancellation can be accomplished by remembering what
> >the resource looked like at the time the LOCK was taken out, and if
> >the LOCK is aborted, simply commit one more time with the lock removal
> >and content reversion.
> That's another reason why I'm against the idea that a locked PUT be
> treated as a checkpoint. It's contrary to the transaction-centric design
> of Subversion.
... except there's no such thing as "lock cancellation" in DAV, so it's
not a reason at all. (As far as I can deduce from reading the whole
thread, that is.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Branko Čibej <br...@xbc.nu>.
C. Michael Pilato wrote:
>Mark Phippard <Ma...@softlanding.com> writes:
>
>
>
>>What happens in the DAV spec if the user later cancels their LOCK? Do
>>those previous PUT's get discarded or committed? If the former, then it
>>seems odd that the DAV server should have previously handed out those now
>>invalid versions to someone that did a GET.
>>
>>
>
>This is my only concern with the current proposal. It would seem,
>though, that LOCK cancellation can be accomplished by remembering what
>the resource looked like at the time the LOCK was taken out, and if
>the LOCK is aborted, simply commit one more time with the lock removal
>and content reversion.
>
>
That's another reason why I'm against the idea that a locked PUT be
treated as a checkpoint. It's contrary to the transaction-centric design
of Subversion.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by John Peacock <jp...@rowman.com>.
Mark Phippard wrote:
>
> 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
Yeah, what he said...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard <Ma...@softlanding.com> writes:
> 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.
Ah yes, and is to this later proposal that I was speaking. Thanks for
the clarification.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Mark Phippard <Ma...@softlanding.com>.
cmpilato wrote on 05/20/2004 03:35:57 PM:
> John Peacock <jp...@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
Re: Exclusive Locking: design in a nutshell
Posted by "C. Michael Pilato" <cm...@collab.net>.
John Peacock <jp...@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?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by John Peacock <jp...@rowman.com>.
C. Michael Pilato wrote:
> Mark Phippard <Ma...@softlanding.com> writes:
>
>
>>What happens in the DAV spec if the user later cancels their LOCK? Do
>>those previous PUT's get discarded or committed? If the former, then it
>>seems odd that the DAV server should have previously handed out those now
>>invalid versions to someone that did a GET.
>
>
> This is my only concern with the current proposal. It would seem,
> though, that LOCK cancellation can be accomplished by remembering what
> the resource looked like at the time the LOCK was taken out, and if
> the LOCK is aborted, simply commit one more time with the lock removal
> and content reversion.
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.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Mark Phippard <Ma...@softlanding.com>.
cmpilato wrote on 05/20/2004 03:14:41 PM:
> Mark Phippard <Ma...@softlanding.com> writes:
>
> > What happens in the DAV spec if the user later cancels their LOCK? Do
> > those previous PUT's get discarded or committed? If the former, then
it
> > seems odd that the DAV server should have previously handed out those
now
> > invalid versions to someone that did a GET.
>
> This is my only concern with the current proposal. It would seem,
> though, that LOCK cancellation can be accomplished by remembering what
> the resource looked like at the time the LOCK was taken out, and if
> the LOCK is aborted, simply commit one more time with the lock removal
> and content reversion.
I see what you are saying, but that is not what I was asking. I was
setting aside SVN for the moment and the proposals being discussed and
just talking about the DAV spec itself. It seems like the main point of
contention is whether to make the content of a PUT available to others
without doing a commit first. What I do not understand about the spec,
and that is the question I asked, is that it seems like if the user
cancelled their LOCK after doing PUT's then for a while the server was
serving out revisions that now are no longer reflected in the repository
in any way. This does not seem correct under any circumstance. Not to
mention, even in the scenario where the LOCK is eventually committed, how
are those "intermediary" PUT's represented in history to something that
needs to know it?
As for your concern, I am not sure how "real" it is. I believe we are
only talking about "dumb" DAV clients. It doesn't seem to me that those
clients would be providing a UI to the user that would lead them to
believe they could cancel after they did a save. Perhaps that is also the
answer to my question? Maybe in the above scenario, cancelling the lock
later is not in the spec?
OK, I took a look at the specs and think I am more up to speed. A "dumb"
DAV client only does LOCK, PUT/GET, UNLOCK. So semantically, a PUT is a
commit where the lock is moved to the new revision. UNLOCK is removing
whatever lock remains. There is no real "cancel checkout" as the UNLOCK
either or is or isn't preceded by a PUT at some point in time.
Only when you move up to DeltaV do you have the ability to CHECKOUT,
CHECKIN and UNCHECKOUT.
So I would say the way Ben stated it earlier today (and others before him)
would make the most sense. A PUT is a commit and the lock is moved to the
new revision until an UNLOCK is received. And, as Ben stated, that could
only be if auto-versioning is ON. If it is OFF, you would reject
altogether. One concern I have with this last point is that it seems like
you need to make this determination at the time the LOCK happens,
otherwise an MS Word user could obtain a lock, but not save back, and when
they close it would just release the lock.
Mark
Re: Exclusive Locking: design in a nutshell
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard <Ma...@softlanding.com> writes:
> What happens in the DAV spec if the user later cancels their LOCK? Do
> those previous PUT's get discarded or committed? If the former, then it
> seems odd that the DAV server should have previously handed out those now
> invalid versions to someone that did a GET.
This is my only concern with the current proposal. It would seem,
though, that LOCK cancellation can be accomplished by remembering what
the resource looked like at the time the LOCK was taken out, and if
the LOCK is aborted, simply commit one more time with the lock removal
and content reversion.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Julian Reschke <ju...@gmx.de>.
Mark Phippard wrote:
> ...
> What happens in the DAV spec if the user later cancels their LOCK? Do
> those previous PUT's get discarded or committed? If the former, then it
> seems odd that the DAV server should have previously handed out those
> now invalid versions to someone that did a GET.
> ...
LOCKs aren't cancelled -- they are locks, not transactions. Don't
confuse them; a WebDAV LOCK is really just a mechanism to prevent others
from modifying a resource; that's all.
Best regards, Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Mark Phippard <Ma...@softlanding.com>.
Ben Collins-Sussman <su...@collab.net> wrote on 05/20/2004 02:40:22 PM:
> On Thu, 2004-05-20 at 13:23, Branko Čibej wrote:
>
> > The DAV spec speaks of shared (read and write) locks, but doesn't
> > specify how they behave. Therefore we can do anything that's
reasonable.
> > IMHO the only thing that's reasonable is for all clients that have a
> > shared lock on the same object to see the same contents. Ergo,
> > transaction-per-lock.
>
> I really don't like the idea of "lock holders" seeing one thing when
> they GET, and the rest of the world seeing something else. It goes
> against the very principles of Subversion, as Jani pointed out.
>
>
What happens in the DAV spec if the user later cancels their LOCK? Do
those previous PUT's get discarded or committed? If the former, then it
seems odd that the DAV server should have previously handed out those now
invalid versions to someone that did a GET.
I like the idea of PUT doing a commit while retaining the LOCK.
Mark
Re: Exclusive Locking: design in a nutshell
Posted by Ben Collins-Sussman <su...@collab.net>.
On Thu, 2004-05-20 at 13:23, Branko Čibej wrote:
> The DAV spec speaks of shared (read and write) locks, but doesn't
> specify how they behave. Therefore we can do anything that's reasonable.
> IMHO the only thing that's reasonable is for all clients that have a
> shared lock on the same object to see the same contents. Ergo,
> transaction-per-lock.
I really don't like the idea of "lock holders" seeing one thing when
they GET, and the rest of the world seeing something else. It goes
against the very principles of Subversion, as Jani pointed out.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Branko Čibej <br...@xbc.nu>.
Josh Pieper wrote:
>Speaking of shared locking, is there some specific semantics for
>shared locking that you're referring too? How would that work, a
>client requests a lock and states that at most N other clients may
>hold the lock at the same time? I was unable to find anything
>resembling that in the WebDAV spec.
>
>
The DAV spec speaks of shared (read and write) locks, but doesn't
specify how they behave. Therefore we can do anything that's reasonable.
IMHO the only thing that's reasonable is for all clients that have a
shared lock on the same object to see the same contents. Ergo,
transaction-per-lock.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Julian Reschke <ju...@gmx.de>.
Josh Pieper wrote:
> ...
> Speaking of shared locking, is there some specific semantics for
> shared locking that you're referring too? How would that work, a
> client requests a lock and states that at most N other clients may
> hold the lock at the same time? I was unable to find anything
> resembling that in the WebDAV spec.
Shared locking is defined in
<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.6.1> and
<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.6>.
Basically, a shared write lock behaves exactly the same way as as share
exclusive lock -- the only difference being, that multiple shared locks
(and thus lock tokens) can exist on the same resource.
Write access is granted if you submit one of the lock tokens for that
resource and is denied otherwise.
Hope thios helps, Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Josh Pieper <jj...@pobox.com>.
Branko ??ibej wrote:
> Greg Stein wrote:
> >It may be that transactions are not needed either.
> >
> >
> We could probably avoid them, yes, but I'd prefer to keep the current
> transaction-per-lock design, so that we can support cooperating clients
> in the future. By "cooperating" I mean client processes that share a
> lock ID, or distinct clients that use a shared lock to make coordinated
I am not sure why associating a long-lived transaction with each lock
object helps you achieve these goals. I think that allowing multiple
clients to co-operate on an uncommitted transaction is an orthogonal
feature to locking, even shared locking. i.e. you should be able to
do one without the other and vice-versa.
Speaking of shared locking, is there some specific semantics for
shared locking that you're referring too? How would that work, a
client requests a lock and states that at most N other clients may
hold the lock at the same time? I was unable to find anything
resembling that in the WebDAV spec.
-Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:
>Seems like a mini-think-reset is needed. To use Branko's term, a PUT might
>simply be a checkpoint, and an UNLOCK is simply a release of the lock (no
>commit action).
>
Yup.
>It may be that transactions are not needed either.
>
>
We could probably avoid them, yes, but I'd prefer to keep the current
transaction-per-lock design, so that we can support cooperating clients
in the future. By "cooperating" I mean client processes that share a
lock ID, or distinct clients that use a shared lock to make coordinated
changes that result in a single commit. Both of these notions would be
extremely useful in, e.g., a Subversion VFS plug-in for Samba. They're
not so useful for a command-line client, of course, but that would do a
single PUT at commit time anyway.
I wonder if we can do magic over DAV that lets the server decide when to
do a write or a checkpoint on PUT depending on parameters...
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Greg Stein <gs...@lyra.org>.
On Wed, May 19, 2004 at 08:00:46PM -0400, Greg Hudson wrote:
> On Wed, 2004-05-19 at 19:24, Josh Pieper wrote:
> > I talked on IRC with Ben about why the long-lived transactions were
> > chosen over this simpler scheme. The motivation seemed to be that
> > with DAV mounts, every single "auto-save" of a file would create a new
> > revision.
>
> Uh, has anyone confirmed this? I think it would be weird for a word
> processor to auto-save to the currently-open file. Normally, editing
> programs auto-save to a side storage area.
It looks like it autosaves locally.
So yah: a PUT would correspond to a manual save. That could change the
approach here, per Ben's recent post.
I was going to comment about how the 202 (Accepted) response could be very
handy for a PUT response. That is: we've accepted the change, but not
necessarily modified the resource (thus, we can return original contents
for a GET). Not sure that it matters right now.
Another thing to consider is how the Location: head can come into play. We
could accept a PUT and return a Location that corresponds to the
transaction holding the interim resources. I doubt many clients would
really look at that Location header, though. *shrug*
Seems like a mini-think-reset is needed. To use Branko's term, a PUT might
simply be a checkpoint, and an UNLOCK is simply a release of the lock (no
commit action). It may be that transactions are not needed either.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2004-05-19 at 19:24, Josh Pieper wrote:
> I talked on IRC with Ben about why the long-lived transactions were
> chosen over this simpler scheme. The motivation seemed to be that
> with DAV mounts, every single "auto-save" of a file would create a new
> revision.
Uh, has anyone confirmed this? I think it would be weird for a word
processor to auto-save to the currently-open file. Normally, editing
programs auto-save to a side storage area.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Julian Reschke <ju...@gmx.de>.
Josh Pieper wrote:
> Does the WebDAV spec explicitly state that versioning only occurs at
> UNLOCK time? If not, then it is possible that other WebDAV
> implementations could behave in the same manner, i.e. every PUT is a
> commit. This advice would also apply to operating Word on any
> versioning filesystem, not just WebDAV.
It depends. You can't modify a version-controlled resource without
checking it out (*). If you do, a new version will be created upon CHECKIN.
(*) Servers MAY support auto-versioning where old-style clients can
modify checked-in resources. Exactly when a new version is created
depends on the auto-versioning model in use, see
<http://greenbytes.de/tech/webdav/rfc3253.html#PROPERTY_auto-version>.
For clients that do use LOCK/UNLOCK (à la MS Office), the most useful
mode is DAV:checkout-unlocked-checkin, where the first modification of a
locked resource results in an automatic checkout, and the subsequent
removal of the lock results in a check-in.
Best regards, Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Josh Pieper <jj...@pobox.com>.
> >My first impression is that this scheme adds significant complexity,
> >where a simpler method would suffice. The simpler method:
> >
> > - Have the a locks table which any client may access. Only one
> > client may hold a lock for a given path.
> >
> >
> That would make it impossible to implement shared locks
> (a.k.a.notifications), and I don't think we want this restriction unless
> it's really necessary, which I don't see at this point.
Fair enough.
> > - At commit time, the server may check the committed paths to see if
> > any of them are protected by locks. Conceivably if all clients
> > that wanted to edit a file were "nice" and held the lock before
> > modifying it, then this check would not be necessary.
> >
> >
> "The lock". Which lock? You still have to verify the authenticity of the
> lock token. You don't want to allow your clients to spoof lock tokens...
That is what I meant, but it may not have been as clear as possible.
> >I talked on IRC with Ben about why the long-lived transactions were
> >chosen over this simpler scheme. The motivation seemed to be that
> >with DAV mounts, every single "auto-save" of a file would create a new
> >revision. With committing a revision automatically upon UNLOCK,
> >hopefully the number of revisions would decrease as most clients only
> >issue an UNLOCK when they are truly done with the file.
> >I think a simpler solution would be to attack this at the higher
> >layers: either through DAV autoversioning,
> >
> A separate feature that we have now and will want to keep anyway...
>
> >or the application layer.
> >
> >
> Oh no, that's not acceptable. "If you want to use Word with a Subversion
> server, turn off autosave". Yikes.
No, more like, "If you want to use Word with Subversion and don't want
_all_ of your changes versioned, turn off autosave."
Does the WebDAV spec explicitly state that versioning only occurs at
UNLOCK time? If not, then it is possible that other WebDAV
implementations could behave in the same manner, i.e. every PUT is a
commit. This advice would also apply to operating Word on any
versioning filesystem, not just WebDAV.
-Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Branko Čibej <br...@xbc.nu>.
Josh Pieper wrote:
>Ben Collins-Sussman wrote:
>
>
>>The main idea is: a user "locks" a file in the filesystem. This means
>>than a new (potentially) long-lived transaction is created in the
>>filesystem which represents this one locked file. There's a 1-to-1
>>mapping between a locked file and a lock-txn. We keep this mapping in
>>a new 'locks' table that maps a path to a txn-id.
>>
>> * When somebody tries to write to any path, the filesystem checks to
>> see if a lock-txn already exists for it. If so, and if the writer
>> owns the lock-txn, then the new data is put into the lock-txn,
>> overwriting whatever was previously there. (And obviously, if the
>> writer doesn't own the lock-txn, the write is rejected.)
>>
>> * When somebody tries to read from a non-HEAD revision, everything
>> is normal. When somebody tries to read from the HEAD revision,
>> the system treats locked paths specially: instead of pulling the
>> file's data out of the HEAD revision, it gets pulled out of the
>> appropriate lock-txn.
>>
>> * The lock-owner ultimately ends up "unlocking" the file, which
>> causes the lock-txn to be committed. Either that, or the lock
>> owner destroys the lock, which aborts the lock-txn, and all
>> changes are lost.
>>
>>
>
>My first impression is that this scheme adds significant complexity,
>where a simpler method would suffice. The simpler method:
>
> - Have the a locks table which any client may access. Only one
> client may hold a lock for a given path.
>
>
That would make it impossible to implement shared locks
(a.k.a.notifications), and I don't think we want this restriction unless
it's really necessary, which I don't see at this point.
> - At commit time, the server may check the committed paths to see if
> any of them are protected by locks. Conceivably if all clients
> that wanted to edit a file were "nice" and held the lock before
> modifying it, then this check would not be necessary.
>
>
"The lock". Which lock? You still have to verify the authenticity of the
lock token. You don't want to allow your clients to spoof lock tokens...
>I talked on IRC with Ben about why the long-lived transactions were
>chosen over this simpler scheme. The motivation seemed to be that
>with DAV mounts, every single "auto-save" of a file would create a new
>revision. With committing a revision automatically upon UNLOCK,
>hopefully the number of revisions would decrease as most clients only
>issue an UNLOCK when they are truly done with the file.
>I think a simpler solution would be to attack this at the higher
>layers: either through DAV autoversioning,
>
A separate feature that we have now and will want to keep anyway...
> or the application layer.
>
>
Oh no, that's not acceptable. "If you want to use Word with a Subversion
server, turn off autosave". Yikes.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Josh Pieper <jj...@pobox.com>.
Ben Collins-Sussman wrote:
> The main idea is: a user "locks" a file in the filesystem. This means
> than a new (potentially) long-lived transaction is created in the
> filesystem which represents this one locked file. There's a 1-to-1
> mapping between a locked file and a lock-txn. We keep this mapping in
> a new 'locks' table that maps a path to a txn-id.
>
> * When somebody tries to write to any path, the filesystem checks to
> see if a lock-txn already exists for it. If so, and if the writer
> owns the lock-txn, then the new data is put into the lock-txn,
> overwriting whatever was previously there. (And obviously, if the
> writer doesn't own the lock-txn, the write is rejected.)
>
> * When somebody tries to read from a non-HEAD revision, everything
> is normal. When somebody tries to read from the HEAD revision,
> the system treats locked paths specially: instead of pulling the
> file's data out of the HEAD revision, it gets pulled out of the
> appropriate lock-txn.
>
> * The lock-owner ultimately ends up "unlocking" the file, which
> causes the lock-txn to be committed. Either that, or the lock
> owner destroys the lock, which aborts the lock-txn, and all
> changes are lost.
My first impression is that this scheme adds significant complexity,
where a simpler method would suffice. The simpler method:
- Have the a locks table which any client may access. Only one
client may hold a lock for a given path.
- At commit time, the server may check the committed paths to see if
any of them are protected by locks. Conceivably if all clients
that wanted to edit a file were "nice" and held the lock before
modifying it, then this check would not be necessary.
I talked on IRC with Ben about why the long-lived transactions were
chosen over this simpler scheme. The motivation seemed to be that
with DAV mounts, every single "auto-save" of a file would create a new
revision. With committing a revision automatically upon UNLOCK,
hopefully the number of revisions would decrease as most clients only
issue an UNLOCK when they are truly done with the file.
I think a simpler solution would be to attack this at the higher
layers: either through DAV autoversioning, or the application layer.
To fix it at the DAV lyer, you would just have the DAV layer perform a
commit for every PUT, except if that resource was locked, then perform
a commit every time a lock is release. This scheme does break the
property that every PUT is immediately seen by other clients, however
I think it is unwise to allow unversioned data to be transparently
propagated to other clients. How would the text-base work in that
case? The client would have no idea what version of a file it had
locally and thus no means for transmitting diffs to/from the server.
Alternatively this could be fixed at the application layer, by
turning off the "auto-save" feature.
-Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Julian Reschke <ju...@gmx.de>.
Ben Collins-Sussman wrote:
> On Wed, 2004-05-19 at 18:42, Greg Hudson wrote:
>
>>Well, as others have pointed out, you've invented something that works
>>for WebDAV and doesn't work for Subversion.
>
>
> Yeah, looks like a semantic incompatibility, eh?
>
> DAV says that every PUT to a resource, regardless of whether it's locked
> or not, should be GETtable by the whole world.
>
> Subversion then has the choice of (1) making every PUT into a commit,
> which can get very messy and annoying with most auto-saving DAV clients,
> or (2) violate DAV, and make a lock-holder's GET show something
> different than what the general public sees.
>
> Gstein, our resident DAV expert, has a proposal to resolve this. I just
> alerted him to this thread, so he'll be posting shortly.
This sounds a bit like we have two entirely different use cases, and
trying to implement them using one mechanism (not surpringly) doesn't
work well.
Case #1: "Edit with Office (Word)"
As others have pointed out, Office LOCKs the file, and sends PUT each
time the clients saves (not sure about auto-saving). It also refreshes
the lock each 180 seconds (WebDAV locks may come with a timeout; but
that's optional). Only when the file is closed, Office sends a PUT and a
final UNLOCK.
Most people will expect (and RFC2518 requires this) that any change that
was PUT will be visible to other users (note if it's not you will also
have to consider HTTP caching!).
This scenario works absolutely wonderful with a server that supports
RFC32523-style autoversioning (I think svn does). See
<http://greenbytes.de/tech/webdav/rfc3253.html#PROPERTY_auto-version>.
Case #2: "Lock through SVN client"
I hear that this shouldn't only keep other people from modifying the
file, it also shouldn't publish changes to other users until the svn
lock is gone. It seems to me that the simple answer to this *extended*
requirement is not use WebDAV LOCK/UNLOCK alone, but also to use
RFC3253's working resources.
In the case where a single file is locked this would mean:
- LOCK the file (keep others from modifying it)
- CHECKOUT a working resource
<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.9>), this
creates a new version controlled resource (with a new URI)
- (possibly LOCK that one as well)
- keep modifying (GET/PUT)
- CHECKIN and UNLOCK original resource
This will satisfy the requirement of the contents of the original file
not changing until the transaction is finished.
Best regards, Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>On Wed, 2004-05-19 at 19:29, Ben Collins-Sussman wrote:
>
>
>
>>Subversion then has the choice of (1) making every PUT into a commit,
>>which can get very messy and annoying with most auto-saving DAV clients,
>>or (2) violate DAV, and make a lock-holder's GET show something
>>different than what the general public sees.
>>
>>
>
>Let me follow up to myself, and repeat a point ghudson has made on IRC.
>
>"Auto-saving" isn't the real problem here. We're talking about a user
>that opens a file directly from a repository with MS-Word (LOCK), then
>deliberately hits Control-S every few minutes to save progress (PUT),
>then ultimately closes the document (UNLOCK).
>
>Perhaps the "lots of revisions" issue really isn't an issue at all.
>
>
Then my suggestion to make a PUT to a locked file be a checkpoint (write
+ commit, keep locked), instead of just a simple write, fits this
observation like a glove. Yes?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-05-19 at 19:29, Ben Collins-Sussman wrote:
> Subversion then has the choice of (1) making every PUT into a commit,
> which can get very messy and annoying with most auto-saving DAV clients,
> or (2) violate DAV, and make a lock-holder's GET show something
> different than what the general public sees.
Let me follow up to myself, and repeat a point ghudson has made on IRC.
"Auto-saving" isn't the real problem here. We're talking about a user
that opens a file directly from a repository with MS-Word (LOCK), then
deliberately hits Control-S every few minutes to save progress (PUT),
then ultimately closes the document (UNLOCK).
Perhaps the "lots of revisions" issue really isn't an issue at all.
Here's the IRC excerpt:
<ghudson> Anyway, if a user is compulsively hitting save, then it seems
like the user has asked to commit whatever changes have been made. It
would be weird for us to toss the history of save events just because
they were all done during the possession of a single lock.
<ghudson> It would be like if a user repeatedly ran C-x C-q to check in
an emacs file after making small changes, and we somehow detected that
it was all done within a single emacs session and tossed all but the
last commit.
<sussman> hm
<sussman> I can buy that argument.
<ghudson> I can understand wanting a versioning filesystem, where every
change is made with history and nothing is lost. I can understand
wanting a version-control client, where you make a conscious decision to
commit a related set of changes all at once. I don't get this idea of
trying to heuristically guess at the right granularity of changes to
automatically save.
<sussman> it's pretty hard to make that guess.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-05-19 at 18:42, Greg Hudson wrote:
> Well, as others have pointed out, you've invented something that works
> for WebDAV and doesn't work for Subversion.
Yeah, looks like a semantic incompatibility, eh?
DAV says that every PUT to a resource, regardless of whether it's locked
or not, should be GETtable by the whole world.
Subversion then has the choice of (1) making every PUT into a commit,
which can get very messy and annoying with most auto-saving DAV clients,
or (2) violate DAV, and make a lock-holder's GET show something
different than what the general public sees.
Gstein, our resident DAV expert, has a proposal to resolve this. I just
alerted him to this thread, so he'll be posting shortly.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>Well, as others have pointed out, you've invented something that works
>for WebDAV and doesn't work for Subversion. It's not really a candidate
>for inclusion in Subversion if it won't work with Subversion clients.
>
>Branko's modified locking plan seems to have limited usefulness from the
>DAV client viewpoint; I'm editing a document in MS Office and I save it,
>but my co-worker over in the next cubicle can't see my changes unless I
>close the document (I assume that's when Office will do an unlock).
>
Yes, it is.
>If
>we're going to invent something that doesn't work for DAV, there are
>simpler ways to go about it.
>
>
"Doesn't work with DAV" is a strong way of putting it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Greg Hudson <gh...@MIT.EDU>.
Well, as others have pointed out, you've invented something that works
for WebDAV and doesn't work for Subversion. It's not really a candidate
for inclusion in Subversion if it won't work with Subversion clients.
Branko's modified locking plan seems to have limited usefulness from the
DAV client viewpoint; I'm editing a document in MS Office and I save it,
but my co-worker over in the next cubicle can't see my changes unless I
close the document (I assume that's when Office will do an unlock). If
we're going to invent something that doesn't work for DAV, there are
simpler ways to go about it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Branko Čibej <br...@xbc.nu>.
Florian Weimer wrote:
>* Branko Čibej:
>
>>> When somebody tries to read from the HEAD revision,
>>> the system treats locked paths specially: instead of pulling the
>>> file's data out of the HEAD revision, it gets pulled out of the
>>> appropriate lock-txn.
>>>
>>>
>>>
>>>
>>Nope.
>>
>> When anyone except the lock owner tries to read from the HEAD
>> revision, everything is normal. When the lock owner tries to read
>> from the HEAD revision, the system treats locked paths specially: ...
>>
>>The point here is that a lock on a file (or directory, don't forget
>>about depth-infinity directory locks) creates a transaction. The
>>isolation principle says that the results of activities that happen in
>>the context of a transaction are not visible outside this context
>>until the transaction is committed. In other words, only the lock
>>owner can see uncommitted changes to the locked file.
>>
>>
>
>By default, yes. Dirty reads on HEAD are too surprising, IMHO.
>
>
Indeed.
>But I think it should be possible to view the pending commit, as
>stored in the repository. This enables some nifty applications (for
>example, you could render a document on the server and have the
>creator review it, before it is actually committed). It's not clear
>that it's worth the additional complexity, though.
>
>
That is a separate issue and in fact a separate planned feature. I'm
sure it could be useful, but it has no bearing on the locking design.
>>> * The lock-owner ultimately ends up "unlocking" the file, which
>>> causes the lock-txn to be committed. Either that, or the lock
>>> owner destroys the lock, which aborts the lock-txn, and all
>>> changes are lost.
>>>
>>>
>>Ah...point of terminology here: "unlock" means "release the lock,
>>discarding changes"; "commit" means "release the lock, keeping
>>changes". It's much more obvious that way, and you don't have a third
>>destroy-lock function.
>>
>>
>If there's "commit", there also should be "abort" or "roll back".
>
>
My definition of "unlock" is exactly "abort".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Florian Weimer <fw...@deneb.enyo.de>.
* Branko Čibej:
>> When somebody tries to read from the HEAD revision,
>> the system treats locked paths specially: instead of pulling the
>> file's data out of the HEAD revision, it gets pulled out of the
>> appropriate lock-txn.
>>
>>
> Nope.
>
> When anyone except the lock owner tries to read from the HEAD
> revision, everything is normal. When the lock owner tries to read
> from the HEAD revision, the system treats locked paths specially: ...
>
> The point here is that a lock on a file (or directory, don't forget
> about depth-infinity directory locks) creates a transaction. The
> isolation principle says that the results of activities that happen in
> the context of a transaction are not visible outside this context
> until the transaction is committed. In other words, only the lock
> owner can see uncommitted changes to the locked file.
By default, yes. Dirty reads on HEAD are too surprising, IMHO.
But I think it should be possible to view the pending commit, as
stored in the repository. This enables some nifty applications (for
example, you could render a document on the server and have the
creator review it, before it is actually committed). It's not clear
that it's worth the additional complexity, though.
>> * The lock-owner ultimately ends up "unlocking" the file, which
>> causes the lock-txn to be committed. Either that, or the lock
>> owner destroys the lock, which aborts the lock-txn, and all
>> changes are lost.
>>
>>
> Ah...point of terminology here: "unlock" means "release the lock,
> discarding changes"; "commit" means "release the lock, keeping
> changes". It's much more obvious that way, and you don't have a third
> destroy-lock function.
If there's "commit", there also should be "abort" or "roll back".
It seems I should read something on MVCC at this point...
--
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: bigpond.com, di-ve.com, hotmail.com, jumpy.it,
libero.it, netscape.net, postino.it, simplesnet.pt, spymac.com,
tatanova.com, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr, yahoo.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>The main idea is: a user "locks" a file in the filesystem. This means
>than a new (potentially) long-lived transaction is created in the
>filesystem which represents this one locked file. There's a 1-to-1
>mapping between a locked file and a lock-txn. We keep this mapping in
>a new 'locks' table that maps a path to a txn-id.
>
> * When somebody tries to write to any path, the filesystem checks to
> see if a lock-txn already exists for it. If so, and if the writer
> owns the lock-txn, then the new data is put into the lock-txn,
> overwriting whatever was previously there. (And obviously, if the
> writer doesn't own the lock-txn, the write is rejected.)
>
>
O.K.
> * When somebody tries to read from a non-HEAD revision, everything
> is normal.
>
O.K.
> When somebody tries to read from the HEAD revision,
> the system treats locked paths specially: instead of pulling the
> file's data out of the HEAD revision, it gets pulled out of the
> appropriate lock-txn.
>
>
Nope.
When anyone except the lock owner tries to read from the HEAD
revision, everything is normal. When the lock owner tries to read
from the HEAD revision, the system treats locked paths specially: ...
The point here is that a lock on a file (or directory, don't forget
about depth-infinity directory locks) creates a transaction. The
isolation principle says that the results of activities that happen in
the context of a transaction are not visible outside this context until
the transaction is committed. In other words, only the lock owner can
see uncommitted changes to the locked file.
This is consistent with current behaviour of SVN's commit transactions.
One benefit is that the locks table doesn't have to be checked on read
operations _except_ if a lock ID is provided.
I realise this is a change from the current locking-plan.txt, but I
believe it's a necessary change. I also understand that this behaviour
is different from the DAV spec, but that doesn't worry me because an
unrelated DAV client can't actually *prove* that we're hiding the
locker's PUTs from him. Several cooperating DAV clients that share the
changed contents of a locked file should be sharing the lock token, too.
> * The lock-owner ultimately ends up "unlocking" the file, which
> causes the lock-txn to be committed. Either that, or the lock
> owner destroys the lock, which aborts the lock-txn, and all
> changes are lost.
>
>
Ah...point of terminology here: "unlock" means "release the lock,
discarding changes"; "commit" means "release the lock, keeping changes".
It's much more obvious that way, and you don't have a third destroy-lock
function.
>The net affect of this (from a WebDAV client's point of view) is that
>a user can LOCK a file indefinitely and do any number of PUTs to it.
>
>
Yes.
>People who do checkouts of HEAD, or just GETs of the file, will always
>see the file's latest text (that is, whatever text was most recently
>PUT by the lock-owner.)
>
No, as per above.
> If somebody else tries to do a normal
>Subversion commit which includes a change the locked file, the entire
>commit will be rejected. Ultimately the owner UNLOCKs the file and a
>new revision is created.
>
>
Yes. Note that the meaning of the DAV UNLOCK method is not the same as
the meaning of svn_fs_unlock should be, but we should not let DAV
nomenclature drive our design.
>Really, we envision at least two APIs to end the lifecycle of a
>lock-txn:
>
> 1. A call to svn_fs_unlock() will attempt to commit a single
> lock-txn and create a new revision.
>
> 2. A new svn_fs_commit_txn2() function will take a "main" txn as
> usual, but also take a list of lock-txns. It would first merge
> the lock-txns into the main txn, then merge the whole thing with
> the HEAD revision.
>
>
As I said, svn_fs_unlock should mean something else; othewise, it's just
a synonym for svn_fs_commit_txn2 with a NULL main txn ID and a single
entry in the lock list.
>Depending on how we design the new commit function, we might also want
>to give users the option to "hold on" to their lock-txns after the
>commit completes. (In other words, delete the temporary main txn, but
>not the lock-txns.)
>
>
Yes, this is usually the check-in command's "keep checked out" option in
locking VC systems; sometimes known as "checkpoint" instead of "check-in".
Note that if you want to completely simulate DAV behaviour, then PUT on
a locked object could be implemented as a checkpoint rather than a
checkin; and UNLOCK suddenly becomes the same as svn_fs_unlock. The
drawback is that you generate a new revision with each PUT.
>There's at least one annoyance with this design: operations like
>'move' and 'delete' must verify that no locks exist for paths below
>the deleted/moved thing. This requires scanning the table of locked
>paths, or doing a 'reverse directory walk'. Actually, it may be slow
>in general to scan a locks-table -- we're talking about doing it for
>every read of a path@HEAD and every write of a path.
>
>
A reverse directory walk is not necessary if the locks table is designed
correctly (in fact, correct layout of the locks table is *the*
interaction point between locks and ACLs; since both features require a
lookup table, it makes sense to use the same table and do the lookup
once). I'll talk about the structure of the lookup (locks) table in a
separate post.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Branko Čibej <br...@xbc.nu>.
Jani Averbach wrote:
>On 2004-05-19 16:54-0500, Ben Collins-Sussman wrote:
>
>
>
>> * When somebody tries to write to any path, the filesystem checks to
>> see if a lock-txn already exists for it. If so, and if the writer
>> owns the lock-txn, then the new data is put into the lock-txn,
>> overwriting whatever was previously there. (And obviously, if the
>> writer doesn't own the lock-txn, the write is rejected.)
>>
>> * When somebody tries to read from a non-HEAD revision, everything
>> is normal. When somebody tries to read from the HEAD revision,
>> the system treats locked paths specially: instead of pulling the
>> file's data out of the HEAD revision, it gets pulled out of the
>> appropriate lock-txn.
>>
>> * The lock-owner ultimately ends up "unlocking" the file, which
>> causes the lock-txn to be committed. Either that, or the lock
>> owner destroys the lock, which aborts the lock-txn, and all
>> changes are lost.
>>
>>The net affect of this (from a WebDAV client's point of view) is that
>>a user can LOCK a file indefinitely and do any number of PUTs to it.
>>People who do checkouts of HEAD, or just GETs of the file, will always
>>see the file's latest text (that is, whatever text was most recently
>>PUT by the lock-owner.)
>>
>>
>
>I see following problems with this behavior:
>
>1) You could get a version X of file at time T, and later, get a
> different content for the same file, for same version X.
>
> <http://svnbook.red-bean.com/svnbook/apa.html#svn-ap-a-sect-1>
>
> "In Subversion, the repository looks like a single
> filesystem. Each commit results in an entirely new filesystem
> tree; in essence, the repository is an array of trees. Each of
> these trees is labeled with a single revision number. When
> someone talks about .revision 54., they're talking about a
> particular tree (and indirectly, the way the filesystem looked
> after the 54th commit)."
>
> So you could now have two or more different trees for same version
> number. I think that this is a problem.
>
>2) You could get a particular content for file (at version X), and
> later find that this data has vanished completely from system (Locker
> has done an unlock). This is problematic, because a version control
> system should let traces of all data that it handles, imho.
>
>
Do you know I completely forgot about this argument? And it's better
than mine.
>Ben told in IRC that this behavior is by WebDAV spec: every PUT to
>the locked object is visible to the world.
>
>
That's true, IMHO broken, but also irrelevent, I think.
>Ben suggested that it might be possible to make lock-txns only
>readable to the locker, when other world won't get mutable data from
>HEAD. I am huge fan of that idea, and will purchase fans and flags
>and wave them maniacally, if this semantic will be chosen for
>Subversion.
>
>
+1eU+03C0 GREEK SMALL LETTER PI
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Exclusive Locking: design in a nutshell
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2004-05-19 16:54-0500, Ben Collins-Sussman wrote:
> * When somebody tries to write to any path, the filesystem checks to
> see if a lock-txn already exists for it. If so, and if the writer
> owns the lock-txn, then the new data is put into the lock-txn,
> overwriting whatever was previously there. (And obviously, if the
> writer doesn't own the lock-txn, the write is rejected.)
>
> * When somebody tries to read from a non-HEAD revision, everything
> is normal. When somebody tries to read from the HEAD revision,
> the system treats locked paths specially: instead of pulling the
> file's data out of the HEAD revision, it gets pulled out of the
> appropriate lock-txn.
>
> * The lock-owner ultimately ends up "unlocking" the file, which
> causes the lock-txn to be committed. Either that, or the lock
> owner destroys the lock, which aborts the lock-txn, and all
> changes are lost.
>
> The net affect of this (from a WebDAV client's point of view) is that
> a user can LOCK a file indefinitely and do any number of PUTs to it.
> People who do checkouts of HEAD, or just GETs of the file, will always
> see the file's latest text (that is, whatever text was most recently
> PUT by the lock-owner.)
I see following problems with this behavior:
1) You could get a version X of file at time T, and later, get a
different content for the same file, for same version X.
<http://svnbook.red-bean.com/svnbook/apa.html#svn-ap-a-sect-1>
"In Subversion, the repository looks like a single
filesystem. Each commit results in an entirely new filesystem
tree; in essence, the repository is an array of trees. Each of
these trees is labeled with a single revision number. When
someone talks about .revision 54., they're talking about a
particular tree (and indirectly, the way the filesystem looked
after the 54th commit)."
So you could now have two or more different trees for same version
number. I think that this is a problem.
2) You could get a particular content for file (at version X), and
later find that this data has vanished completely from system (Locker
has done an unlock). This is problematic, because a version control
system should let traces of all data that it handles, imho.
Ben told in IRC that this behavior is by WebDAV spec: every PUT to
the locked object is visible to the world.
Ben suggested that it might be possible to make lock-txns only
readable to the locker, when other world won't get mutable data from
HEAD. I am huge fan of that idea, and will purchase fans and flags
and wave them maniacally, if this semantic will be chosen for
Subversion.
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org