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.
Received on 2011-01-18 22:35:09 CET