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
Received on Wed Feb 23 03:07:51 2005