Ryan Schmidt <subversion-20...@ryandesign.com> schreef op 18/01/2011 22:34:24:
> 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. I'm afraid we started using the scheme above in CVS because there were problems. The UI designer we use is so kind to randomly rearange it's UI creation code every time you change the UI (move a button change a label, add something and it looks as if you made a hundred changes). As long as you only change logic there's no problem, but as soon as you change something to the UI design there are a random amount of changes that don't make any sense at all, merging them is next to impossible and trying usually results in corupt files. Kind Regards, JAN KEIRSE ICT-DEPARTMENT Software quality & Systems: Software Engineer **** DISCLAIMER **** http://www.tvh.com/newen2/emaildisclaimer/default.html "This message is delivered to all addressees subject to the conditions set forth in the attached disclaimer, which is an integral part of this message."
