On Wed, Jan 19, 2011 at 9:00 AM, Jan Keirse <jan.kei...@tvh.be> wrote: > 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.
Well, wouldn't the only safe way then be that people lock the entire file (like it is supported in SVN)? If locking only part of a file, and the UI designer rearranges everything so you interfere with parts outside of you locked area, that will be a problem. Or can the user predict what part of a file is going to be touched when he does particular changes in the UI designer? Regardless, as Ryan said, locking only part of a file is not possible in SVN, and I think it would require a lot of changes to add such a feature. Maybe you can start educating your users to use only per-file locks, and where this gives too many problems/conflicts, try to refactor and split up the files? Cheers, -- Johan
