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.
<thinkingaloud>
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
time.
Oops. Need to stop thinking aloud.
</thinkingaloud>
---------------------------------------------------------------------
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