> 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
believe.
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
email.
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