Re: Subversion 101: To lock or not to lock..

> Ok.. I printed out all the excellent comments from all of you and had
> meeting with the 'pro-locking' factions here at the ranch.
>
> A lot of the issues of why people want locking is because of a general
> lack of training and knowledge of how and why Subversion works. As the
> SCM this is my fault and its up to me to fix those issues.
Sounds to me like you're hitting a lot of 'developer inertia.'

We are in the midst of a similar switch from VSS to SVN and I'm hitting the
same pushback. Luckily here the developers are a bit more open to the idea
of letting SVN handle merging.

> "When editing an html or jsp file, it is often necessary to modify
> many parts of the file. If someone else is also editing the same
> file, merging the changes can be extremely time consuming, as it is
> hard for subversion to reconcile and display the diffs correctly (this
> is from experience). Locking provides a safeguard from having to
> endure the merge process but does not stop people from getting their
> job done, because you should never have two people working on the same
> html/jsp file at the same time."
XML/HTML/et al are a bit more of a special case actually. Especially if
it's machine generated. We've had some issues with .NET projects and
auto-generated XML files. The problem is that the XML elements aren't
necessarilly always re-generated in the same order, and thus the 'diff'
utility doesn't help very much - too much has moved.

But for hand-edited files this shouldn't be a problem, unless you have
people moving lots of tags for no apparent reason.

Personally, I'm a much bigger fan of a carful 'merge' than I am of waiting
for Fred to unlock a file so I can edit and test some changes...

The only thing we use locking for is binary files.

-- 
// Andrew MacKenzie  |  http://www.edespot.com
// GPG public key: http://www.edespot.com/~amackenz/public.key
// "Money is flat and was meant to be piled up."
//     -- Scottish Proverb
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org