[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.]
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.]
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.
- 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?
- Can a user break or override another user's lock, or can only the administrator do that?
Implementation:
- Done :-)
- Is it acceptable for "check out; undo check-out" to have modified the repository?
- ...
> 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.
> 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 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 26 18:25:28 2003