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.
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."
Received on 2011-01-19 09:00:06 CET