Malcolm Rowe writes:
> > But I definitely need to spend some more time thinking about the problem
> > before diving in. And while doing so, I'll sing a song about how
> > beautiful subsystem-provided transactions and atomicity are.
> >
That's why I am asking about format changes;)
>
> Locking in FSFS is currently done under the FS-wide write-lock, so
> making it able to lock multiple locks at once should be easy (see
> libsvn_fs_fs/lock.c:lock_body()/unlock_body(). I imagine that switching
> those to take an array of the batons they currently get would work).
> Unless I misunderstand, no format changes should be required.
>
Currently, the write lock is typically held for short periods of time.
My concern is that this approach will block other operations (commits and
locks) for long times if people lock lots of files at once.
Maybe it is an acceptable tradeoff...
> That admittedly doesn't give us a complete ACID solution - we're missing
> isolation, because the locks are visible immediately they're created.
> But that wasn't a goal, was it? (you're just implementing an atomic
> lock-many, aren't you?).
And obviously it can leave the repository in an inconsistent state on error,
but we already have this problem. Maybe svnadmin recover needs to start doing
something for fsfs?
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 23 10:07:40 2007