You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2004/10/12 20:52:47 UTC
Locking UI comments
I've discussed most of these with Ben and others on IRC, but that's
not the proper forum for resolving contentious issues. So, here are
my reactions to notes/locking/locking-ui.txt:
Issue #1: Should "svn lock" implicitly include "svn update"?
The document says yes. I believe that it is not intuitive for the
verb "lock" to include an implicit update, and people may be surprised
by the "helpful" behavior. Instead, I think lock should error out if
the file is not up to date, with the error message instructing the
user to update the file. (I'm fine with an explicit "svn lock
--update" if and only if there is a considered belief that it would be
a real convenience for users.)
As I understand things, Ben's rationale for locking-implicitly-updates
is to mirror the behavior of other version control systems which are
either non-concurrent (VSS) or non-concurrent by default (Clearcase).
(It wouldn't be a very perfect mirror; in those systems, it's not so
much "locking implicitly updates" as "checking out implicitly locks.)
I don't think it's a good idea to model our default behavior after a
non-concurrent version control system; we will wind up looking
schizoprenic.
If we want to change the verb to "grab" or "reserve", then maybe it
would be okay to perform an implicit update, but I don't see what's
wrong with just erroring out if the file is not up to date.
Issue #2: Should "svn update" resolve hijacks interactively?
When people or their tools fail to play nicely, Subversion will find
itself in the situation of having to resolve conflicts in a file which
(through the svn:lock property) has been tagged as unmergeable. The
document suggests resolving this issue by interactively asking the
user whether to prefer the local edit or the repository edit, and
leaving the other behind in a backup file.
I believe this is a total non-starter. It has the same problems as
setting diff3 to an interactive merge program--the server is sending
data to the client, and is going to time out if the client stops and
waits for user input. The proper answer is to leave behind enough
information in the WC for later resolution, as we do for merge
conflicts now.
Also, the svn command-line client is not designed to be highly
interactive, and bucking that trend lightly will result in serious
usability issues. If there are a thousand hijacks to deal with, are
we going to ask the user a thousand questions? A GUI can (and
probably should) tackle the hijacking issue by asking questions after
the update completes, but our command-line client should punt.
What we can do is alter our behavior on a conflict for a file which
has been tagged with the svn:lock property. Instead of generating a
conflict marker and perhaps attempting a merge, we can leave the local
edit in place, drop the repository edit into a backup file, and warn
the user. I'm not certain whether this is right or not.
Issue #3: Should lock messages be required?
The document says that "svn lock" should pull up an editor and demand
a lock message if the user does not provide one with the -m or -F
option. The implication is that a GUI like tsvn would also request a
lock message whenever the user locks a file (or files, if there's a
way to select a bunch of files and lock them all in one go).
I suspect that many users are either used to or would prefer
environments with no lock messages. If I want to know why Bob locked
a file, I'll ask him, but 95% of the time I'll never need to know, so
why should he write it down each time?
So, here are alternatives I would consider more palatable:
* Punt on lock messages for the initial implementation.
* Support lock messages, but only specify them if the user specifies
a -m or -F option on the "svn lock" command line.
* Use a file property (either the contents of svn:lock, or a
separate boolean property) to determine whether the UI should get
in the user's face about lock messages. Then a project can
decide, on a per-file basis, whether to require lock messages.
Issue #4: "svn lockinfo" command?
As you all know, I've very keen on keeping our command set small.
"svn lock" and "svn unlock" are pretty much non-negotiable for this
feature, but when we already have "svn status" and "svn info", do we
really need a separate "svn lockinfo"? I realize that svn info is a
client-local operation and lock information has to be fetched from the
server, but perhaps this could be an option to "svn info".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> On Wed, 2004-10-13 at 00:23, Brian W. Fitzpatrick wrote:
>
>>And the ability to have a server-side configuration rears its ugly head
>>again.
>
>
> A per-file property will do the job just fine now. We don't need global
> server-side configuration for this.
Read what Fitz wrote again; he didn't say /global/ server-side config. If the
server-side config was based on the path, it could be placed at the root of a
tree to be considered "global" for our purposes.
The problem is that apart from properties themselves, there is no metadata on
the repository that the client can query to alter local behavior, which is to
say, there is no server-side configuration in Subversion today. It would be
grossly inefficient to store a "must have lock message" on each of thousands of
files in a portion of a tree, if setting it once on the containing directory
would be sufficient. It's what I want to do for custom keywords as well.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2004-10-13 at 12:21, Brian W. Fitzpatrick wrote:
> > A per-file property will do the job just fine now. We don't need global
> > server-side configuration for this. We don't need global server-side
> > configuration for anything, in my opinion; everything which has been
> > proposed for global server-side configuration is something which users
> > might want to vary per subtree or per file.
>
> But you're assuming that the repository administrator wants this to be a
> user preference. I'm talking about enforcing a particular policy.
Well, then, wouldn't it be nice if we had an acl system which could
restrict users from setting particular properties on files?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Wed, 2004-10-13 at 00:19, Greg Hudson wrote:
> On Wed, 2004-10-13 at 00:23, Brian W. Fitzpatrick wrote:
> > > Ah, this came up on IRC. I don't think this is appropriate for a user
> > > pref. Really, for a given file (or project, in most cases, but policy
> > > might vary from place to place), all the users should agree on whether
> > > they're using locking messages or not. So a user pref has the wrong
> > > granularity; it applies to all files for a particular user, when we
> > > want
> > > the pref to apply to all users of a particular file.
> >
> > And the ability to have a server-side configuration rears its ugly head
> > again.
>
> A per-file property will do the job just fine now. We don't need global
> server-side configuration for this. We don't need global server-side
> configuration for anything, in my opinion; everything which has been
> proposed for global server-side configuration is something which users
> might want to vary per subtree or per file.
But you're assuming that the repository administrator wants this to be a
user preference. I'm talking about enforcing a particular policy.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2004-10-13 at 00:23, Brian W. Fitzpatrick wrote:
> > Ah, this came up on IRC. I don't think this is appropriate for a user
> > pref. Really, for a given file (or project, in most cases, but policy
> > might vary from place to place), all the users should agree on whether
> > they're using locking messages or not. So a user pref has the wrong
> > granularity; it applies to all files for a particular user, when we
> > want
> > the pref to apply to all users of a particular file.
>
> And the ability to have a server-side configuration rears its ugly head
> again.
A per-file property will do the job just fine now. We don't need global
server-side configuration for this. We don't need global server-side
configuration for anything, in my opinion; everything which has been
proposed for global server-side configuration is something which users
might want to vary per subtree or per file.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Oct 12, 2004, at 5:17 PM, Greg Hudson wrote:
> On Tue, 2004-10-12 at 18:06, Philip Martin wrote:
>> * Provide a .subversion/config default-lock-message that gets used
>> if neither -m nor -F is used. Then the user can decide whether
>> they get asked or not.
>
> Ah, this came up on IRC. I don't think this is appropriate for a user
> pref. Really, for a given file (or project, in most cases, but policy
> might vary from place to place), all the users should agree on whether
> they're using locking messages or not. So a user pref has the wrong
> granularity; it applies to all files for a particular user, when we
> want
> the pref to apply to all users of a particular file.
And the ability to have a server-side configuration rears its ugly head
again.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2004-10-12 at 18:06, Philip Martin wrote:
> * Provide a .subversion/config default-lock-message that gets used
> if neither -m nor -F is used. Then the user can decide whether
> they get asked or not.
Ah, this came up on IRC. I don't think this is appropriate for a user
pref. Really, for a given file (or project, in most cases, but policy
might vary from place to place), all the users should agree on whether
they're using locking messages or not. So a user pref has the wrong
granularity; it applies to all files for a particular user, when we want
the pref to apply to all users of a particular file.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Philip Martin <ph...@codematters.co.uk>.
Greg Hudson <gh...@MIT.EDU> writes:
> Issue #1: Should "svn lock" implicitly include "svn update"?
>
> The document says yes. I believe that it is not intuitive for the
> verb "lock" to include an implicit update, and people may be surprised
> by the "helpful" behavior. Instead, I think lock should error out if
> the file is not up to date, with the error message instructing the
> user to update the file.
I agree with Greg. Another argument against implicit updates is that
lock would need to provide a --diff3-cmd option, and a user who
routinely uses --diff3-cmd on update may forget that it needs to be
used on lock as well.
> Issue #3: Should lock messages be required?
>
> The document says that "svn lock" should pull up an editor and demand
> a lock message if the user does not provide one with the -m or -F
> option. The implication is that a GUI like tsvn would also request a
> lock message whenever the user locks a file (or files, if there's a
> way to select a bunch of files and lock them all in one go).
>
> I suspect that many users are either used to or would prefer
> environments with no lock messages. If I want to know why Bob locked
> a file, I'll ask him, but 95% of the time I'll never need to know, so
> why should he write it down each time?
I agree again. It's not clear from the functional spec whether a lock
continues to exist in the database once it's released/broken. I
assume it gets deleted (although I suppose it might get moved from an
active to an inactive list) in which case the locks are transient and
I'm not keen on forcing users to supply log messages for transient
objects.
> So, here are alternatives I would consider more palatable:
>
> * Punt on lock messages for the initial implementation.
>
> * Support lock messages, but only specify them if the user specifies
> a -m or -F option on the "svn lock" command line.
>
> * Use a file property (either the contents of svn:lock, or a
> separate boolean property) to determine whether the UI should get
> in the user's face about lock messages. Then a project can
> decide, on a per-file basis, whether to require lock messages.
* Provide a .subversion/config default-lock-message that gets used
if neither -m nor -F is used. Then the user can decide whether
they get asked or not.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>What we can do is alter our behavior on a conflict for a file which
>has been tagged with the svn:lock property. Instead of generating a
>conflict marker and perhaps attempting a merge, we can leave the local
>edit in place, drop the repository edit into a backup file, and warn
>the user. I'm not certain whether this is right or not.
>
>
I think svn should behave exactly as with "normal" conflicts, _except_
that it should not try to merge changes into the working copy --
regardless of whether the working copy has actually changed from BASE.
For UI purposes, we could show an H(ijack) instead of a C(onflict), but
the same information may well be conveyed by "svn st" marking the file
as locked in the WC.
>As you all know, I've very keen on keeping our command set small.
>"svn lock" and "svn unlock" are pretty much non-negotiable for this
>feature, but when we already have "svn status" and "svn info", do we
>really need a separate "svn lockinfo"? I realize that svn info is a
>client-local operation and lock information has to be fetched from the
>server, but perhaps this could be an option to "svn info".
>
>
Obviously both "svn info" and "svn st" must show a certain amount of
lock information. There's no reason why "svn info" shouldn't optionally
contact the server (with -u) or work with URLs. In fact "svn st" could
work with URLs, too, and suddenly "svn info" becomes another way of
spelling "svn status --very-verbose" :-)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, October 13, 2004 1:16 PM -0400 Mark Benedetto King
<mb...@lowlatency.com> wrote:
> I am not familiar with TSVN, but I have witnessed the horror that is
> WinCVS. It is basically a GUI wrapper around the fundamental CVS
> operations; it does not provide an improved UI, just one that involves
> clicking instead of typing. The CVS boolean command options are
> exposed as checkboxes. In such a framework, it would be Just Plain
> Wrong to invert the default.
Speaking as someone who has supported a gaggle of semi-clueless users (aka
students), TortoiseSVN is *way* better than WinCVS. If your GUI is just a
thin wrapper, then it should respect the defaults of our cmd-line interface.
But, TortoiseSVN, Subclipse, SCPlugin, etc. are more than that. And,
accordingly, they might alter their defaults to fit their users... -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Mark Benedetto King <mb...@lowlatency.com>.
On Wed, Oct 13, 2004 at 02:06:06PM +0200, Sander Striker wrote:
> > From: Mark Benedetto King [mailto:mbk@lowlatency.com]
> > Sent: Wednesday, October 13, 2004 1:54 PM
>
> > Well, one counter argument is that many people will forget to release
> > their locks.
>
> As long as locks are breakable/stealable, I don't really see the problem.
>
> > RCS's ci requires "-l" to keep the lock; i.e., releasing it is not the
> > default.
>
> Is or isn't it the default?
Sorry, I misspoke: releasing it is the default in RCS.
> >> I just don't think it's intuitive for 'svn commit' to release the lock
> >> when I explicitly requested it with 'svn lock.' 'svn unlock' should
> >> be the desired usage path we lead users towards. (UIs like TSVN or
> >> whatnot can have a checkbox for allowing the user to release the lock
> >> on commit. I'm only concerned about what our command-line GUI does.)
>
> > Shifting the default between UIs is evil. It would be nice if TSVN
> > users and command-line users could expect similar semantics from the
> > logical operations that they perform.
>
> Well, I disagree here. On commit TSVN is able to show unversioned
> files which can be added when you 'Commit'. Showing locks and being
> able to release them at that same point in the GUI seems logical.
> But I digress...
I agree that GUIs should be able to provider a richer UI, but providing
a nearly equivalent one that differs only in that the default operation
is inverted would be a source of confusion.
For example:
I am not familiar with TSVN, but I have witnessed the horror that is
WinCVS. It is basically a GUI wrapper around the fundamental CVS
operations; it does not provide an improved UI, just one that involves
clicking instead of typing. The CVS boolean command options are
exposed as checkboxes. In such a framework, it would be Just Plain
Wrong to invert the default.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Locking UI comments
Posted by Sander Striker <st...@apache.org>.
> From: Mark Benedetto King [mailto:mbk@lowlatency.com]
> Sent: Wednesday, October 13, 2004 1:54 PM
> Well, one counter argument is that many people will forget to release
> their locks.
As long as locks are breakable/stealable, I don't really see the problem.
> RCS's ci requires "-l" to keep the lock; i.e., releasing it is not the
> default.
Is or isn't it the default?
> VSS requires a non-default checkbox. I'm not familiar with the locking
> functionality in any other SCMs, so I can't produce other examples.
>> I just don't think it's intuitive for 'svn commit' to release the lock
>> when I explicitly requested it with 'svn lock.' 'svn unlock' should
>> be the desired usage path we lead users towards. (UIs like TSVN or
>> whatnot can have a checkbox for allowing the user to release the lock
>> on commit. I'm only concerned about what our command-line GUI does.)
> Shifting the default between UIs is evil. It would be nice if TSVN
> users and command-line users could expect similar semantics from the
> logical operations that they perform.
Well, I disagree here. On commit TSVN is able to show unversioned
files which can be added when you 'Commit'. Showing locks and being
able to release them at that same point in the GUI seems logical.
But I digress...
Keeping the lock by default seems the best option to me. An explicit
lock is followed by an explicit unlock.
>> I suppose keeping the lock by default would be more palatable to me
>> if the commit feedback process reminded users of their open locks:
>>
>> $ svn commit -F msg foo.c
>> Sending foo.c (keeping lock)
>> Transmitting file data.
>> Committed revision 42.
>>
>> or, alternatively
>>
>> $ svn commit -F msg foo.c
>> Sending foo.c
>> Keeping lock on foo.c
>> Transmitting file data.
>> Committed revision 42.
+1 (in concept).
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Mark Benedetto King <mb...@lowlatency.com>.
On Tue, Oct 12, 2004 at 11:29:54PM -0700, Justin Erenkrantz wrote:
>
> Issue #5: Should 'svn commit' release a lock?
>
> I don't think so. I think that if a lock is explicitly requested, then it
> needs to (by default) be explicitly released. I'd reverse the commit
> behavior and have '--release-lock' be an option: the default should be to
> keep the lock.
>
> Here's a use case that I think is more common than not: I lock a file, I
> want to make some changes to the file. It's 5pm and I want to go home for
> the day, so I commit my changes so I can checkpoint my work (after all,
> that's the point of a SCM). By checking it in, I can let other people view
> my progress, but I still want to reflect to everyone else that I still have
> the lock on the file. (That is, if you break or steal it, be aware that I
> was doing something with it.)
>
Well, one counter argument is that many people will forget to release
their locks.
RCS's ci requires "-l" to keep the lock; i.e., releasing it is not the
default. VSS requires a non-default checkbox. I'm not familiar with
the locking functionality in any other SCMs, so I can't produce other
examples.
> I just don't think it's intuitive for 'svn commit' to release the lock when
> I explicitly requested it with 'svn lock.' 'svn unlock' should be the
> desired usage path we lead users towards. (UIs like TSVN or whatnot can
> have a checkbox for allowing the user to release the lock on commit. I'm
> only concerned about what our command-line GUI does.)
>
Shifting the default between UIs is evil. It would be nice if TSVN users
and command-line users could expect similar semantics from the logical
operations that they perform.
I suppose keeping the lock by default would be more palatable to me if
the commit feedback process reminded users of their open locks:
$ svn commit -F msg foo.c
Sending foo.c (keeping lock)
Transmitting file data.
Committed revision 42.
or, alternatively
$ svn commit -F msg foo.c
Sending foo.c
Keeping lock on foo.c
Transmitting file data.
Committed revision 42.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, October 13, 2004 5:31 PM -0400 Mark Benedetto King
<mb...@lowlatency.com> wrote:
> Blind LOCKing is something that a normal WebDAV client could do, but that
> doesn't prevent us from supporting a LOCK request that does automatic and
> atomic update-to-dateness checking; I don't think they're mutually
> exclusive.
Agreed. While I'm not quite clear how you could shoe-horn in the youngest
revision into the LOCK request, but if you could so, that might be
acceptable. (ETag with If header?) Yet, the server will just have to
accept that not every client will know the revision. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Mark Benedetto King <mb...@lowlatency.com>.
On Thu, Oct 14, 2004 at 12:49:20PM -0400, Greg Hudson wrote:
> On Thu, 2004-10-14 at 11:31, Brian W. Fitzpatrick wrote:
> > > Blind LOCKing is something that a normal WebDAV client could do, but that
> > > doesn't prevent us from supporting a LOCK request that does automatic and
> > > atomic update-to-dateness checking; I don't think they're mutually
> > > exclusive.
> >
> > Agreed.
>
> There's no need to invent extra protocol machinery. The client can
> issue a LOCK request (blowing out if someone else already holds the
> lock), then check for up-to-dateness, and then release the lock if it's
> not up to date. This is perfectly atomic.
>
At the time I was thinking that the need for an explicit release
could cause locks to be leaked in the event of network/kernel/application
interrupts after the lock acquisition but before the release.
I realize now that since we don't 2PC the operation, even my more
"test and set" oriented approach is insufficient to prevent lock leaks.
Considering that "rm -rf wc" is enough to also leak the lock, and that
the locking system already includes the capability for users to handle
the case of abandoned locks, I think it makes sense to consider these
potentially leaked lock references as simply unintentionally abandoned.
IOW, I agree.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2004-10-14 at 11:31, Brian W. Fitzpatrick wrote:
> > Blind LOCKing is something that a normal WebDAV client could do, but that
> > doesn't prevent us from supporting a LOCK request that does automatic and
> > atomic update-to-dateness checking; I don't think they're mutually
> > exclusive.
>
> Agreed.
There's no need to invent extra protocol machinery. The client can
issue a LOCK request (blowing out if someone else already holds the
lock), then check for up-to-dateness, and then release the lock if it's
not up to date. This is perfectly atomic.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Wed, 2004-10-13 at 16:31, Mark Benedetto King wrote:
> On Wed, Oct 13, 2004 at 03:30:59PM -0500, Brian W. Fitzpatrick wrote:
> > On Wed, 2004-10-13 at 14:13, Justin Erenkrantz wrote:
> > > --On Wednesday, October 13, 2004 1:22 PM -0400 Mark Benedetto King
> > > <mb...@lowlatency.com> wrote:
> > >
> > > > I think it should be atomic, in the following way:
> > > >
> > > > Client -> Server
> > > >
> > > > LOCK /foo.c @ r1234
> > > >
> > > > Server -> Client
> > >
> > > FWIW, that won't mesh at all with WebDAV's LOCK model. In WebDAV, you just
> > > lock the entire resource not a specific version. So, at the very least, if we
> > > tried to lock a resource/version pair, we'd likely lock out most WebDAV
> > > clients from participating. And, that'd be real bad, IMHO. -- justin
> >
> > I don't understand the utility of locking a path at a specific
> > revision--you can't edit the contents of a revision.
> >
>
> That's not a peg notation, that's saying "I have revision 1234 of /foo.c and
> I want to acquire a lock on /foo.c".
Ah. OK. I got it now.
> The response from the server is either "okay, here is your lock token"
> or "sorry, that's not the youngest revision of /foo.c" or "sorry, something
> else has gone wrong".
*nod*
> Blind LOCKing is something that a normal WebDAV client could do, but that
> doesn't prevent us from supporting a LOCK request that does automatic and
> atomic update-to-dateness checking; I don't think they're mutually
> exclusive.
Agreed.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Mark Benedetto King <mb...@lowlatency.com>.
On Wed, Oct 13, 2004 at 03:30:59PM -0500, Brian W. Fitzpatrick wrote:
> On Wed, 2004-10-13 at 14:13, Justin Erenkrantz wrote:
> > --On Wednesday, October 13, 2004 1:22 PM -0400 Mark Benedetto King
> > <mb...@lowlatency.com> wrote:
> >
> > > I think it should be atomic, in the following way:
> > >
> > > Client -> Server
> > >
> > > LOCK /foo.c @ r1234
> > >
> > > Server -> Client
> >
> > FWIW, that won't mesh at all with WebDAV's LOCK model. In WebDAV, you just
> > lock the entire resource not a specific version. So, at the very least, if we
> > tried to lock a resource/version pair, we'd likely lock out most WebDAV
> > clients from participating. And, that'd be real bad, IMHO. -- justin
>
> I don't understand the utility of locking a path at a specific
> revision--you can't edit the contents of a revision.
>
That's not a peg notation, that's saying "I have revision 1234 of /foo.c and
I want to acquire a lock on /foo.c".
The response from the server is either "okay, here is your lock token"
or "sorry, that's not the youngest revision of /foo.c" or "sorry, something
else has gone wrong".
Blind LOCKing is something that a normal WebDAV client could do, but that
doesn't prevent us from supporting a LOCK request that does automatic and
atomic update-to-dateness checking; I don't think they're mutually
exclusive.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Julian Reschke <ju...@gmx.de>.
Justin Erenkrantz wrote:
> --On Thursday, October 14, 2004 9:43 AM +0200 Julian Reschke
> <ju...@gmx.de> wrote:
>
>> I'd call a client that requires a LOCK before GET a poor
>> implementation (if
>> it only wants to read the file). A LOCK doesn't guarantee you the
>> "youngest"
>> revision any more than GET. All it guarantees is that nobody changes the
>> resource between the LOCK and the GET (so you win exactly nothing
>> compared
>> to doing the GET right away).
>
>
> No. The initial argument was that 'svn lock' implicitly does 'svn
> update.' Therefore, if we go down this path (which I don't want us to,
> FWIW: they should be separate operations), I believe the ordering is
> critical because 'svn lock' is implying that the user has the absolute
> latest version before they do a write operation locally. If you did a
> GET and then a LOCK, it's feasible that you don't have the latest
> version locally and the 'svn lock' behavior doesn't match the
> expectation. -- justin
OK, confusion. I was talking about WebDAV clients in general: doing a
LOCK just to make sure you have the 'latest' version doesn't make sense
unless you are really going to lock the resource. From RFC2518's point
of view, GET always gets you the latest content anyway. The best way to
avoid overlapping updates (PUTting back something that somebody else has
modified since) is to add a check on the entity tag using the "If-Match"
request header.
So yes, if you actually do want to LOCK the resource, LOCK it first,
*then* get the content.
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: Locking UI comments
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, October 14, 2004 9:43 AM +0200 Julian Reschke
<ju...@gmx.de> wrote:
> I'd call a client that requires a LOCK before GET a poor implementation (if
> it only wants to read the file). A LOCK doesn't guarantee you the "youngest"
> revision any more than GET. All it guarantees is that nobody changes the
> resource between the LOCK and the GET (so you win exactly nothing compared
> to doing the GET right away).
No. The initial argument was that 'svn lock' implicitly does 'svn update.'
Therefore, if we go down this path (which I don't want us to, FWIW: they
should be separate operations), I believe the ordering is critical because
'svn lock' is implying that the user has the absolute latest version before
they do a write operation locally. If you did a GET and then a LOCK, it's
feasible that you don't have the latest version locally and the 'svn lock'
behavior doesn't match the expectation. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Julian Reschke <ju...@gmx.de>.
Justin Erenkrantz wrote:
> ...
> I think you are restricting yourself to only Subversion as a client.
> I'm purposely thinking of Adobe Photoshop with its integrated
> WebDAV-aware client which supports locking. Photoshop will issue a LOCK
> on a resource, but it has no concept of a 'youngest' revision. You
> couldn't even tell it that. However, this is also why most WebDAV
> clients issue a LOCK then issue a GET. This ensures that they get the
> 'youngest' revision of the resource after they acquired the lock. --
> justin
I'd call a client that requires a LOCK before GET a poor implementation
(if it only wants to read the file). A LOCK doesn't guarantee you the
"youngest" revision any more than GET. All it guarantees is that nobody
changes the resource between the LOCK and the GET (so you win exactly
nothing compared to doing the GET right away).
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: Locking UI comments
Posted by Mark Phippard <Ma...@softlanding.com>.
Justin Erenkrantz <ju...@erenkrantz.com> wrote on 10/13/2004 05:12:50 PM:
> --On Wednesday, October 13, 2004 4:37 PM -0400 Mark Phippard
> <Ma...@softlanding.com> wrote:
>
> > Plus, we have established that you can only lock the youngest revision
> > anyway, or more specifically your WC has to have the youngest
revision.
>
> I think you are restricting yourself to only Subversion as a client. I'm
> purposely thinking of Adobe Photoshop with its integrated WebDAV-aware
> client which supports locking. Photoshop will issue a LOCK on a
resource,
> but it has no concept of a 'youngest' revision. You couldn't even tell
it
> that. However, this is also why most WebDAV clients issue a LOCK then
> issue a GET. This ensures that they get the 'youngest' revision of the
> resource after they acquired the lock. -- justin
Actually, I was considering that. In the WebDAV example, the server is
just going to give the client the correct version. My point was that
since there is nothing in the proposed spec that would allow you to
explicitly or implicitly lock anything other than the latest revision,
there should not be any problem supporting the WebDAV concepts you have
outlined.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, October 13, 2004 4:37 PM -0400 Mark Phippard
<Ma...@softlanding.com> wrote:
> Plus, we have established that you can only lock the youngest revision
> anyway, or more specifically your WC has to have the youngest revision.
I think you are restricting yourself to only Subversion as a client. I'm
purposely thinking of Adobe Photoshop with its integrated WebDAV-aware
client which supports locking. Photoshop will issue a LOCK on a resource,
but it has no concept of a 'youngest' revision. You couldn't even tell it
that. However, this is also why most WebDAV clients issue a LOCK then
issue a GET. This ensures that they get the 'youngest' revision of the
resource after they acquired the lock. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Mark Phippard <Ma...@softlanding.com>.
"Brian W. Fitzpatrick" <fi...@collab.net> wrote on 10/13/2004 04:30:59 PM:
> On Wed, 2004-10-13 at 14:13, Justin Erenkrantz wrote:
> > --On Wednesday, October 13, 2004 1:22 PM -0400 Mark Benedetto King
> > <mb...@lowlatency.com> wrote:
> >
> > > I think it should be atomic, in the following way:
> > >
> > > Client -> Server
> > >
> > > LOCK /foo.c @ r1234
> > >
> > > Server -> Client
> >
> > FWIW, that won't mesh at all with WebDAV's LOCK model. In WebDAV, you
just
> > lock the entire resource not a specific version. So, at the very
least, if we
> > tried to lock a resource/version pair, we'd likely lock out most
WebDAV
> > clients from participating. And, that'd be real bad, IMHO. -- justin
>
> I don't understand the utility of locking a path at a specific
> revision--you can't edit the contents of a revision.
>
> Am I missing something?
Plus, we have established that you can only lock the youngest revision
anyway, or more specifically your WC has to have the youngest revision.
In PVCS, you create a branch by locking a non-HEAD revision. When you
check-in, that creates the branch at that revision. So, again in PVCS,
you can allow multiple locks on a file, but only one per revision. There
is also an option to only allow one lock on the entire file.
None of this of course applies to Subversion as it has a different
branching model. So, I agree, you would essentially acquire a lock on a
file, not a specific revision of a file. A lock in a branch would
essentially be a different file so different users could still lock the
same file in trunk and a branch.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Wed, 2004-10-13 at 14:13, Justin Erenkrantz wrote:
> --On Wednesday, October 13, 2004 1:22 PM -0400 Mark Benedetto King
> <mb...@lowlatency.com> wrote:
>
> > I think it should be atomic, in the following way:
> >
> > Client -> Server
> >
> > LOCK /foo.c @ r1234
> >
> > Server -> Client
>
> FWIW, that won't mesh at all with WebDAV's LOCK model. In WebDAV, you just
> lock the entire resource not a specific version. So, at the very least, if we
> tried to lock a resource/version pair, we'd likely lock out most WebDAV
> clients from participating. And, that'd be real bad, IMHO. -- justin
I don't understand the utility of locking a path at a specific
revision--you can't edit the contents of a revision.
Am I missing something?
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, October 13, 2004 1:22 PM -0400 Mark Benedetto King
<mb...@lowlatency.com> wrote:
> I think it should be atomic, in the following way:
>
> Client -> Server
>
> LOCK /foo.c @ r1234
>
> Server -> Client
FWIW, that won't mesh at all with WebDAV's LOCK model. In WebDAV, you just
lock the entire resource not a specific version. So, at the very least, if we
tried to lock a resource/version pair, we'd likely lock out most WebDAV
clients from participating. And, that'd be real bad, IMHO. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Mark Benedetto King <mb...@lowlatency.com>.
On Wed, Oct 13, 2004 at 08:48:52AM -0700, Justin Erenkrantz wrote:
> On Wed, Oct 13, 2004 at 11:43:43AM -0400, Ben Collins-Sussman wrote:
> > Aha, this is a different strategy. Rather than make 'svn lock' do an
> > automatic update, you're suggesting that it *require* that an update
> > happen first? I like it!
>
> To be pedantic, there's a race condition between an update and then a lock.
> This is why WebDAV clients usually LOCK then GET. But, it'd most likely be
> small enough for our command-line client to require this behavior. -- justin
>
I think it should be atomic, in the following way:
Client -> Server
LOCK /foo.c @ r1234
Server -> Client
one of:
1.) SUCCESS: TOKEN is xxxx
2.) ERR: RESOURCE ALREADY LOCKED
3.) ERR: REQUEST OUT OF DATE
r1234 need not be HEAD, it just must be the youngest
revision of /foo.c. The server must provide the necessary serialization
to make sure that, server side, the check for up-to-dateness doesn't
race against the lock acquisition.
For locking directories, a WC reporter would be required, due to the
possibility of mixed-rev WCs under the directory being locked.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, Oct 13, 2004 at 11:43:43AM -0400, Ben Collins-Sussman wrote:
> Aha, this is a different strategy. Rather than make 'svn lock' do an
> automatic update, you're suggesting that it *require* that an update
> happen first? I like it!
To be pedantic, there's a race condition between an update and then a lock.
This is why WebDAV clients usually LOCK then GET. But, it'd most likely be
small enough for our command-line client to require this behavior. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Wed, 2004-10-13 at 13:09, Jim Correia wrote:
> On Oct 13, 2004, at 1:40 PM, Mark Phippard wrote:
>
> >> Because it couples unrelated operations and may have unexpected
> >> results
> >> for the user.
> >
> > I haven't seen a good explanation as to what those unexpected results
> > would be. If the file were locally modified, I do not think anyone is
> > suggesting that svn lock should do an update, this is actually the so
> > called "hijack" scenario. So other than that, given that you have to
> > be
> > up to date to acquire the lock, what would be unexpected about doing it
> > automatically.
>
> Possible unexpected side effects:
>
> 1) Person gets a lock to edit something in the file, but as a side
> effect of the update that thing has changed. I suppose this could be
> mitigated by telling the user the file has been updated.
>
> 2) I want to get a lock on FOO to make an edit. svn lock FOO updates it
> to a newer revision. The newer revision also has other files in it,
> some that changes in FOO depend on, but svn lock has put my WC in an
> inconsistent state that breaks the build. If I was told I was out of
> date, and did the single file update myself, I got what I deserved. I
> could also decide if now was a good time to do an svn up and deal with
> the consequences.
Exactly.
We could always have a 'svn lock --update' switch.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Jim Correia <ji...@pobox.com>.
On Oct 13, 2004, at 2:29 PM, Mark Phippard wrote:
> Jim Correia <ji...@pobox.com> wrote on 10/13/2004 02:09:42 PM:
>
>> 2) I want to get a lock on FOO to make an edit. svn lock FOO updates
>> it
>> to a newer revision. The newer revision also has other files in it,
>> some that changes in FOO depend on, but svn lock has put my WC in an
>> inconsistent state that breaks the build. If I was told I was out of
>> date, and did the single file update myself, I got what I deserved. I
>> could also decide if now was a good time to do an svn up and deal with
>> the consequences.
>
> I think that is a pretty good reason. However, it probably applies
> less
> to people using this feature for binary files, like Photoshop, then for
> people that are using this for "normal" development because their
> company
> is afraid of Copy-Merge-Update.
This can come up in "normal" development. One format for interface
files (.nib) on Mac OS X is a binary format. Sometimes changes to the
interface files accompany code changes. I don't do Windows, but I think
I've heard it mentioned before that there are, at least in some
situations, equivalent binary files in "normal" windows development.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Mark Phippard <Ma...@softlanding.com>.
Jim Correia <ji...@pobox.com> wrote on 10/13/2004 02:09:42 PM:
> On Oct 13, 2004, at 1:40 PM, Mark Phippard wrote:
>
> >> Because it couples unrelated operations and may have unexpected
> >> results
> >> for the user.
> >
> > I haven't seen a good explanation as to what those unexpected results
> > would be. If the file were locally modified, I do not think anyone is
> > suggesting that svn lock should do an update, this is actually the so
> > called "hijack" scenario. So other than that, given that you have to
> > be
> > up to date to acquire the lock, what would be unexpected about doing
it
> > automatically.
>
> Possible unexpected side effects:
>
> 1) Person gets a lock to edit something in the file, but as a side
> effect of the update that thing has changed. I suppose this could be
> mitigated by telling the user the file has been updated.
I am not sure how "unexpected" this is, but you are correct that it would
at least need to tell the user that the item was updated.
> 2) I want to get a lock on FOO to make an edit. svn lock FOO updates it
> to a newer revision. The newer revision also has other files in it,
> some that changes in FOO depend on, but svn lock has put my WC in an
> inconsistent state that breaks the build. If I was told I was out of
> date, and did the single file update myself, I got what I deserved. I
> could also decide if now was a good time to do an svn up and deal with
> the consequences.
I think that is a pretty good reason. However, it probably applies less
to people using this feature for binary files, like Photoshop, then for
people that are using this for "normal" development because their company
is afraid of Copy-Merge-Update. For these people, while this feature
would work no worse than the same feature in VSS et. al., it does still
make some sense to encourage the use of svn up.
> It could be that these are not situations that people will run into
> often. I don't know for sure. But it strikes me as a bad idea to couple
> acquiring a lock with updating the file. If it were a good idea, why
> doesn't svn commit do silent updates on delete instead of telling you
> that you can't commit a delete on a file that isn't up to date?
Thank you, I think these are all pretty good explanations.
I do think an option on svn lock to do an update would still be a good
idea, but you are all probably right that it might not be the best
default.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Jim Correia <ji...@pobox.com>.
On Oct 13, 2004, at 1:40 PM, Mark Phippard wrote:
>> Because it couples unrelated operations and may have unexpected
>> results
>> for the user.
>
> I haven't seen a good explanation as to what those unexpected results
> would be. If the file were locally modified, I do not think anyone is
> suggesting that svn lock should do an update, this is actually the so
> called "hijack" scenario. So other than that, given that you have to
> be
> up to date to acquire the lock, what would be unexpected about doing it
> automatically.
Possible unexpected side effects:
1) Person gets a lock to edit something in the file, but as a side
effect of the update that thing has changed. I suppose this could be
mitigated by telling the user the file has been updated.
2) I want to get a lock on FOO to make an edit. svn lock FOO updates it
to a newer revision. The newer revision also has other files in it,
some that changes in FOO depend on, but svn lock has put my WC in an
inconsistent state that breaks the build. If I was told I was out of
date, and did the single file update myself, I got what I deserved. I
could also decide if now was a good time to do an svn up and deal with
the consequences.
It could be that these are not situations that people will run into
often. I don't know for sure. But it strikes me as a bad idea to couple
acquiring a lock with updating the file. If it were a good idea, why
doesn't svn commit do silent updates on delete instead of telling you
that you can't commit a delete on a file that isn't up to date?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Mark Phippard <Ma...@softlanding.com>.
Jim Correia <ji...@pobox.com> wrote on 10/13/2004 12:00:25 PM:
> On Oct 13, 2004, at 9:23 AM, Mark Phippard wrote:
>
> > I do not really understand the objections here. If you have to have
> > an up
> > to date file in order to lock it, and we are trying to make this easy
> > for
> > "users", then why shouldn't svn lock update the file automatically?
>
> Because it couples unrelated operations and may have unexpected results
> for the user.
I haven't seen a good explanation as to what those unexpected results
would be. If the file were locally modified, I do not think anyone is
suggesting that svn lock should do an update, this is actually the so
called "hijack" scenario. So other than that, given that you have to be
up to date to acquire the lock, what would be unexpected about doing it
automatically.
> Committing a delete of an out of date file returns an error. I see no
> reason why trying to acquire a lock on an out of date file should do
> the same.
I guess I just see it as more work that in order to lock a file, a user
has to run 2 commands. That being said, I will confess that having read
more messages in the thread, I am now realizing that the user doesn't have
to be at HEAD in their working copy, they just have to have the latest
revision of that file, as with commit. I suppose that really isn't that
bad.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Jim Correia <ji...@pobox.com>.
On Oct 13, 2004, at 11:43 AM, Ben Collins-Sussman wrote:
> On Oct 13, 2004, at 11:33 AM, Philip Martin wrote:
>
>> Ben Collins-Sussman <su...@collab.net> writes:
>>
>>> $ svn lock foo.doc
>>
>> Result is either an error
>>
>> svn: foo.doc is out-of-date, please update
>>
>> or success which means foo.doc is up-to-date. Once we have a lock it
>> will remain up-to-date.
>
> Aha, this is a different strategy. Rather than make 'svn lock' do an
> automatic update, you're suggesting that it *require* that an update
> happen first? I like it!
As do I.
On Oct 13, 2004, at 9:23 AM, Mark Phippard wrote:
> I do not really understand the objections here. If you have to have
> an up
> to date file in order to lock it, and we are trying to make this easy
> for
> "users", then why shouldn't svn lock update the file automatically?
Because it couples unrelated operations and may have unexpected results
for the user.
Committing a delete of an out of date file returns an error. I see no
reason why trying to acquire a lock on an out of date file should do
the same.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> I was describing what might happen in a world where 'lock' and
> 'update' are separate actions, and have no mutual requirement or
> dependence at all. My fear is that in such a world, users forget to
> 'update' before locking, so that they end up locking an out-of-date
> file.
>
> But your recommendation above fixes that.
Thinking a bit more, if you had suggested the locking command be
$ svn update --lock foo.c
rather than
$ svn lock foo.c
I think I would have accepted it without a question. Appearances are
everything! I guess that means I don't really object to "svn lock"
running update.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Ben Collins-Sussman <su...@collab.net>.
On Oct 13, 2004, at 11:33 AM, Philip Martin wrote:
> Ben Collins-Sussman <su...@collab.net> writes:
>
>> $ svn lock foo.doc
>
> Result is either an error
>
> svn: foo.doc is out-of-date, please update
>
> or success which means foo.doc is up-to-date. Once we have a lock it
> will remain up-to-date.
Aha, this is a different strategy. Rather than make 'svn lock' do an
automatic update, you're suggesting that it *require* that an update
happen first? I like it!
>
>> ### edit
>> $ svn commit foo.c
>> svn: sorry, you need to 'svn up'
>
> It was up-to-date when we took a lock, so how does this happen?
> Did somebody break our lock? How will having lock run update help?
>
I was describing what might happen in a world where 'lock' and 'update'
are separate actions, and have no mutual requirement or dependence at
all. My fear is that in such a world, users forget to 'update' before
locking, so that they end up locking an out-of-date file.
But your recommendation above fixes that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> $ svn lock foo.doc
Result is either an error
svn: foo.doc is out-of-date, please update
or success which means foo.doc is up-to-date. Once we have a lock it
will remain up-to-date.
> ### edit
> $ svn commit foo.c
> svn: sorry, you need to 'svn up'
It was up-to-date when we took a lock, so how does this happen?
Did somebody break our lock? How will having lock run update help?
> $ svn up
> C foo.doc
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Mark Phippard <Ma...@softlanding.com>.
Julian Foad <ju...@btopenworld.com> wrote on 10/13/2004 12:27:03 PM:
> > * Should lock-messages be required?
> >
> > People seem to agree that they shouldn't be required, but still
> > discussing UIs for configuring this.
>
> Despite them being temporary (compared to commit log messages) I think
> that handling them in the same way is appropriate. There are plenty of
> people who don't want supply commit log messages, and they currently
> have to write '-m ""'. I believe that a far greater proportion of
> people will not want to give lock messages, and if it is considered too
> arduous for them to have to write '-m ""' then I think we should allow
> both lock and commit messages to be configurable in the same way.
>
> I suggest that we leave lock messages out of the initial implementation,
> as there will be enough other problems to solve. I can't see any reason
> not to make them a later additional feature.
I think that lock messages are a nice feature, as well as an improvement
over "competitive tools" like CVS, VSS and PVCS. I have not seen any
indication that adding the feature adds any complication to the design.
The only discussion seems to be on whether it ought to be required. While
I personally think they ought to be required, it seems like it would be
rather simple to enforce this rule with a pre-hook script if truly needed.
After all, if you want to require a comment, you probably would like the
comment to be useful, perhaps referencing a bug ID for example. This sort
of validation could only be enforced via hook script anyway. So I say,
add the feature, do not require it, and let hook-scripts and GUI tools,
with preferences, decide to require it. For example, in TSVN you can
define a preference as a repository property that indicates the minimum
characters in a commit message. They could do something similar for lock
messages and it is a simple way for someone that wants to enforce a
message to do so.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Julian Foad <ju...@btopenworld.com>.
Ben Collins-Sussman wrote:
>
> * Garrett: yes, the property might be better be called 'svn:must-lock'.
[...]
> it's just a helpful tool that admins can set on unmergable files.
Agreed that that would be better. Note that we might some time want a
property like "svn:unmergeable" that tells "svn merge" etc. whether to
try merging automatically, but this need not be directly related to the
one that controls locking.
> * Julian: Greg Stein and Fitz and I had a chat about the idea of a
> working copy storing lock-tokens that belong to other people, but Greg
> talked us out of that idea. First, such tokens are likely to get real
> stale, real fast. Second, 'svn st -u' would show other peoples' locks,
> as would 'svn info URL', and would always show the latest information.
Yes - fair enough.
> * "Should locking imply updating"?
[...]
> What I *don't* want to happen is
[...]
> svn: sorry, you need to 'svn up'
No-one (AFAIK) was suggesting that "svn lock" should succeed on an
out-of-date file and thus lead to this sort of nastiness. They were
only debating whether in that case it should error or do the update for you.
> It would be far, far better to teach non-techies to run 'svn reserve',
> and then avoid the conflict situation completely.
Please not two different commands for locking. I don't know whether I
want it (whichever single command we choose) to do the update or not,
but let there only be one command.
> * 'svn info' shows lock-tokens and works on URLs
>
> So far garrett and I like this idea. Are other folks okay with that?
> I agree that it's better than adding a new subcommand.
Yes. That's good.
> * Should lock-messages be required?
>
> People seem to agree that they shouldn't be required, but still
> discussing UIs for configuring this.
Despite them being temporary (compared to commit log messages) I think
that handling them in the same way is appropriate. There are plenty of
people who don't want supply commit log messages, and they currently
have to write '-m ""'. I believe that a far greater proportion of
people will not want to give lock messages, and if it is considered too
arduous for them to have to write '-m ""' then I think we should allow
both lock and commit messages to be configurable in the same way.
I suggest that we leave lock messages out of the initial implementation,
as there will be enough other problems to solve. I can't see any reason
not to make them a later additional feature.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, Oct 13, 2004 at 11:14:47AM -0400, Ben Collins-Sussman wrote:
> Gee, how many threads can I juggle here?
>
> * Garrett: yes, the property might be better be called
> 'svn:must-lock'. Files with this property live in a read-only state,
> to serve as reminder that they're non-mergeable. Locking the file
> makes it read-write, and releasing the lock makes it read-only again.
> It's a system for preventing people from wasting time on unmergeable
> changes. The property is not required to perform a lock; it's just a
> helpful tool that admins can set on unmergable files.
Uh, yah. svn:lock was a crappy name if it doesn't indicate if a lock
is held, but that the file should have mandatory locking enabled.
(This answers my question to ghudson from a few minutes ago.)
> * Ghudson and Philip: I'm going to start a separate thread about
> directory locks. You guys are right, this opens a whole new can of
> worms, and needs to be examined verrrrrrry carefully.
And as ghudson said, we might be better off to split the implementation
of directory locks until after we have file locking in place.
> * Julian: Greg Stein and Fitz and I had a chat about the idea of a
> working copy storing lock-tokens that belong to other people, but Greg
> talked us out of that idea. First, such tokens are likely to get real
...
Agreed that you wouldn't want to store other people's lock tokens.
However, svn st -u (or whatever) would indicate whether a lock is held
at that moment, right? So, there is a way to see if a lock is held on
the server side?
> * "Should locking imply updating"?
...
> It would be far, far better to teach non-techies to run 'svn reserve',
> and then avoid the conflict situation completely.
Honestly, they'd use GUIs. The GUI can say, "Do you want me to update?"
right after the lock is taken.
And, remember that most non-techies are going to be using Adobe Photoshop,
Mac OS X Finder, etc, etc. They all hide the lock/unlock business from
their users.
*ahem* We are planning for the locking API to be able to be DAV-compliant,
right? =) The real non-techies aren't going to know there's Subversion.
They are just going to open it up with Photoshop...
> * Friendlier conflicts on files with 'svn:must-lock' property.
>
> I agree that an interactive choice between repository vs. working
> file is a bad idea, you guys win. I think we should just print a
> warning and save the repos file as backup, as in my example above. If
> nobody objects, I'll put that in the UI spec.
Yup. I'd go with '.mine' to be consistent. And, then 'svn resolved'
could clean it up??
> * 'svn info' shows lock-tokens and works on URLs
>
> So far garrett and I like this idea. Are other folks okay with that?
> I agree that it's better than adding a new subcommand.
+1.
> * Should 'svn commit' release or hold lock by default?
>
> People are still debating this.
So, say you. =)
> * Should lock-messages be required?
>
> People seem to agree that they shouldn't be required, but still
> discussing UIs for configuring this.
Not required, but they should be present. I'd view it as similar to our
'svn commit' messages. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Ben Collins-Sussman <su...@collab.net>.
Gee, how many threads can I juggle here?
* Garrett: yes, the property might be better be called
'svn:must-lock'. Files with this property live in a read-only state,
to serve as reminder that they're non-mergeable. Locking the file
makes it read-write, and releasing the lock makes it read-only again.
It's a system for preventing people from wasting time on unmergeable
changes. The property is not required to perform a lock; it's just a
helpful tool that admins can set on unmergable files.
* Ghudson and Philip: I'm going to start a separate thread about
directory locks. You guys are right, this opens a whole new can of
worms, and needs to be examined verrrrrrry carefully.
* Julian: Greg Stein and Fitz and I had a chat about the idea of a
working copy storing lock-tokens that belong to other people, but Greg
talked us out of that idea. First, such tokens are likely to get real
stale, real fast. Second, 'svn st -u' would show other peoples' locks,
as would 'svn info URL', and would always show the latest information.
Third, there's no serious problem here that needs solving. If a file
is mergeable, and your attempted commit fails due to a previously
unknown lock by someone else, big deal. Just merge and wait for the
lock to go away. If a file isn't mergeable, then the 'svn:must-lock'
property (and resultant read-only attribute) should have been set on
the file in the first place, to prevent you from having wasted time
editing.
* "Should locking imply updating"?
It looks like ghudson, philip, and jerenkrantz all very much want
'lock' to not run 'update'. If so, I think we need to create a command
for the non-vc people that does this, like 'svn reserve' or something.
These managers and web developers being forced to use version-control
might understand enough to run 'svn update' once a day, but I'm pretty
confident that they won't always remember to run 'svn up' right before
or after locking something. What I *don't* want to happen is
$ svn lock foo.doc
### edit
$ svn commit foo.c
svn: sorry, you need to 'svn up'
$ svn up
C foo.doc
or
$ svn up
svn: warning: newer file from repository saved in
'foo.backup.doc'
It would be far, far better to teach non-techies to run 'svn reserve',
and then avoid the conflict situation completely.
* Friendlier conflicts on files with 'svn:must-lock' property.
I agree that an interactive choice between repository vs. working
file is a bad idea, you guys win. I think we should just print a
warning and save the repos file as backup, as in my example above. If
nobody objects, I'll put that in the UI spec.
* 'svn info' shows lock-tokens and works on URLs
So far garrett and I like this idea. Are other folks okay with that?
I agree that it's better than adding a new subcommand.
* Should 'svn commit' release or hold lock by default?
People are still debating this.
* Should lock-messages be required?
People seem to agree that they shouldn't be required, but still
discussing UIs for configuring this.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Julian Foad <ju...@btopenworld.com>.
>> Justin Erenkrantz wrote:
>>> (If we're
>>> adding svn:lock as a property on the resource, my hunch is that the
>>> global revnum is going to have to change.)
Garrett Rooney wrote:
> I'm not sure about that.... I was not totally clear on the use of the
> svn:lock property either. Perhaps Ben or Fitz could elaborate. Is it
> only supposed to be used to indicate the need for locking? If so, I'd
> say we should call it svn:must-lock or something like that.
To all in this discussion:
Before commenting, please read the two new locking documents under
notes/locking/, on which this debate is founded. In this case, see
locking-ui.txt section II.B.: The "svn:lock" property.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Julian Foad wrote:
> Justin Erenkrantz wrote:
>
>> While not a UI issue per se, here's a question that I don't think I've
>> necessarily seen answered yet, but would the acquisition or release of
>> a lock bump the repository revision number? (If we're adding svn:lock
>> as a property on the resource, my hunch is that the global revnum is
>> going to have to change.)
>
>
> Certainly not. The "svn:lock" property was proposed as a permanent
> indication that this is a file that ought to be locked before working on
> it, not as the indication that it is currently locked.
I'm not sure about that.... I was not totally clear on the use of the
svn:lock property either. Perhaps Ben or Fitz could elaborate. Is it
only supposed to be used to indicate the need for locking? If so, I'd
say we should call it svn:must-lock or something like that.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Julian Reschke <ju...@gmx.de>.
Justin Erenkrantz wrote:
> ...
> Take a look at RFC 2518 Section 13.8 for what I mean. WebDAV reports
> the presence of a lock by responding to a lockdiscovery PROPFIND
> request. This is how 'svn info' for a lock would likely be implemented
> over WebDAV.
>
> So, back to my question: does the fact that the property of a resource
> implicitly changes because a lock has been acquired or released also
> mean that the global rev number also changes? By and large, our
> response has been that if any property changes, so should the repository
> revision. Although I feel that might not be appropriate here. I've
> found the WebDAV and DeltaV specs to be completely unhelpful here. My
> hunch is that they shouldn't (and is permitted by DeltaV), but I'm not
> 100% sure. I'm going to ask some of the WebDAV folks around the office
> though... -- justin
The main question here is whether locks contribute to the
version-controlled state of a resource. If it did, some of the
autolocking behaviours allowed by RFC3253 (because they rely on the
ability to lock a resource that is not checked-out) wouldn't work.
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: Locking UI comments
Posted by Julian Reschke <ju...@gmx.de>.
Justin Erenkrantz wrote:
> --On Wednesday, October 13, 2004 2:07 PM -0700 Justin Erenkrantz
> <ju...@erenkrantz.com> wrote:
>
>> shouldn't (and is permitted by DeltaV), but I'm not 100% sure. I'm
>> going to
>> ask some of the WebDAV folks around the office though... -- justin
>
>
> Okay, some more replying to myself. ;-)
>
> I talked to some WebDAV-savvy folks around the office and here's what
> they said:
>
> 1) Locks shouldn't touch the repository number. It's indeed metadata,
> but it doesn't invoke a MERGE which is what we'd use to alter the
> repository revision.
>
> 2) Warnings about goofy WebDAV clients that do LOCK. The ones in Adobe
> are fairly good. However, the WebDAV client in Word/Office has goofy
> LOCK semantics. Apparently, it asks for a LOCK with a two minute
> timeout period. At the *end* of two minutes (i.e. after the lock should
> have expired), it'll refresh the lock. There were some mod_dav fixes
> inserted to give an implicit grace period to time-sensitive locks.
>
> This conversation reminded me that I haven't seen any discussion of
> locks for Subversion that have a timeout, while WebDAV does have locks
> that timeout. So, I wonder if we need to add that functionality or not
> as some WebDAV clients will expect that behavior. -- justin
OK, I just checked with Office 2003; it attempts a LOCK with 180s
timeout; if the request suceeds but the timeout sent back by the server
isn't what it expects, it gives up and opens the document read-only.
Furthermore, it doesn't UNLOCK the document when it's closed. (Yes, that
is a bug in Office; clients MUST NOT rely on servers supporting specific
timeout values, see
<http://greenbytes.de/tech/webdav/rfc2518.html#HEADER_Timeout>).
So it seems that adding locking functionality without timeout support
will not help for the MS-Office use case.
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: Locking UI comments
Posted by Julian Reschke <ju...@gmx.de>.
Justin Erenkrantz wrote:
> ...
> 2) Warnings about goofy WebDAV clients that do LOCK. The ones in Adobe
> are fairly good. However, the WebDAV client in Word/Office has goofy
> LOCK semantics. Apparently, it asks for a LOCK with a two minute
> timeout period. At the *end* of two minutes (i.e. after the lock should
> have expired), it'll refresh the lock. There were some mod_dav fixes
> inserted to give an implicit grace period to time-sensitive locks.
As far as I know this has been fixed in more recent Office versions. I'd
recommend not to put in any workarounds before any actual problems are
reported (by people running Office with all applicable patches applied).
> This conversation reminded me that I haven't seen any discussion of
> locks for Subversion that have a timeout, while WebDAV does have locks
> that timeout. So, I wonder if we need to add that functionality or not
> as some WebDAV clients will expect that behavior. -- justin
I'll try to test with Office that when I have time.
Julian (R)
--
<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: Locking UI comments
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, October 13, 2004 2:07 PM -0700 Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> shouldn't (and is permitted by DeltaV), but I'm not 100% sure. I'm going to
> ask some of the WebDAV folks around the office though... -- justin
Okay, some more replying to myself. ;-)
I talked to some WebDAV-savvy folks around the office and here's what they
said:
1) Locks shouldn't touch the repository number. It's indeed metadata, but it
doesn't invoke a MERGE which is what we'd use to alter the repository revision.
2) Warnings about goofy WebDAV clients that do LOCK. The ones in Adobe are
fairly good. However, the WebDAV client in Word/Office has goofy LOCK
semantics. Apparently, it asks for a LOCK with a two minute timeout period.
At the *end* of two minutes (i.e. after the lock should have expired), it'll
refresh the lock. There were some mod_dav fixes inserted to give an implicit
grace period to time-sensitive locks.
This conversation reminded me that I haven't seen any discussion of locks for
Subversion that have a timeout, while WebDAV does have locks that timeout.
So, I wonder if we need to add that functionality or not as some WebDAV
clients will expect that behavior. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, October 13, 2004 3:26 PM -0500 "Brian W. Fitzpatrick"
<fi...@collab.net> wrote:
> I think we're once again running into the misunderstanding fostered by
> the name 'svn:lock' which should be something to the effect of
> "svn:this-file-must-be-locked-before-committing."
>
> The property is part of the communication system involved in locks--it
> has nothing to do with whether or not the file/path is locked.
>
> So I would say that locking/unlocking a file does not bump the revision
> number.
I think there's confusion about what I was referring to here.
The lockdiscovery property I was referring to is WebDAV's way of reporting
whether or not there is an actively held lock. This has absolutely nothing
to do with 'svn:lock' or 'svn:must-lock' or whatnot.
Take a look at RFC 2518 Section 13.8 for what I mean. WebDAV reports the
presence of a lock by responding to a lockdiscovery PROPFIND request. This
is how 'svn info' for a lock would likely be implemented over WebDAV.
So, back to my question: does the fact that the property of a resource
implicitly changes because a lock has been acquired or released also mean
that the global rev number also changes? By and large, our response has
been that if any property changes, so should the repository revision.
Although I feel that might not be appropriate here. I've found the WebDAV
and DeltaV specs to be completely unhelpful here. My hunch is that they
shouldn't (and is permitted by DeltaV), but I'm not 100% sure. I'm going
to ask some of the WebDAV folks around the office though... -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Wed, 2004-10-13 at 15:17, Mark Phippard wrote:
> Justin Erenkrantz <ju...@erenkrantz.com> wrote on 10/13/2004 03:26:58 PM:
>
> > --On Wednesday, October 13, 2004 1:06 PM +0100 Julian Foad
> > <ju...@btopenworld.com> wrote:
> >
> > > Certainly not. The "svn:lock" property was proposed as a permanent
> > > indication that this is a file that ought to be locked before working
> on it,
> > > not as the indication that it is currently locked.
> >
> > The problem is that according to WebDAV, we have to respond to the
> > lockdiscovery property on the resource in order to allow a query if
> there's an
> > outstanding lock. (This is what 'svn info' should do in order to query
> lock
> > info.) So, the question remains: does an implicit change of a live
> property
> > imply a change in our revnum? I could see it going either way. --
> justin
>
> Forgive me if I am being dense, but what would the implicit change be? I
> thought that svn:lock was just a normal property that would be set and
> managed like any other property. In other words, it would only ever be
> set/modified/removed explicitly and would up the revnum when committed.
>
> There has been a lot of conversation, so perhaps I have missed something?
I think we're once again running into the misunderstanding fostered by
the name 'svn:lock' which should be something to the effect of
"svn:this-file-must-be-locked-before-committing."
The property is part of the communication system involved in locks--it
has nothing to do with whether or not the file/path is locked.
So I would say that locking/unlocking a file does not bump the revision
number.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Mark Phippard <Ma...@softlanding.com>.
Justin Erenkrantz <ju...@erenkrantz.com> wrote on 10/13/2004 03:26:58 PM:
> --On Wednesday, October 13, 2004 1:06 PM +0100 Julian Foad
> <ju...@btopenworld.com> wrote:
>
> > Certainly not. The "svn:lock" property was proposed as a permanent
> > indication that this is a file that ought to be locked before working
on it,
> > not as the indication that it is currently locked.
>
> The problem is that according to WebDAV, we have to respond to the
> lockdiscovery property on the resource in order to allow a query if
there's an
> outstanding lock. (This is what 'svn info' should do in order to query
lock
> info.) So, the question remains: does an implicit change of a live
property
> imply a change in our revnum? I could see it going either way. --
justin
Forgive me if I am being dense, but what would the implicit change be? I
thought that svn:lock was just a normal property that would be set and
managed like any other property. In other words, it would only ever be
set/modified/removed explicitly and would up the revnum when committed.
There has been a lot of conversation, so perhaps I have missed something?
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, October 13, 2004 1:06 PM +0100 Julian Foad
<ju...@btopenworld.com> wrote:
> Certainly not. The "svn:lock" property was proposed as a permanent
> indication that this is a file that ought to be locked before working on it,
> not as the indication that it is currently locked.
The problem is that according to WebDAV, we have to respond to the
lockdiscovery property on the resource in order to allow a query if there's an
outstanding lock. (This is what 'svn info' should do in order to query lock
info.) So, the question remains: does an implicit change of a live property
imply a change in our revnum? I could see it going either way. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Julian Foad <ju...@btopenworld.com>.
Justin Erenkrantz wrote:
> While not a UI issue per se, here's a question that I don't think I've
> necessarily seen answered yet, but would the acquisition or release of a
> lock bump the repository revision number? (If we're adding svn:lock as
> a property on the resource, my hunch is that the global revnum is going
> to have to change.)
Certainly not. The "svn:lock" property was proposed as a permanent
indication that this is a file that ought to be locked before working on
it, not as the indication that it is currently locked.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
I just read through the locking functional reqs and UI doc. I'll add my $.02
to Greg's comments and add my own comments regarding the UI...
--On Tuesday, October 12, 2004 4:52 PM -0400 Greg Hudson <gh...@MIT.EDU>
wrote:
> Issue #1: Should "svn lock" implicitly include "svn update"?
>
> The document says yes. I believe that it is not intuitive for the
> verb "lock" to include an implicit update, and people may be surprised
> by the "helpful" behavior. Instead, I think lock should error out if
> the file is not up to date, with the error message instructing the
> user to update the file. (I'm fine with an explicit "svn lock
> --update" if and only if there is a considered belief that it would be
> a real convenience for users.)
Absolutely agreed that 'lock' should not touch the contents of the file.
> Issue #2: Should "svn update" resolve hijacks interactively?
>...
> I believe this is a total non-starter. It has the same problems as
Yah. Ickiness abounds.
I'm wondering if there is a way for 'svn resolved' to somehow help out. What
are the drawbacks of adopting the '.mine' and '.rXXXX' model? I think having
consistency might be beneficial here.
> Issue #3: Should lock messages be required?
> ...
> So, here are alternatives I would consider more palatable:
>
> * Punt on lock messages for the initial implementation.
>
> * Support lock messages, but only specify them if the user specifies
> a -m or -F option on the "svn lock" command line.
I view the $EDITOR being brought up with either -m or -F as options as my
preference. There should be an ability to have a lock message, as in "I'm
adding Section 7.9. ETA: 1 hour." Lock messages would be wonderful!
While not a UI issue per se, here's a question that I don't think I've
necessarily seen answered yet, but would the acquisition or release of a lock
bump the repository revision number? (If we're adding svn:lock as a property
on the resource, my hunch is that the global revnum is going to have to
change.)
> Issue #4: "svn lockinfo" command?
> ...
> client-local operation and lock information has to be fetched from the
> server, but perhaps this could be an option to "svn info".
Agreed. Add something to 'svn info'.
On to my own comments:
Issue #5: Should 'svn commit' release a lock?
I don't think so. I think that if a lock is explicitly requested, then it
needs to (by default) be explicitly released. I'd reverse the commit behavior
and have '--release-lock' be an option: the default should be to keep the lock.
Here's a use case that I think is more common than not: I lock a file, I want
to make some changes to the file. It's 5pm and I want to go home for the day,
so I commit my changes so I can checkpoint my work (after all, that's the
point of a SCM). By checking it in, I can let other people view my progress,
but I still want to reflect to everyone else that I still have the lock on the
file. (That is, if you break or steal it, be aware that I was doing something
with it.)
I just don't think it's intuitive for 'svn commit' to release the lock when I
explicitly requested it with 'svn lock.' 'svn unlock' should be the desired
usage path we lead users towards. (UIs like TSVN or whatnot can have a
checkbox for allowing the user to release the lock on commit. I'm only
concerned about what our command-line GUI does.)
Issue #6: How would the hook scripts know that the lock is already locked?
This seems to me to be a separate case for a 'force' set of hook scripts or a
flag into the scripts to indicate if the lock was already held. (Pass in
LOCK_OWNER?) For example, I wouldn't care about an unlock where the owner is
doing the unlocking. However, I'd very much care about the case where the
unlocking is done by someone who isn't the owner. I'd personally want an
email sent in that case. And, I'm not at all clear how the hook scripts would
know the difference from the locking-ui.txt.
Looks great. =) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Jack Repenning <jr...@collab.net>.
On Oct 12, 2004, at 3:47 PM, Ben Collins-Sussman wrote:
>
> On Oct 12, 2004, at 4:52 PM, Greg Hudson wrote:
>> Issue #3: Should lock messages be required?
>>
>>
>> * Punt on lock messages for the initial implementation.
>>
>> * Support lock messages, but only specify them if the user specifies
>> a -m or -F option on the "svn lock" command line.
>>
>> * Use a file property (either the contents of svn:lock, or a
>> separate boolean property) to determine whether the UI should get
>> in the user's face about lock messages. Then a project can
>> decide, on a per-file basis, whether to require lock messages.
>
> I have no real opinion on this issue. What do others think?
(a) ClearCase makes this, or something rather like it, a personal
preference rather than a central one, and (b) Greg's absolutely right,
that's wrong ;-) All it does is create/promote a class system, where
those in the know can make it be nice, while all the new users, and no
small proportion of the experienced, are constantly frustrated.
Greg's second idea ("Support lock messages, but ...") should also
include a switch for "ask me for a message" (aka "pop up an editor").
[ClearCase also has an related switch that means "ask me separately for
each file affected," which surely is annoying overkill....]
Anything but "punt" is edging over toward a separate use case entirely
(which I just spent the afternoon jawing about with a customer):
auditability. ClearCase provides this with unreserved checkouts
(including log messages, controlled by personal preference, in the
equivalents of -m, -F, -pop-an-editor, and
-ask-me-for-each-file-separately). But maybe "punt now" allows the
topic of lock messages to be included in that other discussion. If we
ever have it.
I think I like "punt."
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: +1 650.228.2562
c: +1 408.835.8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Mark Benedetto King <mb...@lowlatency.com>.
On Wed, Oct 13, 2004 at 05:10:26PM -0700, Jack Repenning wrote:
>
> On Oct 12, 2004, at 4:54 PM, Mark Benedetto King wrote:
>
> >One thing, so we don't forget: our directory conflict check is more
> >permissive for commits than it should be for locks: an add doesn't
> >conflict on commit with unseen adds, but a lock should (IMO).
>
> How's that again? Are you saying "locks should conflict with locks
> more generally than adds do with adds"? Or maybe "locks should
> conflict with adds ...."? How might a lock be "unseen"?
>
An attempt to lock a directory should be considered out-of-date
if the WC issuing the lock request is not completely up to date.
An attempt to add to a directory is not considered out-of-date
unless the add conflicts with another (unseen) add.
Note:
This stance is predicated on my opinion that blind locks are
bad, and that a lock request should be accompanied by the
revision that the client has, so the server can determine
whether or not the client is up to date. Obviously, a blind
lock request can never be considered out of date.
Also note:
I agree that directory locking is more than we should bite off,
so the issue is moot. Count my statement as one more reason
why.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Jack Repenning <jr...@collab.net>.
On Oct 12, 2004, at 4:54 PM, Mark Benedetto King wrote:
> One thing, so we don't forget: our directory conflict check is more
> permissive for commits than it should be for locks: an add doesn't
> conflict on commit with unseen adds, but a lock should (IMO).
How's that again? Are you saying "locks should conflict with locks
more generally than adds do with adds"? Or maybe "locks should
conflict with adds ...."? How might a lock be "unseen"?
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: +1 650.228.2562
c: +1 408.835.8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Mark Benedetto King <mb...@lowlatency.com>.
On Tue, Oct 12, 2004 at 06:52:24PM -0400, Garrett Rooney wrote:
>
> Sure, but that's not a problem that's unique to the proposed 'svn lock'
> command, we have that issue all over the place. Perhaps the client
> should catch the SVN_ERR_RA_OUT_OF_DATE error and wrap it in a 'try
> running svn update and doing that again' kind of message.
>
One thing, so we don't forget: our directory conflict check is more
permissive for commits than it should be for locks: an add doesn't
conflict on commit with unseen adds, but a lock should (IMO).
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Ben Collins-Sussman wrote:
>
> On Oct 12, 2004, at 4:52 PM, Greg Hudson wrote:
>
>> I've discussed most of these with Ben and others on IRC, but that's
>> not the proper forum for resolving contentious issues.
>
>
> Thanks for the great feedback, Greg.
>
>>
>> Issue #1: Should "svn lock" implicitly include "svn update"?
>>
>> As I understand things, Ben's rationale for locking-implicitly-updates
>> is to mirror the behavior of other version control systems which are
>> either non-concurrent (VSS) or non-concurrent by default (Clearcase).
>> (It wouldn't be a very perfect mirror; in those systems, it's not so
>> much "locking implicitly updates" as "checking out implicitly locks.)
>> I don't think it's a good idea to model our default behavior after a
>> non-concurrent version control system; we will wind up looking
>> schizoprenic.
>
>
> To whom? :-)
>
>>
>> If we want to change the verb to "grab" or "reserve", then maybe it
>> would be okay to perform an implicit update, but I don't see what's
>> wrong with just erroring out if the file is not up to date.
>>
>
> To the seasoned unix crowd, I suppose that defining 'lock' to do two
> things contradicts the "lots of small tools" unix philosophy. But to
> the non-techie being forced to use version control, I'm not sure it
> would create confusion.
>
> My ultimate goal is to help users working in the 100% locking
> environment, where everything is read-only and has the 'svn:lock'
> property attached. I guess that such a user needs to learn about 'svn
> update' no matter what... so if 'svn lock' tells them to run 'svn up',
> that's fine. What's *not* okay is 'svn lock' saying 'error, file is
> out-of-date'. The phrase 'out-of-date' is too lingoey.
Sure, but that's not a problem that's unique to the proposed 'svn lock'
command, we have that issue all over the place. Perhaps the client
should catch the SVN_ERR_RA_OUT_OF_DATE error and wrap it in a 'try
running svn update and doing that again' kind of message.
>>
>> Issue #4: "svn lockinfo" command?
>>
>> As you all know, I've very keen on keeping our command set small.
>> "svn lock" and "svn unlock" are pretty much non-negotiable for this
>> feature, but when we already have "svn status" and "svn info", do we
>> really need a separate "svn lockinfo"? I realize that svn info is a
>> client-local operation and lock information has to be fetched from the
>> server, but perhaps this could be an option to "svn info".
>
>
> I'm fine with this. Maybe 'svn info' just prints extra lock-token info
> if the wc target happens to have a lock-token attached to it? If this
> were the case, I'd want 'svn info' to be able to operate on URLs as well
> (which has been requested before, I think). People need to be able to
> find out who/when/why a repository file was locked... without a working
> copy.
+1, to both including this inforation in 'svn info' and making 'svn
info' work on URLs.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Ben Collins-Sussman <su...@collab.net>.
On Oct 12, 2004, at 4:52 PM, Greg Hudson wrote:
> I've discussed most of these with Ben and others on IRC, but that's
> not the proper forum for resolving contentious issues.
Thanks for the great feedback, Greg.
>
> Issue #1: Should "svn lock" implicitly include "svn update"?
>
> As I understand things, Ben's rationale for locking-implicitly-updates
> is to mirror the behavior of other version control systems which are
> either non-concurrent (VSS) or non-concurrent by default (Clearcase).
> (It wouldn't be a very perfect mirror; in those systems, it's not so
> much "locking implicitly updates" as "checking out implicitly locks.)
> I don't think it's a good idea to model our default behavior after a
> non-concurrent version control system; we will wind up looking
> schizoprenic.
To whom? :-)
>
> If we want to change the verb to "grab" or "reserve", then maybe it
> would be okay to perform an implicit update, but I don't see what's
> wrong with just erroring out if the file is not up to date.
>
To the seasoned unix crowd, I suppose that defining 'lock' to do two
things contradicts the "lots of small tools" unix philosophy. But to
the non-techie being forced to use version control, I'm not sure it
would create confusion.
My ultimate goal is to help users working in the 100% locking
environment, where everything is read-only and has the 'svn:lock'
property attached. I guess that such a user needs to learn about 'svn
update' no matter what... so if 'svn lock' tells them to run 'svn up',
that's fine. What's *not* okay is 'svn lock' saying 'error, file is
out-of-date'. The phrase 'out-of-date' is too lingoey.
> Issue #2: Should "svn update" resolve hijacks interactively?
>
>
> What we can do is alter our behavior on a conflict for a file which
> has been tagged with the svn:lock property. Instead of generating a
> conflict marker and perhaps attempting a merge, we can leave the local
> edit in place, drop the repository edit into a backup file, and warn
> the user. I'm not certain whether this is right or not.
>
I think I agree... adding interactivity to 'svn up' is going to kill
us. I like your idea of doing a "wussy" merge on 'svn:lock' files in
the case of a hijack -- that is, instead of creating a (C)onflicted
file with three fulltexts, we print a warning and drop the repos file
into a backup. That's sufficiently user-friendly, doesn't necessarily
lose data, and keeps non-techies from having to learn what a conflict
is, or how to deal with it.
> Issue #3: Should lock messages be required?
>
>
> * Punt on lock messages for the initial implementation.
>
> * Support lock messages, but only specify them if the user specifies
> a -m or -F option on the "svn lock" command line.
>
> * Use a file property (either the contents of svn:lock, or a
> separate boolean property) to determine whether the UI should get
> in the user's face about lock messages. Then a project can
> decide, on a per-file basis, whether to require lock messages.
I have no real opinion on this issue. What do others think?
>
> Issue #4: "svn lockinfo" command?
>
> As you all know, I've very keen on keeping our command set small.
> "svn lock" and "svn unlock" are pretty much non-negotiable for this
> feature, but when we already have "svn status" and "svn info", do we
> really need a separate "svn lockinfo"? I realize that svn info is a
> client-local operation and lock information has to be fetched from the
> server, but perhaps this could be an option to "svn info".
I'm fine with this. Maybe 'svn info' just prints extra lock-token info
if the wc target happens to have a lock-token attached to it? If this
were the case, I'd want 'svn info' to be able to operate on URLs as
well (which has been requested before, I think). People need to be
able to find out who/when/why a repository file was locked... without a
working copy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking UI comments
Posted by Mark Phippard <Ma...@softlanding.com>.
There has been so much activity, it is hard to know what to quote, or
where to begin. I am just going to start with Greg's original email.
Greg Hudson <gh...@MIT.EDU> wrote on 10/12/2004 04:52:47 PM:
> Issue #1: Should "svn lock" implicitly include "svn update"?
>
> The document says yes. I believe that it is not intuitive for the
> verb "lock" to include an implicit update, and people may be surprised
> by the "helpful" behavior. Instead, I think lock should error out if
> the file is not up to date, with the error message instructing the
> user to update the file. (I'm fine with an explicit "svn lock
> --update" if and only if there is a considered belief that it would be
> a real convenience for users.)
I do not really understand the objections here. If you have to have an up
to date file in order to lock it, and we are trying to make this easy for
"users", then why shouldn't svn lock update the file automatically? OK,
maybe the verb could have been better than "lock", but the people this
feature is largely being written for are not going to care about that. At
a minimum, I think there has to be an option to do the update so that the
GUI's that are built can implement it this way. Ideally, I think that the
update should be the default, and there should perhaps be an option to not
do the update and error out if the file is out of date.
Having not come from a CVS background myself, I wish that the "checkout"
verb was still available to mean "get the latest and lock it". In my
world, that is what we call a "checkout".
> Issue #2: Should "svn update" resolve hijacks interactively?
>
> When people or their tools fail to play nicely, Subversion will find
> itself in the situation of having to resolve conflicts in a file which
> (through the svn:lock property) has been tagged as unmergeable. The
> document suggests resolving this issue by interactively asking the
> user whether to prefer the local edit or the repository edit, and
> leaving the other behind in a backup file.
I agree with you. Personally, I did not completely understand why the
existing behavior is not good enough. I think that it should try to
auto-resolve any conflicts and otherwise leave it for the user. If this
can be made better, than make it better for the non-locking scenarios too.
> Issue #3: Should lock messages be required?
>
> The document says that "svn lock" should pull up an editor and demand
> a lock message if the user does not provide one with the -m or -F
> option. The implication is that a GUI like tsvn would also request a
> lock message whenever the user locks a file (or files, if there's a
> way to select a bunch of files and lock them all in one go).
I would not object if lock messages were not required, but I would really
like to see them at least be optional. I think they are a great idea and
can really enhance usability, especially in GUI's. I kind of liked the
idea of being able to have a default lock message in a configuration file.
That seems like it would satisfy power users.
I suppose the lock message could be enforced by a hook script too, so
again, I am more interested in the feature itself than whether it is a
requirement.
> Issue #4: "svn lockinfo" command?
>
> As you all know, I've very keen on keeping our command set small.
> "svn lock" and "svn unlock" are pretty much non-negotiable for this
> feature, but when we already have "svn status" and "svn info", do we
> really need a separate "svn lockinfo"? I realize that svn info is a
> client-local operation and lock information has to be fetched from the
> server, but perhaps this could be an option to "svn info".
It seems like some good ideas have been proposed already. The main thing
is that there has to be a good way to interrogate lock information from
the repository. Would any information be stored in the WC? I think it
would be useful if an svn up brought down the information about what locks
were held. Even though that information could become stale, it could
still be useful to know that a file was locked without contacting the
server.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org