On Wed, Jan 19, 2011 at 9:00 AM, Jan Keirse <jan.keirse_at_tvh.be> wrote:
> Ryan Schmidt <subversion-2011a_at_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
Received on 2011-01-19 09:39:40 CET