Mark Phippard wrote:
>"Stefan Gmx" <Stefan_DD@gmx.net> wrote on 08/11/2004 08:04:15 AM:
>
>
>
>>Hello,
>>
>>Is there a way to lock an object exclussively?
>>
>>I ask, because we want to control binary files (Oracle Forms Modules) ….
>>
>>
>and
>
>
>>merging different file versions of this type does not make any sense.
>>
>>Thanks for your answer.
>>
>>
>
>Not currently. The feature is tentatively planned for release 1.2.
>
>It has been discussed a lot in the past, so you might want to search the
>list archives for "locking" to see some of the workarounds that have been
>proposed.
>
>Also, a few weeks ago someone posted an implementation that uses hook
>scripts and some custom patches to svn to implement it with the current
>release.
>
>http://www.contactor.se/~dast/svn/archive-2004-07/1351.shtml
>
>Mark
>
>
>
I have the exact same situation in an Oracle development shop.
I think you need to look at the situation differently.....
The mindset here WAS based on the locking model using PVCS.
Developers 'checked out' a file, changed it then checked it back in
releasing the lock. The coordination of changes
was forced when a developer was unable to check out a file due to locks.
That is unless the boneheads found an old copy,
changed it and then "followed the rules" and waited to 'Check out' the
form 'til the first guy was done then promptly checked in
the "working copy" they had previously changed.
Some people just don't get it!!!!
That Lock, check-out, check-in, unlock logic doesn't quite mesh with
the subversion way of thinking.
What is the proposed methodology for 'locking' in version 1.2?
A. The PVCS approach which will simply not allow you to get files from
the repository which are locked?
This will result in useless working copies full of holes and unusable as
a 'Set'.
This would also require the clients to delete any pre-existing files in
the working directory to enforce the logic. ?.
B. Refuse to allow you to 'check-in' changes to a locked file?
This is really no different than the current situation if subversion
knows the file is binary or can't be merged. you
already did all the work of making a change and only then find out you
changed an old copy and it's worthless.
C. The only usable approach I can imagine to give you notice up front is
to have the subversion clients make the files
'read-only' at the filesystem level if they are 'locked'.
Ultimately there needs to be communication between developers as to the
changes they are working on and how it
will impact other developers and the system as a whole.
For example Joe just added a script that modifies some items in the
database schema. Mike is currently modifying Form XYZ.
Joe thinks he is safe because HIS script is new code, Mike thinks he is
safe because XYZ is 'locked'. The fact is Mikes form is now
garbage and must be changed or at the very least recompiled, and 'locks'
will never prevent that.
The same issues apply to automagically merged code but are harder to
resolve IMHO.
Joe Changed HelloWorld.c and so did Mike, Subversion merged the changes
without a complaint, but the 'Logic' of the 2 changes
or the combination of the 2 cause something to break. Now what?
COMMUNICATION.
Locking can become a crutch and allow users the false sense of security
and encourage development in a vacuum.
Not having locking per-se has forced us to communicate better. Making
sure subversion knows some file types can't be merged
gives developers a swift kick in the butt when they don't communicate
and end up with a conflict and that have to redo a bunch of work on
more current source files.
Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 11 16:30:33 2004