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

RE: Comments on the book

From: <andy.glew_at_amd.com>
Date: 2004-06-03 19:08:37 CEST

> Granted, SCM models aren't my area of expertise. But I'd love to hear
> someone argue a strong case for lock-modify-unlock. I'd love
> to hear a
> one-sided argument for the other side. :-)

I can only give a half-hearted argument for locking.

I *have* had bugs due to CVS merging, that locking would have
prevented. And I have had, on more than one occcasion, to spend
a day or so fixing up such messes.

(But then again, I have also had bugs with locking,
where file1 was locked, but file2, which used a feature of file1
that was being changed, was not locked and got changed
in an incompatible direction.)

The best that I can say about locking is that it does not
need to be as heavyweight as most non-locking merge advocates

E.g. I have typically used locking in an advisory manner.
When I start editing, I might get told "Debbie has this file
locked." At which point I know to go and talk to Debbie,
and/or I can just break her lock, automatically sending her

This sort of locking is basically just a crutch for
communications. Brian Berliner said in his CVS docs,
something like "CVS is not a substitute for communications".
But I started doing version control at the Little Software
House on the Prairie after Brian left: in Brian's time,
it was maybe 30 people, but when I was there it was
maybe 200+ people in Illinois, with more people at other
sites. As project size increases - or, more accurately,
as more projects start sharing more stuff - anything
that helps communications is good.

I.e. I don't believe in lock-modify-unlock, with locks
held for a long time, delaying progress. I believe in
optimistic concurrency control.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 3 19:11:48 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.