You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Peter N. Lundblad" <pe...@famlundblad.se> on 2004/12/14 18:11:29 UTC
[Locking] commit and unlock
Hi,
The current locking spec says that svn commit unlocks locked files that
are committed by default. I think this is a good default to prevent people
from forgetting to unlock, but it seems there was no consensus, so it
might be time for some discussion.
If we have this default, there will be a --keep-lock(s|ed)? option to let
people keep their locks. As I said, this is good. Having people often
forget to unlock could develop a habit of stealing locks as a "normal" way
of working. Somebody might argue that this is mxing up commands.
IN any case there is the question if only the committables (the files that
were actually changed) or all files specified by the targets (and possibly
recursively) should be unlocked. I think the latter is the best. If you
commit a subtree with some locked files, a lock shouldn't be left just
becvause the file wasn't modified. This could also need some dicsussion, I
suppose.
Any opinions?
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Wed, 15 Dec 2004, Jani Averbach wrote:
> On 2004-12-15 07:38-0600, Ben Collins-Sussman wrote:
> > On Dec 15, 2004, at 5:22 AM, Branko ??ibej wrote:
> > >John Szakmeister wrote:
> > >
> > >>I withdraw my objection. We should definitely release the locks. It
> > >>seems more intuitive for the users. While I may not consider having
> > >>a lock to be justification enough to consider it part of the commit
> > >>and release it, I can see many users thinking it is.
> > >>
> > >O.K., unlock the file, but only if it's an explicit target (I count
> > >any file in a subtree of a directory target to be explicit fo this
> > >case).
> > >
> > >However, then "svn st" must always show files that the WC thinks are
> > >locked, and these files should be listed in the log template along
> > >with the modified ones.
> > >
>
> +1
>
Sounds like we will go with locked files being committables in the sense
that they get unlocked if the commit unlocks at all. Some the commit item
harvesting will fetch locks everywhere and give to the server, including
descending into deleted subdirectories.
Thanks for the input,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2004-12-15 07:38-0600, Ben Collins-Sussman wrote:
> On Dec 15, 2004, at 5:22 AM, Branko ??ibej wrote:
> >John Szakmeister wrote:
> >
> >>I withdraw my objection. We should definitely release the locks. It
> >>seems more intuitive for the users. While I may not consider having
> >>a lock to be justification enough to consider it part of the commit
> >>and release it, I can see many users thinking it is.
> >>
> >O.K., unlock the file, but only if it's an explicit target (I count
> >any file in a subtree of a directory target to be explicit fo this
> >case).
> >
> >However, then "svn st" must always show files that the WC thinks are
> >locked, and these files should be listed in the log template along
> >with the modified ones.
> >
+1
>
> So essentially, it sounds like people want the client's wc
> commit-crawling algorithm to consider a locked-file a "committable"
> candidate, just like a modified item or schedule-add/delete item.
>
> If so, I agree with brane. 'svn st' will list a locked file as
> "interesting', whether or not it's been edited (which we were planning
> to do anyway), and if the crawler harvests the locked file as a
> "committable", then it should automatically show up in $EDITOR.
>
> But still, I'd like to hear more opinions...
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 15, 2004, at 5:22 AM, Branko Čibej wrote:
> John Szakmeister wrote:
>
>> I withdraw my objection. We should definitely release the locks. It
>> seems more intuitive for the users. While I may not consider having
>> a lock to be justification enough to consider it part of the commit
>> and release it, I can see many users thinking it is.
>>
> O.K., unlock the file, but only if it's an explicit target (I count
> any file in a subtree of a directory target to be explicit fo this
> case).
>
> However, then "svn st" must always show files that the WC thinks are
> locked, and these files should be listed in the log template along
> with the modified ones.
>
So essentially, it sounds like people want the client's wc
commit-crawling algorithm to consider a locked-file a "committable"
candidate, just like a modified item or schedule-add/delete item.
If so, I agree with brane. 'svn st' will list a locked file as
"interesting', whether or not it's been edited (which we were planning
to do anyway), and if the crawler harvests the locked file as a
"committable", then it should automatically show up in $EDITOR.
But still, I'd like to hear more opinions...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Bruce DeVisser <bm...@look.ca>.
On Fri, Dec 17, 2004 at 09:37:22AM +0100, Folker Schamel wrote:
> When using svn commit foo/, you are explicitely telling svn
> that you've done your work on the complete directory foo/.
No, you are explicitly telling svn you want to commit the
modifications in foo/ to the repository. Whether you are
done with your work in foo/ is irrelevant.
Bruce
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Julian Foad <ju...@btopenworld.com>.
Benjamin Pflugmann wrote:
> On Fri 2004-12-17 at 01:27:11 +0000, Julian Foad wrote:
> [...]
>
>>>As a project administrator, I often put locks on files that I don't want
>>>people to edit, even if I'm not actively working on it. I want to lock
>>>it and leave it, knowing that it will be preserved in that state until
>>>I'm ready for it.
>>
>>That sounds like a bit of a crude way of implementing access control. You
>>are free to do that if it works for you, but I don't think that this
>>discussion should by influenced by a desire to facilitate that usage.
>
> I understand locking to be mainly for serializing access, while
> authorization is mainly for controlling access. Please correct me, if
> I am wrong.
>
> So while freezing a branch in preparation for and during rolling a
> release could be implemented via authorization (or pre-commit hook),
> locking it seems the easier choice to me.
[...]
> I don't mean, that any emphasis should be put on the that. I just
> wanted to point out that while this is a bit in-between, this was not
> about misusing locking to implement authorization.
OK, I accept that. It's not "a crude way of implementing access control".
It's just a use case for wanting locked files to remain locked by default.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
On Fri 2004-12-17 at 01:27:11 +0000, Julian Foad wrote:
[...]
> >As a project administrator, I often put locks on files that I don't want
> >people to edit, even if I'm not actively working on it. I want to lock
> >it and leave it, knowing that it will be preserved in that state until
> >I'm ready for it.
>
> That sounds like a bit of a crude way of implementing access control. You
> are free to do that if it works for you, but I don't think that this
> discussion should by influenced by a desire to facilitate that usage.
I understand locking to be mainly for serializing access, while
authorization is mainly for controlling access. Please correct me, if
I am wrong.
So while freezing a branch in preparation for and during rolling a
release could be implemented via authorization (or pre-commit hook),
locking it seems the easier choice to me. Maybe Ben Reser likes that
idea. ;)
Similar for the case, when I want to show the current prototype to the
customer using the staging server and simply want prevent anyone
messing with me for the time in question (without having to disable
the post-commit hook that auto-updates the staging server). Seems a
clear case of serializing access to the resource to me. :)
I don't mean, that any emphasis should be put on the that. I just
wanted to point out that while this is a bit in-between, this was not
about misusing locking to implement authorization.
Bye,
Benjamin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, December 16, 2004 1:01 PM -0600 Ben Collins-Sussman
<su...@collab.net> wrote:
> I don't see much -- if any -- contention going on here. I and one other
> person initially objected to the idea of commits releasing locks by default
> (and in particular, releasing locks on unedited files). But then we were
> persuaded otherwise.
*I* still think that if lock is explicit, then unlock should be explicit. =)
> Decisions should be made through rational arguments and debates. Anyone on
> users@ is free to come in here and argue against what seems to be the
> popular opinion. At the moment, the only thing we're arguing about isn't
> which default to use, it's whether we're able to change behaviors later on.
I think this entire conversation shows the absurdity of trying to merge unlock
and commit behaviors. There's a tangled web in that direction and it's very
unlikely to do what some think it will no matter *what* we choose.
As long as I can set 'commit-keeps-locks = yes' in ~/.subversion/config, I'll
continue to be amused at these threads... =) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 16, 2004, at 12:41 PM, Jani Averbach wrote:
> On 2004-12-16 18:09+0000, Julian Foad wrote:
>> Ben Collins-Sussman wrote:
>>> On Dec 16, 2004, at 11:50 AM, Peter N. Lundblad wrote:
>>>> Do people agree that we unlock by default and don't on --keep-locked
>>>> switch? I'll assume so if I don't get massive objections:-)
>>>
>>> That certainly seems to be the consensus.
>>
>> As usual, I'll recommend providing explicit switches for both ways,
>> so that
>> the default need not be finalised in the first release that supports
>> locking. After one release worth of experience, we may have a better
>> idea
>> of what the default should be, or whether the default should be
>> configurable.
>
> Or what about if we use our svn-users list and ask there?
>
>
To quote maxb, I think we should be making a choice-by-logical-design,
not choice-by-whoever-shouts-loudest. :-)
I don't see much -- if any -- contention going on here. I and one
other person initially objected to the idea of commits releasing locks
by default (and in particular, releasing locks on unedited files). But
then we were persuaded otherwise.
Decisions should be made through rational arguments and debates.
Anyone on users@ is free to come in here and argue against what seems
to be the popular opinion. At the moment, the only thing we're arguing
about isn't which default to use, it's whether we're able to change
behaviors later on.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 16, 2004, at 12:57 PM, Julian Foad wrote:
> Jani Averbach wrote:
>> On 2004-12-16 18:09+0000, Julian Foad wrote:
>>> As usual, I'll recommend providing explicit switches for both ways,
>>> so that the default need not be finalised in the first release that
>>> supports locking. After one release worth of experience, we may have
>>> a better idea of what the default should be, or whether the default
>>> should be configurable.
>> Or what about if we use our svn-users list and ask there?
>
> That's effectively what we've been asking the developers' list. The
> trouble with asking "What would you want... ?" is that without the
> practical experience of using the feature and discovering the
> consequences of working with it in different ways, you won't get a
> reliable answer.
>
Well, that's why we have beta releases, right? Eventually we'll merge
the locking-branch to trunk, and we'll spend a while looking for
obvious bugs, testing locking ourselves. Then we'll do a 1.2-beta1
release as always, so bleeding-edge users can try it out, and send
complaints about horrible behavioral choices. We can then change the
UI in a 1.2-beta2 release if we want.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Julian Foad <ju...@btopenworld.com>.
Jani Averbach wrote:
> On 2004-12-16 18:09+0000, Julian Foad wrote:
>>As usual, I'll recommend providing explicit switches for both ways, so that
>>the default need not be finalised in the first release that supports
>>locking. After one release worth of experience, we may have a better idea
>>of what the default should be, or whether the default should be
>>configurable.
>
> Or what about if we use our svn-users list and ask there?
That's effectively what we've been asking the developers' list. The trouble
with asking "What would you want... ?" is that without the practical experience
of using the feature and discovering the consequences of working with it in
different ways, you won't get a reliable answer.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Julian Foad <ju...@btopenworld.com>.
Shawn Harrison wrote:
> I am a user who has been following this thread with interest. I
> implemented an advisory locking add-in for Microsoft Word, because we
> need some kind of locking mechanism to edit binary files. I've had six
> months of experience with "some kind of" locking mechanism with
> Subversion, in actual use. So, here's a user's perspective.
>
>>
>> Subject: User interface survey (command line)
>>
>> You have following working copy and you are about committing it:
>>
>> foo/
>> first_file.txt #locked, and modified
>> second_file.txt #locked, and unmodified
>>
>> svn commit ./foo
>>
>>
>> After that, what do you expect that will happen:
Well, that depends on why I am committing after only changing one of the files.
If I have decided that the changes are complete, and the second file happened
to need no change, then I expect (or want) one behaviour; if I am making a
partial commit and then will want to continue working on the files, then I
expect (or want) the other behaviour.
Note that if I had finished working on the first file and wanted to commit it
by itself, then this scenario would be inappropriate: I would expect to have to
use a commit command that identified that file by itself. I would have to do
so if I had already started to modify the second file, and so it would be
logical to do so even if I had not already started to modify the second file.
>> a) first_file.txt will been shown on the modified file list (on your
>> commit log editor), and it is still locked after the commit.
>
> This is what I would expect, that locking and committing are two
> different activities. I often commit partway through a lock, and I don't
> expect that I've lost my exclusive hold until I say so. "Commit" doesn't
> mean "check-in", just as "update" doesn't mean "check-out". This isn't a
> library, with only one copy of the file. This is a working copy of the
> repository.
What a word or a command means to you depends on how you have been taught. If
you had read the Subversion documentation in a certain frame of mind (I'm not
sying you haven't read it) then you would recognise "commit" and "ci" (short
for "check-in") as synonyms within the context of a Subversion that has no locking.
When we introduce a new feature like locking, we have to re-evaluate our
concepts and how they map to command names. Should we now say that "commit"
and "ci" are no longer strictly synonyms when locks are involved? Perhaps they
should have different defaults with respect to locks? Perhaps they should have
different actions with respect to locks, and no flags to alter that: they would
become separate commands. This would still be backward-compatible becaus they
would still behave the same as each other (and as they always did) in the
absence of locks.
[snip: locks help to avoid simultaneous changes to an unmergeable file]
> Leaving
> the locks in place is insurance against this kind of mess. Removing them
> by default potentially undermines the reason for implementing them in
> the first place.
Well, this idea of having a single "default" is a bit hairy. There are clearly
use cases where "commit and unlock" is most appropriate, and other use cases
where "commit and don't touch locks" is most appropriate. If we pick either of
those to be the default meaning of both "svn commit" and "svn checkin", then
> You could add something to the commit output to remind the user that the
> lock is still being held.
That is a potentially very good idea that I haven't heard or thought of.
>> b) first_file.txt will been shown on the modified file list (on your
>> commit log editor), and it is unlocked after the commit
>> (second_file.txt will be still locked).
>
> This is acceptable as long as I am notified that this has happened. But
> I would probably set my auto prop to no_unlock anyway.
(I don't know what "auto prop" you think you might be able to set.)
>> c) first_file.txt and second_file.txt have been shown on the
>> modified file list, and both of them have been unlocked after
>> the commit (even when content of second_file.txt was unmodified).
>
> This is pernicious, and it is Microsoftesque: The program is telling me
> it knows better than I do what I intend. If I locked a file and didn't
> work on it, it means I still want it locked. What a pain to lock a bunch
> of files, work on one, commit it, and have all my locks undone by
> so-called smart software.
Whoa! Hold on. No, no, no. It's just a matter of what concept we attach to
the command. Let's say you use the command "ci" (check-in) instead of
"commit". Does that make sense then? You are asking Subversion to check in
(commit and unlock) these two files. It does so. No problem. The only
problem is if you don't like using the command named "commit" to perform a
check-in.
(I am using your terminology here, not saying that Subversion should
necessarily adopt this terminology distinction, though perhaps it should.)
> If someone on the team _is_ stupid and gratuitously locks stuff he's not
> working on, then this is a human problem with a human solution:
> training, public shamings, reprisals, whatever.
Agreed.
> I don't like to have the
> software implement policy, because that is a passive-aggressive approach
> to life, and I've had enough of that from sysadmins for two lifetimes.
I suppose you mean that if the plain "svn commit" or "svn ci" command unlocks
files, then it's setting (or at least encouraging) a policy of not holding a
lock throughout a series of commits. It's not enforcing that policy, because
you can add "--no-unlock".
I suppose that someone who customarily hold a lock through a series of commits
will not be happy if the plain "commit" command (without a switch) unlocks files.
> As a project administrator, I often put locks on files that I don't want
> people to edit, even if I'm not actively working on it. I want to lock
> it and leave it, knowing that it will be preserved in that state until
> I'm ready for it.
That sounds like a bit of a crude way of implementing access control. You are
free to do that if it works for you, but I don't think that this discussion
should by influenced by a desire to facilitate that usage.
>> d) Something else, please tell us what?
>
> You could implement a new svn client command to do "commit and unlock".
> E.g., "svn cu target". Then you can easily get result (c) when you
> actually want it. If the file isn't locked, no harm done -- just as when
> you do "svn ci target" and target has not changed.
Yes, a command to do that is very much wanted I think. What that command
should be is a big question. ("checkin" ... except for the confusion with "ci"
being a synonym for "commit")
> One thing that I haven't seen discussed (I might have missed this) is
> what happens when a locally modified file is unlocked: If there are
> local changes, it would seem that the file should be committed before it
> is unlocked.
Why? Or do you mean "should be committed or reverted"?
> So in that case I would expect "svn unlock target" to fail
> with a warning, unless I use --force.
>
> Individual files and folders could have a svn:property that overrides
> the default behavior.
In what way? Basically, yuck! unless there is a very strong reason for this.
> Another thing that I love about Subversion is that it is extremely
> well-designed. So I realize that you guys really don't need my input.
> But I appreciate the opportunity to offer it.
Your input is valuable when we have difficult decisions to make and you have
real-world experience. Even though I have argued against most of what you
wrote, it brings up useful new points and ideas and makes the whole discussion
better.
- Julian
>
> Shawn Harrison
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Folker Schamel <sc...@spinor.com>.
>>
>> c) first_file.txt and second_file.txt have been shown on the
>> modified file list, and both of them have been unlocked after
>> the commit (even when content of second_file.txt was unmodified).
>
>
> This is pernicious, and it is Microsoftesque: The program is telling me
> it knows better than I do what I intend. If I locked a file and didn't
> work on it, it means I still want it locked.
But if you only worked on first_file.txt, you should have been
trained to only svn commit foo/first_file.txt, don't you agree? ;-)
When using svn commit foo/, you are explicitely telling svn
that you've done your work on the complete directory foo/.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Branko Čibej <br...@xbc.nu>.
Shawn Harrison wrote:
> Jani Averbach wrote:
>
>> c) first_file.txt and second_file.txt have been shown on the
>> modified file list, and both of them have been unlocked after
>> the commit (even when content of second_file.txt was unmodified).
>
>
> This is pernicious, and it is Microsoftesque: The program is telling
> me it knows better than I do what I intend.
Oh, I can't resist turning this one right back at you, in two different
ways :-)
* If you intend to commit one file but not the other, then you
should say so on the command line
* SVN is already knows better than you not to commit files with no
textual changes, yet you don't object.
> If I locked a file and didn't work on it, it means I still want it
> locked. What a pain to lock a bunch of files, work on one, commit it,
> and have all my locks undone by so-called smart software.
>
> A plea: One of the things that I love about Subversion is that it
> treats me like I know what I'm doing.
Well, "know what you're doing" is mostly the same as "know how the
software behaves". The difference between SVN's unlocking unchanged
files and "Microsofesque" is that the latter would leave you no
alternative or workaround, whilst you can always tell SVN to commit only
specific files.
> One thing that I haven't seen discussed (I might have missed this) is
> what happens when a locally modified file is unlocked: If there are
> local changes, it would seem that the file should be committed before
> it is unlocked. So in that case I would expect "svn unlock target" to
> fail with a warning, unless I use --force.
I agree with this part: allow a "svn unlock" only if the target isn't
modified, unless with --force. Usually you'd want to "svn revert" the
local changes anyway, and revert will remove the lock. Or will it?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Jim Correia <ji...@pobox.com>.
On Dec 16, 2004, at 7:50 PM, Ben Collins-Sussman wrote:
> But the main use-case (that's been posited here over and over) is that
> the "most common" scenario is for a user to lock a whole directory
> full of things they "might" need to change. Then, after working,
> they've discovered that they've only edited half of them.
>
> * should we "be literal" and have 'svn commit' only unlock the
> edited files?
> This is unfriendly to the user. Now they have to remember to
> unlock the others.
>
> * should we "be friendly" and unlock every file we see, edited or
> not?
> This is friendly, but now we're blurring concepts and
> second-guessing users.
>
> I guess the meta-debate here is: "is this really a common scenario or
> not?" Should we be making svn "smart" just for this one use-case?
Why would someone lock a whole directory worth of things just in case?
That seems absurd to me :-)
I use Perforce as work, which supports locking. Though I rarely need it
since the majority of the files we have under Perforce revision control
are merge-able text files, when we do use locking we never gratuitously
lock just in case.
Additional Perforce requires that you "p4 edit" a file before making
changes to it. We don't go around p4 edit-ing files just in case we
have to make changes - we p4 edit them as necessary.
As far as unlock on commit, if a file has been modified it should
certainly be unlocked on commit. (I don't know if this is even up for
discussion anymore - it has been a long thread.) Looking at Perforce
for prior art, the docs for p4 lock say:
Locking files prevents all other users from submitting
changes to those files. If the files are already locked by
another user, p4 lock fails. When the user who locked a
particular file submits the file, the lock is released.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 16, 2004, at 5:52 PM, Shawn Harrison wrote:
>
> If someone on the team _is_ stupid and gratuitously locks stuff he's
> not working on, then this is a human problem with a human solution:
> training, public shamings, reprisals, whatever. I don't like to have
> the software implement policy, because that is a passive-aggressive
> approach to life, and I've had enough of that from sysadmins for two
> lifetimes.
Heh, I agree in general...
But the main use-case (that's been posited here over and over) is that
the "most common" scenario is for a user to lock a whole directory full
of things they "might" need to change. Then, after working, they've
discovered that they've only edited half of them.
* should we "be literal" and have 'svn commit' only unlock the
edited files?
This is unfriendly to the user. Now they have to remember to
unlock the others.
* should we "be friendly" and unlock every file we see, edited or
not?
This is friendly, but now we're blurring concepts and
second-guessing users.
I guess the meta-debate here is: "is this really a common scenario or
not?" Should we be making svn "smart" just for this one use-case?
> One thing that I haven't seen discussed (I might have missed this) is
> what happens when a locally modified file is unlocked: If there are
> local changes, it would seem that the file should be committed before
> it is unlocked. So in that case I would expect "svn unlock target" to
> fail with a warning, unless I use --force.
>
Hm, that's an interesting idea. Might be friendly. But is it likely?
Will someone ever "accidentally" unlock a file without committing
first?
> Another thing that I love about Subversion is that it is extremely
> well-designed. So I realize that you guys really don't need my input.
> But I appreciate the opportunity to offer it.
Thanks for the input!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Shawn Harrison <ha...@tbc.net>.
Jani Averbach wrote:
> Or what about if we use our svn-users list and ask there?
I am a user who has been following this thread with interest. I
implemented an advisory locking add-in for Microsoft Word, because we
need some kind of locking mechanism to edit binary files. I've had six
months of experience with "some kind of" locking mechanism with
Subversion, in actual use. So, here's a user's perspective.
>
> Subject: User interface survey (command line)
>
> You have following working copy and you are about committing it:
>
> foo/
> first_file.txt #locked, and modified
> second_file.txt #locked, and unmodified
>
> svn commit ./foo
>
>
> After that, what do you expect that will happen:
>
> a) first_file.txt will been shown on the modified file list (on your
> commit log editor), and it is still locked after the commit.
This is what I would expect, that locking and committing are two
different activities. I often commit partway through a lock, and I don't
expect that I've lost my exclusive hold until I say so. "Commit" doesn't
mean "check-in", just as "update" doesn't mean "check-out". This isn't a
library, with only one copy of the file. This is a working copy of the
repository.
Bear in mind: With binary files, the consequences of editing without a
lock are potentially more costly than the consequences of holding a lock
that is no longer in use and thus locking someone out. Waiting a week to
work on a file is less trouble than merging changes from two different
Word documents. And with Word, merging is relatively straightforward,
because there is a reliable diff2 mechanism (Word's "merge" function, on
the other hand, is horribly broken: let the buyer beware): Give a typist
the two diffs and training him/her to merge them with tags showing who
did what. Then the editor reads through and decides. Okay. It's a lot
easier to wait a week. And I can't imagine what would be required to
merge changes to two different Adobe Illustrator file versions. Leaving
the locks in place is insurance against this kind of mess. Removing them
by default potentially undermines the reason for implementing them in
the first place.
My implementation of advisory locking works this way, and in that case
each lock/unlock is committed as a revision, because it involves
creating/deleting a file. With locking as an unversioned property, it
makes even more sense to do it this way, because committing doesn't have
anything to do with locking.
You could add something to the commit output to remind the user that the
lock is still being held.
>
> b) first_file.txt will been shown on the modified file list (on your
> commit log editor), and it is unlocked after the commit
> (second_file.txt will be still locked).
This is acceptable as long as I am notified that this has happened. But
I would probably set my auto prop to no_unlock anyway.
>
> c) first_file.txt and second_file.txt have been shown on the
> modified file list, and both of them have been unlocked after
> the commit (even when content of second_file.txt was unmodified).
This is pernicious, and it is Microsoftesque: The program is telling me
it knows better than I do what I intend. If I locked a file and didn't
work on it, it means I still want it locked. What a pain to lock a bunch
of files, work on one, commit it, and have all my locks undone by
so-called smart software.
A plea: One of the things that I love about Subversion is that it treats
me like I know what I'm doing.
If someone on the team _is_ stupid and gratuitously locks stuff he's not
working on, then this is a human problem with a human solution:
training, public shamings, reprisals, whatever. I don't like to have the
software implement policy, because that is a passive-aggressive approach
to life, and I've had enough of that from sysadmins for two lifetimes.
As a project administrator, I often put locks on files that I don't want
people to edit, even if I'm not actively working on it. I want to lock
it and leave it, knowing that it will be preserved in that state until
I'm ready for it.
>
> d) Something else, please tell us what?
>
You could implement a new svn client command to do "commit and unlock".
E.g., "svn cu target". Then you can easily get result (c) when you
actually want it. If the file isn't locked, no harm done -- just as when
you do "svn ci target" and target has not changed.
One thing that I haven't seen discussed (I might have missed this) is
what happens when a locally modified file is unlocked: If there are
local changes, it would seem that the file should be committed before it
is unlocked. So in that case I would expect "svn unlock target" to fail
with a warning, unless I use --force.
Individual files and folders could have a svn:property that overrides
the default behavior.
--
Another thing that I love about Subversion is that it is extremely
well-designed. So I realize that you guys really don't need my input.
But I appreciate the opportunity to offer it.
Shawn Harrison
Senior Editor
Tyndale House Publishers
________________
harrison@tbc.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2004-12-16 18:09+0000, Julian Foad wrote:
> Ben Collins-Sussman wrote:
> >On Dec 16, 2004, at 11:50 AM, Peter N. Lundblad wrote:
> >>Do people agree that we unlock by default and don't on --keep-locked
> >>switch? I'll assume so if I don't get massive objections:-)
> >
> >That certainly seems to be the consensus.
>
> As usual, I'll recommend providing explicit switches for both ways, so that
> the default need not be finalised in the first release that supports
> locking. After one release worth of experience, we may have a better idea
> of what the default should be, or whether the default should be
> configurable.
Or what about if we use our svn-users list and ask there?
Subject: User interface survey (command line)
You have following working copy and you are about committing it:
foo/
first_file.txt #locked, and modified
second_file.txt #locked, and unmodified
svn commit ./foo
After that, what do you expect that will happen:
a) first_file.txt will been shown on the modified file list (on your
commit log editor), and it is still locked after the commit.
b) first_file.txt will been shown on the modified file list (on your
commit log editor), and it is unlocked after the commit
(second_file.txt will be still locked).
c) first_file.txt and second_file.txt have been shown on the
modified file list, and both of them have been unlocked after
the commit (even when content of second_file.txt was unmodified).
d) Something else, please tell us what?
Let's the masses raise their voice.
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Thu, 16 Dec 2004, Julian Foad wrote:
> Ben Collins-Sussman wrote:
> > On Dec 16, 2004, at 11:50 AM, Peter N. Lundblad wrote:
> >> Do people agree that we unlock by default and don't on --keep-locked
> >> switch? I'll assume so if I don't get massive objections:-)
> >
> > That certainly seems to be the consensus.
>
> As usual, I'll recommend providing explicit switches for both ways, so that the
> default need not be finalised in the first release that supports locking.
> After one release worth of experience, we may have a better idea of what the
> default should be, or whether the default should be configurable.
>
How would you do without a default? Error out if a any lock is discovered?
If we want to add an option for the oposite later, or add it to the
configuration files, we might want to use --no-unlock (so we can add
--unlock). Opinions?
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Fri, 17 Dec 2004, Benjamin Pflugmann wrote:
> On Thu 2004-12-16 at 12:19:01 -0600, Ben Collins-Sussman wrote:
> [...]
> > That said, we could create a new ~/.subversion/config variable called
> > "commit-keeps-locks = yes", or "always-keep-locks" or something.
>
> Sorry, this is just kind of a drive-by proposal, but I didn't see it
> mentioned yet, so I thought I bring it up:
>
> How about something like
>
> svn lock [--persistent|--temporary]
>
> in addition to / instead of the user-config, which would note (only in
> the WC) with the lock whether to rather keep it or remove it on
> actions where a lock might reasonably be released (in practice, it's
> only "commit", isn't it?)
>
> The suggestion is because I see me using both kinds of
> "always-keep-locks" settings, depending on whether I expect to finish
> up fast (like in 1-2 hours) and do only one commit, or if I expect the
> work to consist of several stages (and so commits).
>
This could be one way of doing it, but I don't think it buys you anything
compared to the current spec. YOu could as well use --no-unlock on the
commit before running to the bus:-)
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
On Thu 2004-12-16 at 12:19:01 -0600, Ben Collins-Sussman wrote:
[...]
> That said, we could create a new ~/.subversion/config variable called
> "commit-keeps-locks = yes", or "always-keep-locks" or something.
Sorry, this is just kind of a drive-by proposal, but I didn't see it
mentioned yet, so I thought I bring it up:
How about something like
svn lock [--persistent|--temporary]
in addition to / instead of the user-config, which would note (only in
the WC) with the lock whether to rather keep it or remove it on
actions where a lock might reasonably be released (in practice, it's
only "commit", isn't it?)
The suggestion is because I see me using both kinds of
"always-keep-locks" settings, depending on whether I expect to finish
up fast (like in 1-2 hours) and do only one commit, or if I expect the
work to consist of several stages (and so commits).
Bye,
Benjamin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 16, 2004, at 12:09 PM, Julian Foad wrote:
> Ben Collins-Sussman wrote:
>> On Dec 16, 2004, at 11:50 AM, Peter N. Lundblad wrote:
>>> Do people agree that we unlock by default and don't on --keep-locked
>>> switch? I'll assume so if I don't get massive objections:-)
>> That certainly seems to be the consensus.
>
> As usual, I'll recommend providing explicit switches for both ways, so
> that the default need not be finalised in the first release that
> supports locking. After one release worth of experience, we may have a
> better idea of what the default should be, or whether the default
> should be configurable.
>
I'm pretty sure this isn't an option. We try to resist adding extra
switches to command whenever we can, and it's a big no-no to *remove* a
1.2 switch in a 1.3 release.
So I think 'svn commit' will release locks by default, and have a
single --keep-locks option.
That said, we could create a new ~/.subversion/config variable called
"commit-keeps-locks = yes", or "always-keep-locks" or something.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Julian Foad <ju...@btopenworld.com>.
Greg Hudson wrote:
> On Thu, 2004-12-16 at 13:09, Julian Foad wrote:
>
>>As usual, I'll recommend providing explicit switches for both ways, so that the
>>default need not be finalised in the first release that supports locking.
>>After one release worth of experience, we may have a better idea of what the
>>default should be, or whether the default should be configurable.
>
> I don't think it would be at all reasonable to change the default for an
> option like this in a later 1.x release. We're stuck with the default
> we choose for 1.2.
Exactly, and we might not want to get stuck. What I meant was that by
providing switches for both ways, we don't have to choose a default yet: the
command fails if a target is locked and neither switch was given. Then we will
still be free to choose a default later.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2004-12-16 at 13:09, Julian Foad wrote:
> As usual, I'll recommend providing explicit switches for both ways, so that the
> default need not be finalised in the first release that supports locking.
> After one release worth of experience, we may have a better idea of what the
> default should be, or whether the default should be configurable.
I don't think it would be at all reasonable to change the default for an
option like this in a later 1.x release. We're stuck with the default
we choose for 1.2.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Julian Foad <ju...@btopenworld.com>.
Ben Collins-Sussman wrote:
> On Dec 16, 2004, at 11:50 AM, Peter N. Lundblad wrote:
>> Do people agree that we unlock by default and don't on --keep-locked
>> switch? I'll assume so if I don't get massive objections:-)
>
> That certainly seems to be the consensus.
As usual, I'll recommend providing explicit switches for both ways, so that the
default need not be finalised in the first release that supports locking.
After one release worth of experience, we may have a better idea of what the
default should be, or whether the default should be configurable.
But I feel I'm rather alone in this view. Most people seem to want a default
to be decided and implemented straight away. If that's what we do, I'm happy
with the default being "unlock" (meaning unlock all of the targets) as
suggested above.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Thu, 16 Dec 2004, Philip Martin wrote:
> "Peter N. Lundblad" <pe...@famlundblad.se> writes:
>
> > Roger, Roger. I use --keep-locked because that's the same for singular and
> > plural, BTW.
>
> Following the pattern of --no-auto-props, --no-auth-cache, etc. how
> about --no-unlock?
>
Yes, I think that's a good idea. See my other posting.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Philip Martin <ph...@codematters.co.uk>.
"Peter N. Lundblad" <pe...@famlundblad.se> writes:
> Roger, Roger. I use --keep-locked because that's the same for singular and
> plural, BTW.
Following the pattern of --no-auto-props, --no-auth-cache, etc. how
about --no-unlock?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Thu, 16 Dec 2004, Ben Collins-Sussman wrote:
>
> On Dec 16, 2004, at 11:50 AM, Peter N. Lundblad wrote:
> >
> >
> > Do people agree that we unlock by default and don't on --keep-locked
> > switch? I'll assume so if I don't get massive objections:-)
> >
>
> That certainly seems to be the consensus.
>
> When you modify 'svn commit', see if you can add an extra sentence to
> the 'svn help commit' text, noting that any locks discovered will be
> unlocked.
>
Roger, Roger. I use --keep-locked because that's the same for singular and
plural, BTW.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 16, 2004, at 11:50 AM, Peter N. Lundblad wrote:
>
>
> Do people agree that we unlock by default and don't on --keep-locked
> switch? I'll assume so if I don't get massive objections:-)
>
That certainly seems to be the consensus.
When you modify 'svn commit', see if you can add an extra sentence to
the 'svn help commit' text, noting that any locks discovered will be
unlocked.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Thu, 16 Dec 2004, [UTF-8] Branko �^Libej wrote:
> Peter N. Lundblad wrote:
>
> >On Wed, 15 Dec 2004, Julian Foad wrote:
> >
> >>>John Szakmeister wrote:
> >>>O.K., unlock the file, but only if it's an explicit target (I count any
> >>>file in a subtree of a directory target to be explicit fo this case).
> >>>
> >>>
> >What would be an non-explicit target? The implicit "."? That would be
> >inconsistent. Saying "svn ci foo.c" won't commit bar.cin the same
> >directory. Just trying to understand what you meant here, brane.
> >
> >
> Actually, I find that I don't know myself what I meant here... possibly
> that we don't unlock "bar/qux" if you commit "foo", but that's obvious.
>
OK. We are in aggreement then.
Do people agree that we unlock by default and don't on --keep-locked
switch? I'll assume so if I don't get massive objections:-)
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Branko Čibej <br...@xbc.nu>.
Peter N. Lundblad wrote:
>On Wed, 15 Dec 2004, Julian Foad wrote:
>
>
>
>>Branko Čibej wrote:
>>
>>
>>>John Szakmeister wrote:
>>>O.K., unlock the file, but only if it's an explicit target (I count any
>>>file in a subtree of a directory target to be explicit fo this case).
>>>
>>>
>What would be an non-explicit target? The implicit "."? That would be
>inconsistent. Saying "svn ci foo.c" won't commit bar.cin the same
>directory. Just trying to understand what you meant here, brane.
>
>
Actually, I find that I don't know myself what I meant here... possibly
that we don't unlock "bar/qux" if you commit "foo", but that's obvious.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Wed, 15 Dec 2004, Julian Foad wrote:
> Branko Čibej wrote:
> > John Szakmeister wrote:
> > O.K., unlock the file, but only if it's an explicit target (I count any
> > file in a subtree of a directory target to be explicit fo this case).
>
What would be an non-explicit target? The implicit "."? That would be
inconsistent. Saying "svn ci foo.c" won't commit bar.cin the same
directory. Just trying to understand what you meant here, brane.
> > However, then "svn st" must always show files that the WC thinks are
> > locked, and these files should be listed in the log template along with
> > the modified ones.
>
> I hadn't thought of that aspect, but I completely agree with you. (It's a pity
> that "status" already uses "L" for a different type of lock. We'll just have
> to find a way to distinguish these new locks.)
>
Yes. This terminology problem is even apparent in the code. The WC already
talks about locking. Suggestions welcome. Also, I have been planning to
start another thread about how to compatibly extend svn st and other
output for locking. So people can actually start thinking about that:-)
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> John Szakmeister wrote:
> O.K., unlock the file, but only if it's an explicit target (I count any
> file in a subtree of a directory target to be explicit fo this case).
Certainly. (I never meant to suggest that "svn commit foo" should unlock
everything in the WC that contains "foo"!)
> However, then "svn st" must always show files that the WC thinks are
> locked, and these files should be listed in the log template along with
> the modified ones.
I hadn't thought of that aspect, but I completely agree with you. (It's a pity
that "status" already uses "L" for a different type of lock. We'll just have
to find a way to distinguish these new locks.)
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Branko Čibej <br...@xbc.nu>.
John Szakmeister wrote:
>I withdraw my objection. We should definitely release the locks. It
>seems more intuitive for the users. While I may not consider having a
>lock to be justification enough to consider it part of the commit and
>release it, I can see many users thinking it is.
>
>
O.K., unlock the file, but only if it's an explicit target (I count any
file in a subtree of a directory target to be explicit fo this case).
However, then "svn st" must always show files that the WC thinks are
locked, and these files should be listed in the log template along with
the modified ones.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by John Szakmeister <jo...@szakmeister.net>.
On Tuesday 14 December 2004 18:40, Julian Foad wrote:
> John Szakmeister wrote:
> > Ben Collins-Sussman wrote:
> >>I disagree about this. People often have multiple changesets going
> >>on in their working copies. For example, I may lock foo/bar/baz.jpg
> >>because I plan to edit it as part of Changeset A. Then I might
> >>switch gears and change a bunch of other files in foo/bar/, as part
> >>of Changeset B. Then I run 'svn commit foo/bar/' to commit Changeset
> >>B. I would be really annoyed if that released my lock on baz.jpg!
> >
> > I agree with you Ben. I often have several changes running through
> > my working copy.
>
> See my reply to Ben: how do you justify wanting any locks on unchanged
> sibling files to be left alone while, already, any changes to sibling
> files get committed?
IMHO, if the file isn't modified (whether it has a lock or not), it
shouldn't be committed. Hence, the lock should remain. It was that
simple.
I can see arguments the other direction too though, especially in the case
of the clumsy user who locks a bunch of stuff, edits the one file that
was important, and then commits. Hmph. I suppose that now that I think
about it, Julian and Peter have a point. I can definitely see if we
didn't release the locks, that people would end up stealing them on a
regular basis. I see another use case in favor of this too. Mainly, I
want to ensure that some related files don't get changed while I modify
one of the files in the group (this would be handy for me today if I
could do it).
I withdraw my objection. We should definitely release the locks. It
seems more intuitive for the users. While I may not consider having a
lock to be justification enough to consider it part of the commit and
release it, I can see many users thinking it is.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Bruce DeVisser <bm...@look.ca>.
On Wed, Dec 15, 2004 at 01:51:58PM +0100, Folker Schamel wrote:
> Bruce DeVisser wrote:
> > On Wed, Dec 15, 2004 at 02:53:36AM +0100, Folker Schamel wrote:
> >
> >>What is the practical advantage of not unlocking unmodified files?
> >
> >
> > Perhaps the locker wants to force the file to remain
> > unmodified (by anyone). Someone in an administrative
> > capacity might wish to do this as a partial code freeze.
>
> This argument holds in the same way for modified and
> unmodified files. -> so it is an argument for committing
> without releasing locks at all.
>
> -> but what is the practical advantage of unlocking
> modified, but not unlocking unmodified files belonging to
> the same commit?
Valid point, *if* you think committing modified files should
unlock them.
Personally I would prefer that it be a user-configurable
option, overrideable on the command line.
Bruce
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Folker Schamel <sc...@spinor.com>.
Bruce DeVisser wrote:
> On Wed, Dec 15, 2004 at 02:53:36AM +0100, Folker Schamel wrote:
>
>>What is the practical advantage of not unlocking unmodified files?
>
>
> Perhaps the locker wants to force the file to remain
> unmodified (by anyone). Someone in an administrative
> capacity might wish to do this as a partial code freeze.
This argument holds in the same way for modified and unmodified files.
-> so it is an argument for committing without releasing locks at all.
-> but what is the practical advantage of unlocking modified,
but not unlocking unmodified files belonging to the same commit?
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Bruce DeVisser <bm...@look.ca>.
On Wed, Dec 15, 2004 at 02:53:36AM +0100, Folker Schamel wrote:
> What is the practical advantage of not unlocking unmodified files?
Perhaps the locker wants to force the file to remain
unmodified (by anyone). Someone in an administrative
capacity might wish to do this as a partial code freeze.
(Pre-commit hooks are server-side and not as easy to work
with.)
Bruce
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Folker Schamel <sc...@spinor.com>.
Ben Collins-Sussman wrote:
>
> On Dec 14, 2004, at 5:40 PM, Julian Foad wrote:
>
>> John Szakmeister wrote:
>>
>>> Ben Collins-Sussman wrote:
>>>
>>>> I disagree about this. People often have multiple changesets going
>>>> on in their working copies. For example, I may lock foo/bar/baz.jpg
>>>> because I plan to edit it as part of Changeset A. Then I might
>>>> switch gears and change a bunch of other files in foo/bar/, as part
>>>> of Changeset B. Then I run 'svn commit foo/bar/' to commit Changeset
>>>> B. I would be really annoyed if that released my lock on baz.jpg!
>>>
>>> I agree with you Ben. I often have several changes running through my
>>> working copy.
>>
>>
>> See my reply to Ben: how do you justify wanting any locks on unchanged
>> sibling files to be left alone while, already, any changes to sibling
>> files get committed?
>>
>
> The justification for my opinion is that I consider "locking" and
> "changing" files to be independent actions. They aren't related to each
> other; they live in different dimensions.
>
> - a file can be changed, but not locked.
> - a file can be locked, but not changed.
> - a changed file can be committed, but the lock can remain.
> - a file can be unlocked, but still have local changes.
>
> In my world, the "commit" command finds all changed files, and commits
> them. A locked file doesn't qualify as a "changed" file in and of
> itself. That simple.
>
> This logic is consistent, I think, with everyone's objection to the idea
> of blurring the line between "svn lock" and "svn update" command. We
> deliberately separated them: locking doesn't cause an update. Nor does
> unlocking cause a commit. Once again, the idea here is that a file
> lock/unlock state has nothing do with pushing or pulling data.
>
> In a perfect world, I think neither 'svn up' nor 'svn commit' should
> affect lock states at all. But I can understand adding a *convenience*
> switch so that things which are committed automatically get unlocked.
> (Just like cmpilato and I would like to see a convenience switch that
> causes 'svn lock' to automatically update something.)
>
> But unlocking things that were never committed? That's just completely
> blurring concepts.
Both perspectives are reasonable;
I personally would prefer unlocking unmodified files.
Scenario:
I want to work on diagram image files in a folder
documentation/diagrams/*.gif
Since I don't know which files I'm going to modify,
I lock all these files.
But then, when working on the documentation,
I only have to modify some of them.
At the end, I svn commit documentation/diagrams.
Not unlocking all files in this directory would make
it likely that these locks accidently remain "forever".
I would say that locking means telling other users
"I'm planning to modifiy these unmergable files.
Please don't modify them in parallel.",
but locking is no "promise" of modifying these file.
What is the practical advantage of not unlocking unmodified files?
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 14, 2004, at 5:40 PM, Julian Foad wrote:
> John Szakmeister wrote:
>> Ben Collins-Sussman wrote:
>>> I disagree about this. People often have multiple changesets going
>>> on in their working copies. For example, I may lock foo/bar/baz.jpg
>>> because I plan to edit it as part of Changeset A. Then I might
>>> switch gears and change a bunch of other files in foo/bar/, as part
>>> of Changeset B. Then I run 'svn commit foo/bar/' to commit Changeset
>>> B. I would be really annoyed if that released my lock on baz.jpg!
>> I agree with you Ben. I often have several changes running through my
>> working copy.
>
> See my reply to Ben: how do you justify wanting any locks on unchanged
> sibling files to be left alone while, already, any changes to sibling
> files get committed?
>
The justification for my opinion is that I consider "locking" and
"changing" files to be independent actions. They aren't related to
each other; they live in different dimensions.
- a file can be changed, but not locked.
- a file can be locked, but not changed.
- a changed file can be committed, but the lock can remain.
- a file can be unlocked, but still have local changes.
In my world, the "commit" command finds all changed files, and commits
them. A locked file doesn't qualify as a "changed" file in and of
itself. That simple.
This logic is consistent, I think, with everyone's objection to the
idea of blurring the line between "svn lock" and "svn update" command.
We deliberately separated them: locking doesn't cause an update. Nor
does unlocking cause a commit. Once again, the idea here is that a
file lock/unlock state has nothing do with pushing or pulling data.
In a perfect world, I think neither 'svn up' nor 'svn commit' should
affect lock states at all. But I can understand adding a *convenience*
switch so that things which are committed automatically get unlocked.
(Just like cmpilato and I would like to see a convenience switch that
causes 'svn lock' to automatically update something.)
But unlocking things that were never committed? That's just completely
blurring concepts.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Julian Foad <ju...@btopenworld.com>.
John Szakmeister wrote:
> Ben Collins-Sussman wrote:
>>I disagree about this. People often have multiple changesets going
>>on in their working copies. For example, I may lock foo/bar/baz.jpg
>>because I plan to edit it as part of Changeset A. Then I might
>>switch gears and change a bunch of other files in foo/bar/, as part
>>of Changeset B. Then I run 'svn commit foo/bar/' to commit Changeset
>>B. I would be really annoyed if that released my lock on baz.jpg!
>
> I agree with you Ben. I often have several changes running through my
> working copy.
See my reply to Ben: how do you justify wanting any locks on unchanged sibling
files to be left alone while, already, any changes to sibling files get committed?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by John Szakmeister <jo...@szakmeister.net>.
Ben Collins-Sussman wrote:
[snip]
>
> I disagree about this. People often have multiple changesets going
> on in their working copies. For example, I may lock foo/bar/baz.jpg
> because I plan to edit it as part of Changeset A. Then I might
> switch gears and change a bunch of other files in foo/bar/, as part
> of Changeset B. Then I run 'svn commit foo/bar/' to commit Changeset
> B. I would be really annoyed if that released my lock on baz.jpg!
I agree with you Ben. I often have several changes running through my
working copy.
> My feeling is: 'svn commit' should only change the things it
> committed. That's how it works now, and it seems pretty simple and
> clear. If 'svn commit' started removing locks just because they're
> "nearby" things that were committed, we'd be violating the rule.
+1.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Shawn Harrison <ha...@tbc.net>.
Bruce DeVisser wrote [12/17/04 12:40 AM]:
> [...]
> Perhaps I have a difference viewpoint because I work in an
> environment where locking is enforced. Developers have
> non-trivial work to do on multiple files, and typically the
> scope of work is known ahead of time (eg, 15 files +/- will
> need to be changed by one developer over the course of days
> or even weeks), but not committed all at once. The files are
> locked by the developer when we starts; the work
> proceeds by degrees, with changes committed periodically
> (files are left locked); and then finally, when the whole
> 'chunk' of work is done, the files are all unlocked. This
> may not be the use case in front of the Subversion
> development team daily, but it is out there.
>
> Here is how I envision the two options functioning in our
> typical development scenario at work. This disregards
> command-line switches or user configuration to supersede
> default operation; the concern is strictly with 'what makes
> sense for a default'.
>
>
> Option A: unlock on checkin:
> 1. Work sequence
> svn lock file1 ... file15
>
> <edit some>
> svn ci file1 file2 file3
> svn lock file1 file2 file3
> <edit some>
> svn ci file2 file4 file6 file8 file10
> svn lock file2 file4 file6 file8 file10
> <edit some>
> svn ci file3 file5 file6 file8
> svn lock file3 file5 file6 file8
> ...
> svn unlock
>
> 2. Note that 'svn ci' is never applicable, because it will
> clear the locks, necessitating another long unlock
> command. Also note that the locks are released for a
> moment after every checkin.
>
>
> Option B: no unlock on checkin
> 1. Work sequence
> svn lock file1 ... file15
>
> <edit some>
> svn ci
> <edit some>
> svn ci
> <edit some>
> svn ci [occasionally file list may be needed]
> ...
> svn unlock
>
> 2. There is a reason 'svn ci' and friends are recursive by
> default: it makes things easier for the user. Clearly,
> not auto-locking on checkin is the only way to retain
> this benefit in this use-case.
>
>
> Granted, there are use cases wherein it would be nice to
> clear all the locks upon commit. But if that doesn't happen,
> the remedy is simple: just an extra 'svn unlock'. Compare
> that to the nuisance auto-clearing of locks inflicts on the
> use case I've described above, and the choice is clear.
>
> Furthermore, the defaults in Subversion have always tended
> on the side of safety. While there is, strictly speaking, no
> safety issue here (the local working copy is not lost), the
> consequences of forgetting a '--no-unlock' switch are
> potentially more serious than those of forgetting a
> '--release-locks' switch in terms of trying to reconcile
> concurrent updates.
>
> I truly believe that Ben's original line of reasoning was,
> and continues to be, both valid and persuasive: locking and
> committing are orthogonal operations. Checking in a file
> does not imply that you want to unlock it; frequently it is
> not the case.
>
> Bruce
Thank you. You have eloquently expressed what I fumblingly was trying to
get at in part of my message much earlier on this thread.
Shawn Harrison
--
________________
harrison@tbc.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Bruce DeVisser <bm...@look.ca>.
On Tue, Dec 14, 2004 at 10:56:20PM +0000, Julian Foad wrote:
> Ben Collins-Sussman wrote:
> > On Dec 14, 2004, at 12:11 PM, Peter N. Lundblad wrote:
> >> IN any case there is the question if only the committables (the files that
> >> were actually changed) or all files specified by the targets (and possibly
> >> recursively) should be unlocked. I think the latter is the best. If you
> >> commit a subtree with some locked files, a lock shouldn't be left just
> >> becvause the file wasn't modified.
> >
> > I disagree about this. People often have multiple changesets going on
> > in their working copies. For example, I may lock foo/bar/baz.jpg
> > because I plan to edit it as part of Changeset A. Then I might switch
> > gears and change a bunch of other files in foo/bar/, as part of
> > Changeset B. Then I run 'svn commit foo/bar/' to commit Changeset B. I
> > would be really annoyed if that released my lock on baz.jpg!
>
> What? While I can see that you might find that a convenient way to work if
> 'commit' behaves the way you imply it should, I don't see that as an argument
> for 'commit' to behave that way.
>
> A contrasting scenario: Instead of "I may lock
> foo/bar/baz.jpg [for] Changeset A", let's say "I may
> _modify_ foo/bar/baz.jpg as part of Changeset A", and
> proceed as before. Then I am aware that I can't check in
> Changeset B by running 'svn commit foo/bar/'. Why would
> you find that restriction annoying in your scenario?
> Surely you would understand that a recursive command won't
> selectively ignore some of the given tree, and would
> instead use a more appropriate command?
Am I the only one that finds this unpersuasive? Isn't this
reasoning saying, 'Since it is sometimes tedious to checkin,
it should be tedious always?'
Perhaps I have a difference viewpoint because I work in an
environment where locking is enforced. Developers have
non-trivial work to do on multiple files, and typically the
scope of work is known ahead of time (eg, 15 files +/- will
need to be changed by one developer over the course of days
or even weeks), but not committed all at once. The files are
locked by the developer when we starts; the work
proceeds by degrees, with changes committed periodically
(files are left locked); and then finally, when the whole
'chunk' of work is done, the files are all unlocked. This
may not be the use case in front of the Subversion
development team daily, but it is out there.
Here is how I envision the two options functioning in our
typical development scenario at work. This disregards
command-line switches or user configuration to supersede
default operation; the concern is strictly with 'what makes
sense for a default'.
Option A: unlock on checkin:
1. Work sequence
svn lock file1 ... file15
<edit some>
svn ci file1 file2 file3
svn lock file1 file2 file3
<edit some>
svn ci file2 file4 file6 file8 file10
svn lock file2 file4 file6 file8 file10
<edit some>
svn ci file3 file5 file6 file8
svn lock file3 file5 file6 file8
...
svn unlock
2. Note that 'svn ci' is never applicable, because it will
clear the locks, necessitating another long unlock
command. Also note that the locks are released for a
moment after every checkin.
Option B: no unlock on checkin
1. Work sequence
svn lock file1 ... file15
<edit some>
svn ci
<edit some>
svn ci
<edit some>
svn ci [occasionally file list may be needed]
...
svn unlock
2. There is a reason 'svn ci' and friends are recursive by
default: it makes things easier for the user. Clearly,
not auto-locking on checkin is the only way to retain
this benefit in this use-case.
Granted, there are use cases wherein it would be nice to
clear all the locks upon commit. But if that doesn't happen,
the remedy is simple: just an extra 'svn unlock'. Compare
that to the nuisance auto-clearing of locks inflicts on the
use case I've described above, and the choice is clear.
Furthermore, the defaults in Subversion have always tended
on the side of safety. While there is, strictly speaking, no
safety issue here (the local working copy is not lost), the
consequences of forgetting a '--no-unlock' switch are
potentially more serious than those of forgetting a
'--release-locks' switch in terms of trying to reconcile
concurrent updates.
I truly believe that Ben's original line of reasoning was,
and continues to be, both valid and persuasive: locking and
committing are orthogonal operations. Checking in a file
does not imply that you want to unlock it; frequently it is
not the case.
Bruce
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Julian Foad <ju...@btopenworld.com>.
Ben Collins-Sussman wrote:
> On Dec 14, 2004, at 12:11 PM, Peter N. Lundblad wrote:
>> IN any case there is the question if only the committables (the files that
>> were actually changed) or all files specified by the targets (and possibly
>> recursively) should be unlocked. I think the latter is the best. If you
>> commit a subtree with some locked files, a lock shouldn't be left just
>> becvause the file wasn't modified.
>
> I disagree about this. People often have multiple changesets going on
> in their working copies. For example, I may lock foo/bar/baz.jpg
> because I plan to edit it as part of Changeset A. Then I might switch
> gears and change a bunch of other files in foo/bar/, as part of
> Changeset B. Then I run 'svn commit foo/bar/' to commit Changeset B. I
> would be really annoyed if that released my lock on baz.jpg!
What? While I can see that you might find that a convenient way to work if
'commit' behaves the way you imply it should, I don't see that as an argument
for 'commit' to behave that way.
A contrasting scenario: Instead of "I may lock foo/bar/baz.jpg [for] Changeset
A", let's say "I may _modify_ foo/bar/baz.jpg as part of Changeset A", and
proceed as before. Then I am aware that I can't check in Changeset B by
running 'svn commit foo/bar/'. Why would you find that restriction annoying in
your scenario? Surely you would understand that a recursive command won't
selectively ignore some of the given tree, and would instead use a more
appropriate command?
> My feeling is: 'svn commit' should only change the things it
> committed. That's how it works now, and it seems pretty simple and
> clear. If 'svn commit' started removing locks just because they're
> "nearby" things that were committed, we'd be violating the rule.
It depends on what we feel we mean by "changing" a thing, and what we mean by
"the things it committed". I know what they mean in Subversion without
locking, but we could adjust our concepts so that we don't feel that unlocking
a file is changing it, and/or so that we do feel that an item which was locked
but not changed is still logically part of the commit for the purposes of such
discussions.
There is certainly merit in your argument, but I don't think your previous
paragraph is any support for it.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Tue, 14 Dec 2004, Ben Collins-Sussman wrote:
>
> On Dec 14, 2004, at 12:11 PM, Peter N. Lundblad wrote:
> >
> > IN any case there is the question if only the committables (the files
> > that
> > were actually changed) or all files specified by the targets (and
> > possibly
> > recursively) should be unlocked. I think the latter is the best. If you
> > commit a subtree with some locked files, a lock shouldn't be left just
> > becvause the file wasn't modified.
>
> I disagree about this. People often have multiple changesets going on
> in their working copies. For example, I may lock foo/bar/baz.jpg
> because I plan to edit it as part of Changeset A. Then I might switch
> gears and change a bunch of other files in foo/bar/, as part of
This is a good point. OHO, you have the same problem if you actually
started work on baz.jpg before comitting foo/bar. But then you would see
it when editing the log message, so I guess I am convinced.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 14, 2004, at 12:11 PM, Peter N. Lundblad wrote:
>
> IN any case there is the question if only the committables (the files
> that
> were actually changed) or all files specified by the targets (and
> possibly
> recursively) should be unlocked. I think the latter is the best. If you
> commit a subtree with some locked files, a lock shouldn't be left just
> becvause the file wasn't modified.
I disagree about this. People often have multiple changesets going on
in their working copies. For example, I may lock foo/bar/baz.jpg
because I plan to edit it as part of Changeset A. Then I might switch
gears and change a bunch of other files in foo/bar/, as part of
Changeset B. Then I run 'svn commit foo/bar/' to commit Changeset B.
I would be really annoyed if that released my lock on baz.jpg!
My feeling is: 'svn commit' should only change the things it
committed. That's how it works now, and it seems pretty simple and
clear. If 'svn commit' started removing locks just because they're
"nearby" things that were committed, we'd be violating the rule.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commit and unlock
Posted by Julian Foad <ju...@btopenworld.com>.
Peter N. Lundblad wrote:
> The current locking spec says that svn commit unlocks locked files that
> are committed by default. I think this is a good default to prevent people
> from forgetting to unlock, but it seems there was no consensus, so it
> might be time for some discussion.
>
> If we have this default, there will be a --keep-lock(s|ed)? option to let
> people keep their locks. As I said, this is good. Having people often
> forget to unlock could develop a habit of stealing locks as a "normal" way
> of working. Somebody might argue that this is mxing up commands.
I think I agree with you, but it rather depends on whether the "make one
change" way of working is considerably more common than making a series of
commits while keeping the files locked.
> IN any case there is the question if only the committables (the files that
> were actually changed) or all files specified by the targets (and possibly
> recursively) should be unlocked. I think the latter is the best. If you
> commit a subtree with some locked files, a lock shouldn't be left just
> becvause the file wasn't modified.
I find this a compelling argument for considering locked-but-unmodified files
to be part of the commit. I can see this being a common use case.
In particular, I think it would be silly for a 'commit' command with explicit
targets to unlock those targets that were modified but not those that were not.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org