[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Bluesky: Fine Grain Locking

From: <andy.glew_at_amd.com>
Date: 2004-06-01 21:35:05 CEST

> I had always worked in the "locks" world and thought it was better than
> the CVS model. I have been doing a lot of J2EE development lately and it
> would be virtually impossible to do in a locking version control system as
> there are so many XML files that EVERYONE has to be able to edit and
> modify to do any work. If the file was always locked no one could ever do
> anything.
> Mark

This causes me to wonder about updating
what is now a long-forgotten Version Control

CVS, SVN, etc. are file based - they lock at file
granularity. Using merging instead of locking
allows non-conflicting edits to different parts
of the same file. (Unfortunately, it occasionally
also allows conflicting edits - but even file
based locking doesn't solve that.)

I've occasionally heard people talk about VC
systems based on the "deck of cards" paradigm
- where you locked several particular regions,
basically line numbers, typically scaled up
to procedures, etc., of the source.

There are many problems with this approach
to fine grain locking, including:
   * it's a pain to specify ranges of line
     numbers (aka cards). You always need
     to round up to granularities such as
     procedures (with/without argument lists), etc.
   * tracking changing line numbers ...
     basically, this is what the diff / merge
     tools do.
   * UNIX doesn't allow inserts into the middle
     of a file - even if you are on one on the UNIXes
     that allow byte regions of a file to be locked,
     typically somebody will want to insert
     lines before than position.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jun 1 21:37:11 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.