On Jan 18, 2011, at 08:15, Jan Keirse wrote: > we would like to be able to always know who else is working on a file, so > that we can communicate with each other and avoid complex merges. > Case 1: If 2 or 3 users have to change the same file but one user has to > make his changes in the top of the file, someone else is making changes to > the bottom of the file and a third person is changing the middle of the > file, there's no problem, we can all work at the same time, merging the > changes is trivial. > Case 2: If 2 users have to change the same section of a file it would be > better if one waits for the other, because it may be hard or impossible to > merge the changes. > > To simplify this we would like to implement some sort of 'concurrent > locking': If a user wants to change a file he has to first take a lock on > the file, and if others also have a lock he is informed about that (so he > can have a chat and see if this is case 1 (and he can continue) or case 2 > (and he should wait for the first change to be completed.)) > > As I understand it right now, locking in subversion is 'exclusive', if > user 1 has a lock, and user 2 also wants to lock, he has to steal the > lock, but when user 2 commits the changes the repository will not know > someone else (user 1) is still working on the file, so if a third user > takes a lock he will not be informed that user 1 is also working on the > file. > Could this be solved with repository hooks or will I have to implement my > own 'locking' mechanism? Or would this be considered a usefull feature > request? What I want is basically the equivalent of the cvs edit and > editors commands.
I don't think Subversion's locking mechanism is something that can be modified in the way you suggest (not without rewriting a lot of the Subversion source code). I also don't think you need a locking mechanism at all. Just don't lock anything. Let people work concurrently. Yes, sometimes you may need to resolve conflicts. Hopefully it won't be too difficult to do so. I suggest you just try this way of working and see what you think. I think there will be fewer conflicts than you anticipate.
