You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jan Keirse <ja...@tvh.be> on 2011/01/19 09:00:47 UTC
Betr.: Re: multiple locks on a single file
Ryan Schmidt <su...@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."
Re: multiple locks on a single file
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jan 19, 2011, at 03:32, Jan Keirse wrote:
> I'm not asking for a lock on part of the file, in fact if you think about
> it I'm not asking a real lock, i'm only asking a notification, informing
> the developer who else is working on the file.
[snip]
> I'm not asking to automatically stop the user from
> changing anything, I just would like them to be notified someone else is
> working on the file so that they can talk to the other people to make sure
> they are only working on logic and not design.
Note that Subversion does have pre-lock and post-lock hooks that you can write scripts for. Note also that Subversion locks can, by default, be stolen by anyone. Combining these facts, you could write a post-lock hook that informs your team that someone has locked this file. (This information could be sent by any convenient means -- for example, by sending an email to a mailing list to which all team members are subscribed.) Anyone who feels they still need to work on the file after it has been locked by someone can steal the lock for themselves.
Betr.: Re: Betr.: Re: multiple locks on a single file
Posted by Jan Keirse <ja...@tvh.be>.
Johan Corveleyn <jc...@gmail.com> schreef op 19/01/2011 09:38:41:
> On Wed, Jan 19, 2011 at 9:00 AM, Jan Keirse <ja...@tvh.be> wrote:
> > Ryan Schmidt <su...@ryandesign.com> schreef op 18/01/2011
> > 22:34:24:
> >
> >> On Jan 18, 2011, at 08:15, Jan Keirse wrote:
> >>
> >> 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?
I'm not asking for a lock on part of the file, in fact if you think about
it I'm not asking a real lock, i'm only asking a notification, informing
the developer who else is working on the file.
One file contains both automatically generated UI description (based on
what you designed in a wysiwyg designer) and UI logic (which you coded in
a 'section editor'). If you change the UI logic (for example code that
changes the color of a field based on some data) there will be no random
changes in the file. I'm not asking to automatically stop the user from
changing anything, I just would like them to be notified someone else is
working on the file so that they can talk to the other people to make sure
they are only working on logic and not design.
I could easily write a tool myself, it's a trivial thing:
Create a table with
- username
- filename
- some unique id that can be passed during commit (so I know from
what working copy the commit came from to know what edit to remove)
- maybe optional informative fields like hostname and date/time of
creation of the 'edit'
Create a tool
svnedit somefilename that stores a record in the above table and returns a
list of all records for that filename.
Create a commithook that deletes the specific record for this file after
commit.
However I think this would be better integrated within subversion
(creating an svn edit somefile command) because it would allow to check
out the files read-only (svn edit would then make them read/write just
like svn lock does, only it would not take an exclusive lock.)
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."
Re: Betr.: Re: multiple locks on a single file
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Jan 19, 2011 at 9:00 AM, Jan Keirse <ja...@tvh.be> wrote:
> Ryan Schmidt <su...@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