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

Re: Locking design (was Re: svn commit: r9885 - trunk/notes)

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2004-05-27 02:36:44 CEST

Branko Čibej <brane@xbc.nu> writes:

> >So, before we go wild with directory locks and depth indicators,
> > remember that locks don't interact well with our operational
> > model. We're going to run into corner cases like: I lock a file in a
> > working
> >directory, make a copy of it, and then unlock it in one of the working
> >copies; the other one erroneously believes it holds a lock.
> >
> That's no worse than breaking the lock any other way.


While I was kinda anti-directory-lock, I fear that by *not*
implementing directory locks, we're going to open up a larger can of
worms (from a performance and elegance standpoint). As soon as
UserOfLargeBinaryfulRepos realizes he can't lock his massive tree of
digital video resources, he'll do something worse -- recursively lock
each resource in that tree. Now instead of adding a single
locks-table item, there's a thousand. Though I suspect it will be
painful to get right, wussing out on directory locking almost feels
like a violation of our foremost win over CVS -- that we do directory
version control quite well thankyouverymuch.

But then again ... implementing depth-infinity directory locks means
that to implement "lock dir; unlock dir/subdir", we'll either need
some way to indicate lock exceptions (a negation token of sorts) or
we'll end up exploding the locks into per-resource locks table rows
anyway, in which case directory locking is again useless.

Dinner was pretty good tonight, despite having to eat it while on a
conference call. I think I'll surprise Amy by washing up the
remaining dishes. Gavin, it's sleepytime, son, not vocal-strength-test

Oops. Need to stop thinking aloud.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 27 02:37:18 2004

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

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