Julian Foad wrote:
> [I modified the Subject because there has been lots of discussion about
> locking w.r.t. Berkely DB and filesystem access, so I didn't know that
> this referred to locking at the user-interface level.]
Good idea. Perhaps the property should be called svn:reserved or
something...there is already enough locking terminology in svn.
>
> D.J. Heap wrote:
>
>> Here's a little patch to implement the core of kfogel's remarks in Issue
>> 533 on locking. Basically it just stops the commit if a node has
>> the svn:locked property set to a username other than the committer's.
>>
>> I realize this is a semi-religious (and post 1.0) issue, but it has
>> become a sticking point at our shop and with this bit I can make them
>> happy.
>
>
> Ah ha! I'm glad you are working on that. I think it is an essential
> feature for many people when dealing with non-mergeable files.
>
> Issue 533 discusses some ideas. The required functionality is not
> defined. Please could we start with a description of what we want to
> achieve at the user level. Then you could say what your patch achieves
> (as a log message, ideally) and we could see how that fits the
> requirement. I'll make a start below. I know most of the ideas look
> familiar, but lots of it is not yet agreed. We should try to consider
> all reasonable use cases, while aiming for a simple initial design which
> will not satisfy all of them.
>
>
> What this is about:
> - If two users edit a file at "the same time", generally both changes
> are wanted so the changes need to be combined. Subversion generally
> assumes text files and automatically merges the most common types of
> change. In any other case, the options are for the user to merge the
> changes manually, or for the users to avoid making simultaneous changes
> in the first place. A "reserved check-out" is a means by which the
> system can help the users to avoid making simultaneous changes.
>
> Why it is needed:
> - File type cannot be automatically merged (i.e. most file types).
> - Don't want to use automatic merge (because it can do the wrong thing).
> - Want to enforce a discipline in which users are not supposed to work
> on overlapping tasks. [I don't think this is a valid reason.]
The first two points are what we (not really me, actually, but some
coworkers/superiors) are concerned about.
>
> High-level requirements:
> - Prevent a commit from accidentally reverting the effect of someone
> else's previous commit. [The existing "svn commit" already achieves
> this by requiring that the WC file is based on the latest repository
> revision.]
> - Prevent a user from editing a file that someone else is editing,
> because then one or both of them would have to re-do their work or merge
> the changes manually.
> - Provide an easy way for a user to aquire a lock before editing a file,
> and to release it on committing.
> - Provide a way for an administrator and/or a user to designate which
> parts of the repository are subject to reserved check-outs.
>
> Detailed requirements / functional design:
> - Certain files and/or sub-trees need to be designated "reserved
> check-outs only".
> - Pick the granularity at which the "reserved check-outs" functionality
> can be enabled: whole repository, or specified sub-trees, or specified
> sub-trees and individual files.
> - Which of these modes is/are supported when reserved check-outs are
> enabled on sub-tree X?
> - Files in sub-tree X can be independently reserved by different users.
Since the patch is property based, it works on individual files and/or
folders and can be set recursively if desired. Here, we really only
care about a very small number of individual files, so this will work
well for us, I think.
> - A reservation can only be made on the whole sub-tree X.
> - How will the user "lock" the repository copy (or "unlock" his working
> copy) before editing a file?
A node is locked by setting the svn:locked property to the user's name.
There's no quick command to do this at the moment (and retrieving
the username at the client side automatically is not as easy as I had
initially thought) -- just 'svn pset svn:locked myusername file'.
> - Can a user break or override another user's lock, or can only the
> administrator do that?
Any committer can -- we would dislike having only admins able to do it
as that has caused us a number of headaches in Visual SourceSafe
already. If a user overrides/removes someone else's lock, it would be
recorded in the revision logs and could be dealt with appropriately --
it may be nice to warn them or something before they do, though.
>
> Implementation:
> - Done :-)
> - Is it acceptable for "check out; undo check-out" to have modified the
> repository?
That is a good point I hadn't thought of...for us it will be fine.
Others may disagree, though.
> - ...
>
>
>> Another detail I wasn't really clear on from the remarks was whether or
>> not it was desirable to make a locked file read-only for other users --
>
>
> To my mind, doing that is very important.
I suspect it will be desired here, also, even though I was hoping to get
away without it. The patch does not do so right now. (I would imagine
that implementing this means having the property set to an empty string
for reservation required, so everyone should have read-only copies
unless it is reserved by them -- that would take some work in libsvn_wc,
I think, perhaps elsewhere as well).
>
>> Basically following the issue comments, locking the file means setting a
>> 'svn:locked' property to the user's name -- only that user can commit
>> the file now,
>
>
>> although it is easy to remove the property, of course. That is a
>> feature IMO, since it is more about notification than any real security,
>
>
> Probably, in most cases. I've added this to the "requirements/design"
> section.
>
>> Is this the right idea and desired or not even close?
>
>
> It's a start :-) Even if you don't have time to go deeply into this, I
> would be interested to see how your shop's requirements fit into these
> ideas.
I think you have outlined very well what is desired from our perspective.
>
>
> I hope we can grow these notes into a proper design document and come to
> a fairly minimal but clean and useful design for a "first pass".
>
> - Julian
If it is deemed acceptable, then I am willing to spend some time to
finish it up.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 26 19:56:21 2003