Johan Corveleyn <jcorvel_at_gmail.com> schreef op 19/01/2011 09:38:41:
> 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:
> >>
> >> 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."
Received on 2011-01-19 10:31:43 CET