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

Re: on-the-fly lock checking

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-12-05 19:23:24 CET

Ben Collins-Sussman wrote:

> On Dec 3, 2004, at 6:48 PM, Branko Čibej wrote:
>>> I suppose we can do much of this right now. Ben can rev create_txn(),
>>> adding two parameters (one for on-the-fly lock checking, one for
>>> out-of-dateness). We can implement the on-the-fly lock checking in
>>> the FS. We can document that we don't do OOD checks yet, and return
>>> FEATURE_NOT_IMPLEMENTED if that boolean is TRUE.
>>> svn_repos_begin_txn_for_commit/update() can pass FALSE for OOD
>>> checking parameter (now and forever), and we can start deprecating
>>> functions.
>> One bitmap parameter would suffice, I think; we may have other kinds
>> of checks later on, and this way we don't have to rev create_txn
>> every time. Otherwise, +1. This will give us a much cleaner API in
>> the long run.
> So I've added a 'flags' parameter to svn_fs_begin_txn2().
> But guess what? This new variable needs to be attached to the
> transaction. Remember that fs users can constantly open/close the
> transaction (like mod_dav_svn, for example). But that means changing
> the definition of a txn_t... which means a db schema change. Ick!

Hmmm, yes, good point.

> cmpilato and I were thinking that perhaps svn_fs_begin_txn2() can save
> the 'flags' value as a temporary svn: revprop. and then
> svn_fs_commit_txn() can quietly remove it.

I don't see anything fundamentally wrong with that. I would use a
revprop name that can't be set from the client, though (i.e., that
doesn't pass our prop name validation). We want to be careful that a
client can't change that revprop's value.

-- Brane

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 5 19:24:13 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.