You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Brian W. Fitzpatrick" <fi...@collab.net> on 2005/02/22 21:28:37 UTC
[Locking] commits and unlock (revisited)
I'd like to revisit the decision that came out of the "commit and
unlock" discussion in December (Full thread here
http://svn.haxx.se/dev/archive-2004-12/0598.shtml).
The outcome of that thread was that 'svn commit' will unlock any file
that is specified as a target to 'svn commit' (including children of
directories).
I've read through the thread, and I can't say that I saw a clear
comparison of the pros and cons of the various options presented, so
I'd like to open up this can of worms again and do some "information
gathering and aggregation."
The three options for *default* behavior that were presented are:
a) Upon commit, unlock all locked files in TARGETS
PROS: - Helps when you forget to unlock files when you're done with
them.
CONS: - If you want to make multiple commits to a file without
releasing a lock, you need to pass --no-unlock when
committing.
b) Upon commit, unlock SOME locked files in TARGETS
PROS: - Makes it easier to divide separate commits into changesets.
CONS: - YASSC (Yet Another Subversion Special Case).
- Violates KISS.
c) Upon commit, unlock nothing
PROS: - Avoids possible conflicts in unmergeable files that are left
unlocked (although svn:needs-lock alleviates this somewhat).
- Doesn't overload commit with locking behaviors.
CONS: - You can forget that they you have files locked and prevent
others from editing those files.
Can interested parties please contribute more pros and cons to this
list? I'll summarize the discussion and post the total pros and cons
to the list.
-Fitz
PS: I'm in favor of C.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commits and unlock (revisited)
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Tue, 22 Feb 2005, C. Michael Pilato wrote:
> "Brian W. Fitzpatrick" <fi...@collab.net> writes:
>
> > a) Upon commit, unlock all locked files in TARGETS
> >
> > PROS: - Helps when you forget to unlock files when you're done with
> > them.
> >
> > CONS: - If you want to make multiple commits to a file without
> > releasing a lock, you need to pass --no-unlock when
> > committing.
> >
> > b) Upon commit, unlock SOME locked files in TARGETS
> >
> > PROS: - Makes it easier to divide separate commits into changesets.
> >
> > CONS: - YASSC (Yet Another Subversion Special Case).
> > - Violates KISS.
> >
> > c) Upon commit, unlock nothing
> >
> > PROS: - Avoids possible conflicts in unmergeable files that are left
> > unlocked (although svn:needs-lock alleviates this somewhat).
> > - Doesn't overload commit with locking behaviors.
> >
> > CONS: - You can forget that they you have files locked and prevent
> > others from editing those files.
>
...
> So:
> (a) +1
> (b) -0.9999
> (c) +0
>
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commits and unlock (revisited)
Posted by Walter Nicholls <wa...@cornerstone.co.nz>.
>> 3. Finished working and move on to something else
>
Sorry yes meant (a) (commit and unlock all)
> There's no technical difficulty, just the significant "social"
> implications of increasing the command set. Why is "svn
> commit-and-unlock" better than the proposed "svn commit --unlock",
It's not, and I don't seriously suggest a command "commit-and-unlock".
But I never type "svn commit" either, I type "svn ci". Maybe a shortcut
"cu" would work without a "long form". I don't know. Maybe if the
switch has a short form then "svn ci -U" is no problem: I aften add a
-m "message" anyway, if the log message is short enough.
> If "commit" unlocks nothing, then it is perfectly normal for there
> still to be locks. It is silly to issue warnings for perfectly normal
> situations. Perhaps you mean, or perhaps it would be reasonable to
> require that the progress output must indicate where locks are present.
>
I had in mind something like this:
C:\work\www\docs>svn ci -m "Website: updated docs"
Adding (bin) Web site design overview.odt
Sending Xaraya Configuration.odt
Transmitting file data ..
Committed revision 5.
Warning: 2 files remain locked
C:\work\www\docs>
On the Fatal/Error/Warning/Info/Debug scale this is "Info" I guess. same
effect, it is just bringing the remaining locks to my attention.
Alternatively of course
C:\work\www\docs>svn ci -m "Website: updated docs"
Some files in scope are locked, specify --unlock or --keep-locked
and try again
C:\work\www\docs>
I'd personally prefer the first option, but if there isn't clear
consensus on what the default commit behaviour should be maybe the best
thing *is* not to have a default. People with no locked files won't be
inconvenienced either way.
Of course, GUIs can do what they damn well please. Most surely display
the equivalent of svn status anyway, and I'd be surprised if they didn't
incorporate a [ ]Keep locked checkbox on at least the whole commit if
not on a per-file basis.
- Walter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commits and unlock (revisited)
Posted by Julian Foad <ju...@btopenworld.com>.
Walter Nicholls wrote:
> C. Michael Pilato wrote:
>> "Brian W. Fitzpatrick" <fi...@collab.net> writes:
>>> a) Upon commit, unlock all locked files in TARGETS
>>> c) Upon commit, unlock nothing
>
> BOTH! and I'm serious. These are two solutions to two separate use cases.
Brian was specifically asking for the "default" behaviour, but that was on the
assumption that the single command "commit" was used, whereas you are proposing
two separate commands, so that question is moot.
> 3. Finished working and move on to something else
> This is (b)
Given what you said above, I assume you mean "This is (a)" here.
> Is there a problem with EITHER
> - adding a new command (commit-and-unlock)
There's no technical difficulty, just the significant "social" implications of
increasing the command set. Why is "svn commit-and-unlock" better than the
proposed "svn commit --unlock", other than that it avoids the question of which
is the default? Is avoiding the need for a default useful? Maybe it is.
> OR forcing the user to specify if SVN COMMIT detects that locks are
> present (in scope)?
Now, that is quite a reasonable fourth option: "commit" fails if any targets
are locked and neither "--unlock" nor "--keep-locks" was given.
> The consequences of commit unlocking files I need to keep locked are far
> far worse than the consequences of commit not unlocking a file. Usually
> when I make a mistake like this, I realise it before my fingers have
> left the keyboard (but after pressing the Enter key).
OK, that's an argument in favour of (c).
> I'm in favour of :
>
> (d) Commit unlocks nothing, but warns if there are still locks in
> force. Commit --unlock unlocks everything
> Revert unlocks nothing, but warns if there are still locks in force.
> Revert --unlock unlocks everything
If "commit" unlocks nothing, then it is perfectly normal for there still to be
locks. It is silly to issue warnings for perfectly normal situations. Perhaps
you mean, or perhaps it would be reasonable to require that the progress output
must indicate where locks are present.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commits and unlock (revisited)
Posted by Walter Nicholls <wa...@cornerstone.co.nz>.
C. Michael Pilato wrote:
>"Brian W. Fitzpatrick" <fi...@collab.net> writes:
>
>
>
>> a) Upon commit, unlock all locked files in TARGETS
>>
>>
>> c) Upon commit, unlock nothing
>>
>>
BOTH! and I'm serious. These are two solutions to two separate use cases.
Here's my workflow
1. Start working - lock a few files and start modifing
2. Back up my current work to the repository, but I'm still working on it
This is (c)
3. Finished working and move on to something else
This is (b)
Is there a problem with EITHER
- adding a new command (commit-and-unlock)
OR forcing the user to specify if SVN COMMIT detects that locks are
present (in scope)?
SourceSafe (for example) offers both options. (a) is SS CHECKIN
<filelist>, (c) is SS CHECKIN <filelist> -K (not that I ever used the
sourcesafe command line).
In the interests of caution and backward compatibility I suggest the
Commit unlocks nothing, AND warns that locks still exist
I would prefer a commit-and-unlock command, but if you guys would prefer
not to add a new command (or can't think of a suitable name! I can't)
then commit --unlock would still provide the functionality in one line.
"svn cu" would be a very handy shortcut.
I already forget to SVN ADD often enough, I don't need to forget to SVN
UNLOCK either. But I don't mind retraining myself to type SVN CU
instead of SVN CI
The consequences of commit unlocking files I need to keep locked are far
far worse than the consequences of commit not unlocking a file. Usually
when I make a mistake like this, I realise it before my fingers have
left the keyboard (but after pressing the Enter key).
And I believe this discussion applies equally to SVN REVERT, however I'm
far more cautious when going near that command. Once again, there are
two use cases - I want to get back what the repository says and keep
working (SVN REVERT should unlock nothing), or I want to abandon what
I'm doing entirely (SVN REVERT --unlock). It also applies to some
extent to UPDATE.
I posted on this subject end of last year if you want more waffle/detail
from me (http://svn.haxx.se/dev/archive-2004-12/0824.shtml). It all
still seems valid to me, and it covers a lot more than just two use cases.
I don't think I have voting rights, but I'm in favour of :
(d) Commit unlocks nothing, but warns if there are still locks in
force. Commit --unlock unlocks everything
Revert unlocks nothing, but warns if there are still locks in
force. Revert --unlock unlocks everything
Thus if I have (svn status output)
M K x.c (modified and locked)
K y.c (unmodified and locked)
then...
svn commit : commits change to x.c only(svn st = K x.c, K y.c)
svn commit --unlock x.c : commits and unlocks x.c only (svn st = K y.c)
svn commit --unlock : commits x.c and unlocks x.c and y.c (svn st = )
.. and exactly the same if you s/commit/revert/g to the above.
As a separate-but-related item
(e) new command "svn cu" as a shortcut
- Walter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commits and unlock (revisited)
Posted by "C. Michael Pilato" <cm...@collab.net>.
"Brian W. Fitzpatrick" <fi...@collab.net> writes:
> a) Upon commit, unlock all locked files in TARGETS
>
> PROS: - Helps when you forget to unlock files when you're done with
> them.
>
> CONS: - If you want to make multiple commits to a file without
> releasing a lock, you need to pass --no-unlock when
> committing.
>
> b) Upon commit, unlock SOME locked files in TARGETS
>
> PROS: - Makes it easier to divide separate commits into changesets.
>
> CONS: - YASSC (Yet Another Subversion Special Case).
> - Violates KISS.
>
> c) Upon commit, unlock nothing
>
> PROS: - Avoids possible conflicts in unmergeable files that are left
> unlocked (although svn:needs-lock alleviates this somewhat).
> - Doesn't overload commit with locking behaviors.
>
> CONS: - You can forget that they you have files locked and prevent
> others from editing those files.
I find that (a) and (c) are perfect (enough) opposites, and trust that
regardless, there will be a configuration option to toggle between
those two states. (b) is just flatly insane -- whack-o behavior that
requires yet another Book paragraph to describe.
So, I could either way for (a) or (c), and will fall back to (a) as
choice because VSS (the VC system whose locking model I believe we
most want to be compatible with, if any) does things this way.
So:
(a) +1
(b) -0.9999
(c) +0
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commits and unlock (revisited)
Posted by Jack Repenning <ja...@netgate.net>.
On Feb 22, 2005, at 5:32 PM, Branko Čibej wrote:
<excerpt>Jack Repenning wrote:
<excerpt>The upshot I recall was (keyed to your alternatives):
(a) This is the "the need for lock is a property of the change" model.
Unfortunately, we can't do it well (due to lack of preexisting
always-(well-nearly)-required please-let-me-edit step). Let's sigh a
small sigh and not do this.
(b) Insanity.
(c) This is the "the need for lock is a property of the file" model.
We can do this well. It covers the most-often cited use cases (files
whose data cannot be merged, and users whose minds cannot grasp
merge). Let's do this one.
</excerpt>But but but... this is not what our idea of locking is about
at all. What we /want/ to do is to allow people to lock files to
protect against parallel changes -- exactly the "need for lock is a
property of the change" model, or ClearCase's "reserved check-out"
idiom. This is exactly what the svn:needs-lock property means. I think
it would be most confusing if the property said one thing, but the
behaviour of "svn commit" said something else.
</excerpt>I'll defer to Branko in summarizing the consensus. And I am
not advocating any position in any thing I say here, only trying to
clarify consensus (maybe not succeeding very well, a different
problem).
But I think, maybe, that Branko's fingers got ahead of his thoughts
here. Expanding his comment a bit, I think he means:
But but but ... [(c)] is not what our idea of locking is about at all.
What we /want/ to do is to allow people to lock files to protect
against parallel changes -- exactly the "need for lock is a property
of the change" model, or ClearCase's "reserved check-out" idoim [that
is, Fitz's (a)]. This [(c)] is what the svn:needs-lock property means.
But you should note that my descriptions included "unmergeable data
type" in both use cases, and hence "protect against parallel changes."
I think the data-type case straddles the line. As an example that's
in some ways clearer, I've seen message catalogs handled in locking
style, because the organization felt a need to have one message
catalog for all versions of the software. I'm talking, here, about a
catalog that maps an error number to a message, not particularly a
catalog used for translations, although they used it for that, too.
The point was, if you debug a program against version 6.3.5 and learn
that error number -1437 means "You didn't stand on your head when you
did that," then that same number has to mean that same error later,
when you port your program to version 8.9.10.11. That, first of all,
means they didn't branch the error code file even though they did
branch the code; second, it means that the documentation people need
to be involved in any changes (need to add new codes to the books,
which were actually, gasp, printed on paper before the users could
see them). And in this organization, they felt the only way to make
that all happen was to make the message file owned by a Committee that
met monthly and wrangled endlessly over new messages and their
numbers. (Personally, I don't agree that's the only, or even best,
way to do this, but they never offered to make me God. But now I've
got back at them by calling that whole mess "sheer bloody-mindedness"!
;-)
In the fitzological terminology, that's (c): they had a locking need
related to the file, not to any one change. The files themselves were
mere text, they could have been merged (or at least, any merge tool in
the land would have thought it could merge them). But the
organization had decided the files were unmergeable, and indeed that
you needed a special place in the org-chart in order to change the
file at all.
Contrast, some organizations live most of their lives without any
locking/reservations/whatever, but institute a restrictive policy as
the release nears. That makes the need for lock a property of the
change (any change happening during that time).
<excerpt>And we can have an equivalent of ClearCase's "lock" idiom,
too, at no extra cost. I think we're all forgetting that, in case (a),
"svn commit" would only unlock files _that had been locked in the same
working copy_. So if you do a "svn lock URL",
</excerpt>Oooh, you're right about me, at least: "lock the wc vs. lock
the URL" is a useful way of distinguishing the two use cases. Thanks
for the reminder!
-==-
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] commits and unlock (revisited)
Posted by Walter Nicholls <wa...@cornerstone.co.nz>.
Branko Čibej wrote:
>> (c) This is the "the need for lock is a property of the file" model.
>> We can do this well. It covers the most-often cited use cases (files
>> whose data cannot be merged, and users whose minds cannot grasp
>> merge). Let's do this one.
>
>
> But but but... this is not what our idea of locking is about at all.
> What we /want/ to do is to allow people to lock files to protect
> against parallel changes -- exactly the "need for lock is a property
> of the change" model, or ClearCase's "reserved check-out" idiom.
> This is exactly what the svn:needs-lock property means.
Huh? I though the svn:needs-lock was by definition a property of the
file. How can you set a property on a change?
I'm not sure you're disagreeing and I think I agree with both of you <g>
My overriding need is a way to indicate that a file stored in the
repository cannot be automatically merged (usually because it is binary,
eg a JPEG image) and thus users are required to lock it before they
begin editing. I may be blinded by my own situation but my impression
was that the majority of people waiting for subversion to implement
locking, were waiting because this was their need. (Ignoring the ones
who only THINK they need locking, perhaps because they don't understand
copy/merge, satisfying them is a side effect).
I haven't had the time I've wanted to spend on this subject (witness the
morbid state of sourcecross.org for evidence) but a long time ago I read
http://svn.collab.net/repos/svn/trunk/notes/locking/svn-needs-lock-impl.txt
and was quite happy that this was fulfilling exactly this goal.
Although in light of the current discussion may be this paragraph did
jump out at me:
"Commit:
- If a file has the svn:needs-lock property set and is not locked:
- Unconditionally set the file to read-only."
Obviously this test needs to be done AFTER the unlock, if commit --unlock (as opposed to commit --keep-locked)
I don't see how fulfilling Jack's (c) means it is impossible to provide
case (a). You simply lock the file and don't ever unlock it, as Brane
points out.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commits and unlock (revisited)
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On Feb 24, 2005, at 5:55 PM, Julian Foad wrote:
> Brian W. Fitzpatrick wrote:
>> OK. It seems apparent to me that the (a) crowd is in the majority
>> here. I'll stop bringing this up and go fix the bug where running
>> 'svn commit'
>> on a working copy with no local mods (but with lock tokens) currently
>> creates a revision with no changes (and unlocks all the TARGETS that
>> have lock tokens).
>
> To be clear, you will fix it so that it doesn't commit a new revision,
> but still _does_ unlock all the TARGETS that have lock tokens, yes?
> (You seemed to imply that unlocking was part of the bug.)
Sorry. Your clarification is correct--it will unlock all the TARGETS
that have lock tokens, but without creating an empty revision.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commits and unlock (revisited)
Posted by Julian Foad <ju...@btopenworld.com>.
Brian W. Fitzpatrick wrote:
> OK. It seems apparent to me that the (a) crowd is in the majority
> here.
>
> I'll stop bringing this up and go fix the bug where running 'svn commit'
> on a working copy with no local mods (but with lock tokens) currently
> creates a revision with no changes (and unlocks all the TARGETS that
> have lock tokens).
To be clear, you will fix it so that it doesn't commit a new revision, but
still _does_ unlock all the TARGETS that have lock tokens, yes? (You seemed to
imply that unlocking was part of the bug.)
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commits and unlock (revisited)
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On Wed, 2005-02-23 at 02:32 +0100, Branko Čibej wrote:
> Jack Repenning wrote:
>
> > The upshot I recall was (keyed to your alternatives):
> > (a) This is the "the need for lock is a property of the change" model.
> > Unfortunately, we can't do it well (due to lack of preexisting
> > always-(well-nearly)-required please-let-me-edit step). Let's sigh a
> > small sigh and not do this.
> > (b) Insanity.
> > (c) This is the "the need for lock is a property of the file" model.
> > We can do this well. It covers the most-often cited use cases (files
> > whose data cannot be merged, and users whose minds cannot grasp
> > merge). Let's do this one.
>
> But but but... this is not what our idea of locking is about at all.
> What we /want/ to do is to allow people to lock files to protect against
> parallel changes -- exactly the "need for lock is a property of the
> change" model, or ClearCase's "reserved check-out" idiom. This is
> exactly what the svn:needs-lock property means. I think it would be most
> confusing if the property said one thing, but the behaviour of "svn
> commit" said something else.
>
> And we can have an equivalent of ClearCase's "lock" idiom, too, at no
> extra cost. I think we're all forgetting that, in case (a), "svn commit"
> would only unlock files _that had been locked in the same working copy_.
> So if you do a "svn lock URL", the working copy knows nothing about the
> lock, and "svn commit" won't touch the lock on the file (unless it's
> been modified locally, in which case the commit will fail since the WC
> doesn't contain the lock token anyway).
OK. It seems apparent to me that the (a) crowd is in the majority
here.
I'll stop bringing this up and go fix the bug where running 'svn commit'
on a working copy with no local mods (but with lock tokens) currently
creates a revision with no changes (and unlocks all the TARGETS that
have lock tokens).
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commits and unlock (revisited)
Posted by Branko Čibej <br...@xbc.nu>.
Jack Repenning wrote:
> The upshot I recall was (keyed to your alternatives):
> (a) This is the "the need for lock is a property of the change" model.
> Unfortunately, we can't do it well (due to lack of preexisting
> always-(well-nearly)-required please-let-me-edit step). Let's sigh a
> small sigh and not do this.
> (b) Insanity.
> (c) This is the "the need for lock is a property of the file" model.
> We can do this well. It covers the most-often cited use cases (files
> whose data cannot be merged, and users whose minds cannot grasp
> merge). Let's do this one.
But but but... this is not what our idea of locking is about at all.
What we /want/ to do is to allow people to lock files to protect against
parallel changes -- exactly the "need for lock is a property of the
change" model, or ClearCase's "reserved check-out" idiom. This is
exactly what the svn:needs-lock property means. I think it would be most
confusing if the property said one thing, but the behaviour of "svn
commit" said something else.
And we can have an equivalent of ClearCase's "lock" idiom, too, at no
extra cost. I think we're all forgetting that, in case (a), "svn commit"
would only unlock files _that had been locked in the same working copy_.
So if you do a "svn lock URL", the working copy knows nothing about the
lock, and "svn commit" won't touch the lock on the file (unless it's
been modified locally, in which case the commit will fail since the WC
doesn't contain the lock token anyway).
How this interacts with lock token discovery is another question.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commits and unlock (revisited)
Posted by Julian Foad <ju...@btopenworld.com>.
Jack, the bulk of your discussion of use cases is very useful, but I think you
introduced some confusion over the phrase, "the need for a lock is a property
of the [change|file]". You are talking about a logical, conceptual property,
not meta-data. Both ways are supported by Subversion locks and
"svn:needs-lock" (which is a meta-data Property of the file).
In your conclusion:
Jack Repenning wrote:
> The upshot I recall was (keyed to your alternatives):
> (a) This is the "the need for lock is a property of the change" model.
> Unfortunately, we can't do it well (due to lack of preexisting
> always-(well-nearly)-required please-let-me-edit step). Let's sigh a
> small sigh and not do this.
Let's not do what, exactly?
We can cater for lock-during-change well enough, using "svn:needs-lock" to help
users notice that a lock is needed and "svn lock" to reserve a file and some
form of "svn commit" (possibly with "svn unlock") to finish with it. OK, it's
not as neat as in systems that inherently work like this, but it's not too bad
given that it has to fit in to Subversion's flexible development model.
> (b) Insanity.
That conclusion is based on lack of information - not your fault. In fact (b)
- unlocking only the files that have changed - is a reasonable alternative to
(a), but I believe the consensus is that it is inferior to (a).
> (c) This is the "the need for lock is a property of the file" model. We
... by which you mean a long-term lock, not just existing while a change is
made. Certainly option (c) - "commit" never unlocks (by default) - fits this
case well.
> can do this well. It covers the most-often cited use cases (files whose
> data cannot be merged, and users whose minds cannot grasp merge). Let's
> do this one.
It does cover those cases, but (a) covers them with fewer steps or options to
remember.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commits and unlock (revisited)
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Feb 22, 2005, at 6:20 PM, Jack Repenning wrote:
> 22, 2005, at 1:28 PM, Brian W. Fitzpatrick wrote:
...
>> b) Upon commit, unlock SOME locked files in TARGETS
>> PROS: - Makes it easier to divide separate commits into changesets.
>> CONS: - YASSC (Yet Another Subversion Special Case).
>> - Violates KISS.
> I do not recall this case being discussed. I ask, in some horror,
> "unlock *which* files????" My thought, in so asking, is not that
> anyone has a good answer to the question, but rather that in
> considering the question, everyone will realize what a truly monstrous
> idea this really is ;-)
Sorry...I should have been clearer--only *modified* files are unlocked
in case b).
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commits and unlock (revisited)
Posted by Jack Repenning <ja...@netgate.net>.
22, 2005, at 1:28 PM, Brian W. Fitzpatrick wrote:
<excerpt>I'd like to revisit the decision that came out of the "commit
and
unlock" discussion in December (Full thread here
http://svn.haxx.se/dev/archive-2004-12/0598.shtml).
The outcome of that thread was that 'svn commit' will unlock any file
that is specified as a target to 'svn commit' (including children of
directories).
</excerpt>What I think is apparent there, and not obvious in this
message, is that there are two completely different use cases tromping
around wearing the same name "lock." We are proposing to implement
only one of the two use cases, but that don't mean there ain't another
'un out there, somewhere.
Use case one has it that someone is making changes, or is just about
to make changes, to a file that ought not to be changed in parallel.
Never mind why that is, could range from "unmergeable data type" to
"company policy" to "sheer bloody-mindedness"; not important to us
here. The point is, the lock idea is attached to the intent-to-change.
Use case two has it that there's some file that shouldn't be changed
at all, or only by decree from God as interpreted by His Only Prophet
(say, me). Again, never mind why this is so, could range from
"there's some external contract related to this file's contents" to
"unmergeable data type" to "company policy" to "sheer
bloody-mindedness." The point is, the lock idea is attached to the
file itself.
In ClearCase (FWIW), these are, respectively, the "reserved checkout"
and the "lock." They're separate commands, and their effects are
different in just the sort of way Fitz raises here. The "reserved
checkout" (which may arise either as a side effect of the checkout
proper, or at any time after the checkout through a separate command,
"reserve") is automatically removed at checkin time (and can be
removed asynchronously with the "unreserve" command). The "lock" can
only be placed by the "lock" command, and can only be removed by the
"unlock" command. Either has the effect of preventing anyone else
from checking out the file. (Quibble 1: "check out" in ClearCase
doesn't mean what it does in CVS or Subversion (that's "update", just
like what we call "update"); rather, "check out" is an always (well,
nearly so) required step before making any changes. Quibble 2: other
people may still check out and modify the file if they create a
separate branch to work on, and indeed in some deep-voodoo sense, it's
really the branch tip that's "reserved," not the file or version
itself.)
I know that VSS provides "case one" behavior by default (indeed, I
think you have no choice about that); I dunno about case two.
CVS ... well, CVS does some rather different things, involving things
like email notification or extra commands just to check if someone
might actually have a lock set ... no doubt, in the spirit of that
great "C", concurrency, a spirit which we around here in some degree
applaud, but an implementation which, on the whole, we chose not to
imitate slavishly.
So in fact, what Fitz is raising is the question (in ClearCase
phraseology) "reserved checkouts, or locks?"
And I claim that that was, indeed, talked to screaming DEATH before,
and if the outcome wasn't clear, that was only because people had such
a hard time remembering that there are two different things here, and
we're only proposing (at least, for the moment) to implement one of
them. Oh, and also: because the one we most want, we can't do very
well, because there isn't any such "always (well, nearly so) required
step" as there is in ClearCase and VSS, so we're actually doing one
that feels kind off second-best.
<excerpt>I've read through the thread, and I can't say that I saw a
clear
comparison of the pros and cons of the various options presented, so
I'd like to open up this can of worms again and do some "information
gathering and aggregation."
The three options for *default* behavior that were presented are:
a) Upon commit, unlock all locked files in TARGETS
PROS: - Helps when you forget to unlock files when you're done with
them.
CONS: - If you want to make multiple commits to a file without
releasing a lock, you need to pass --no-unlock when
committing.
</excerpt>This is not about "helping." This is about "what is it
we're doing?" Model (a) removes the lock at commit because it should,
because (so says this model) the lock is a property of the
intent-to-change, and the change is completed with the commit.
Alternatives like "--no-unlock" are provided because models are always
more pure than reality, but they're options, not main-line behavior,
because they violate the model. The idea is, people should learn
subconsciously that "locks have to do with intent to change," and only
go hunting for a rule-breaker when they have a rule-breaking need.
<excerpt> b) Upon commit, unlock SOME locked files in TARGETS
PROS: - Makes it easier to divide separate commits into changesets.
CONS: - YASSC (Yet Another Subversion Special Case).
- Violates KISS.
</excerpt>I do not recall this case being discussed. I ask, in some
horror, "unlock *which* files????" My thought, in so asking, is not
that anyone has a good answer to the question, but rather that in
considering the question, everyone will realize what a truly monstrous
idea this really is ;-)
<excerpt> c) Upon commit, unlock nothing
PROS: - Avoids possible conflicts in unmergeable files that are left
unlocked (although svn:needs-lock alleviates this somewhat).
- Doesn't overload commit with locking behaviors.
CONS: - You can forget that they you have files locked and prevent
others from editing those files.
</excerpt>Ah, yes, the other model: there's something persistent about
the file that means it should always be locked. This is a simpler
model to understand than the first, and simpler to implement.
<excerpt>Can interested parties please contribute more pros and cons
to this
list? I'll summarize the discussion and post the total pros and cons
to the list.
</excerpt>The upshot I recall was (keyed to your alternatives):
(a) This is the "the need for lock is a property of the change" model.
Unfortunately, we can't do it well (due to lack of preexisting
always-(well-nearly)-required please-let-me-edit step). Let's sigh a
small sigh and not do this.
(b) Insanity.
(c) This is the "the need for lock is a property of the file" model.
We can do this well. It covers the most-often cited use cases (files
whose data cannot be merged, and users whose minds cannot grasp
merge). Let's do this one.
-==-
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] commits and unlock (revisited)
Posted by Branko Čibej <br...@xbc.nu>.
Brian W. Fitzpatrick wrote:
>I'd like to revisit the decision that came out of the "commit and
>unlock" discussion in December (Full thread here
>http://svn.haxx.se/dev/archive-2004-12/0598.shtml).
>
>The outcome of that thread was that 'svn commit' will unlock any file
>that is specified as a target to 'svn commit' (including children of
>directories).
>
>I've read through the thread, and I can't say that I saw a clear
>comparison of the pros and cons of the various options presented, so
>I'd like to open up this can of worms again and do some "information
>gathering and aggregation."
>
>The three options for *default* behavior that were presented are:
>
> a) Upon commit, unlock all locked files in TARGETS
>
> PROS: - Helps when you forget to unlock files when you're done with
> them.
>
>
- Every other VC system I know does this by defauls.
> CONS: - If you want to make multiple commits to a file without
> releasing a lock, you need to pass --no-unlock when
> committing.
>
> b) Upon commit, unlock SOME locked files in TARGETS
>
> PROS: - Makes it easier to divide separate commits into changesets.
>
> CONS: - YASSC (Yet Another Subversion Special Case).
> - Violates KISS.
>
> c) Upon commit, unlock nothing
>
> PROS: - Avoids possible conflicts in unmergeable files that are left
> unlocked (although svn:needs-lock alleviates this somewhat).
> - Doesn't overload commit with locking behaviors.
>
> CONS: - You can forget that they you have files locked and prevent
> others from editing those files.
>
>
- YASSC obtains here, too.
>Can interested parties please contribute more pros and cons to this
>list? I'll summarize the discussion and post the total pros and cons
>to the list.
>
>-Fitz
>
>PS: I'm in favor of C.
>
>
I can't imagine why. The user has _already_ taken the time to list all
the targets, and has either completed a change (which means that
atomically unlocking the files is the Thing To Do), or is making a
checkpoint commit, in which case she says --no-unlock. Of course a)
assumes that if the commit fails, locks aren't affected.
I think forgetting to unlock after a commit is a huge enough problem to
make c) lose in any comparison with a) unless we find some very, very
compelling reason why a) whould be undesirable.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Locking] commits and unlock (revisited)
Posted by Julian Foad <ju...@btopenworld.com>.
Brian W. Fitzpatrick wrote:
> The three options for *default* behavior that were presented are:
>
> a) Upon commit, unlock all locked files in TARGETS
>
> PROS: - Helps when you forget to unlock files when you're done with
> them.
Or rather, "Helps to avoid you forgetting ..."
Also: - Simplifies working with locked files if you rarely need to
make multiple commits without releasing a lock.
> CONS: - If you want to make multiple commits to a file without
> releasing a lock, you need to pass --no-unlock when
> committing.
>
> b) Upon commit, unlock SOME locked files in TARGETS
Not just 'some' locked files at random, but precisely those TARGETS that
(because they are modified) actually get committed.
> PROS: - Makes it easier to divide separate commits into changesets.
>
> CONS: - YASSC (Yet Another Subversion Special Case).
> - Violates KISS.
Also: - If you want to make multiple commits to a file without
releasing a lock, you need to pass --no-unlock when
committing.
>
> c) Upon commit, unlock nothing
>
> PROS: - Avoids possible conflicts in unmergeable files that are left
> unlocked (although svn:needs-lock alleviates this somewhat).
I don't understand that point. Please elaborate.
> - Doesn't overload commit with locking behaviors.
>
> CONS: - You can forget that they you have files locked and prevent
> others from editing those files.
Also: - If you want to unlock a file when you commit it, you need
to pass --unlock when committing, or use a separate command.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org