I began a rebuttal. Then I actually applied thought. Added a pinch
of sanity check from Ben Collins-Sussman. And the response is that
there is no rebuttal to be had.
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.
Branko ÄŒibej <brane@xbc.nu> writes:
> The FS wrappers today are doing two things:
>
> * running hooks
> * checking out-of-datendess
>
> We obviously don't need wrappers for running hooks; as I told Ben the
> other day on IRC, a set of callbacks would serve much better (/and/
> we'd be able to finally implement read hooks).
>
> The out-of datedness check is obviously a performance optimisation,
> and any way I look at it, it doetn's belong in libsvn_repos. I mean,
> it's a bit funny to have libsvn_repos do some of the out-of-date
> checks, and libsvn_fs do others. The argument that a user can use a fs
> txn as a scratch area, so the fs shouldn't do out-of-date checks until
> commit...well, it holds water up to a point (even though IIRC there
> are not /right now/ any such applications). Now, I think you'll agree
> that it makes no sense to theck out-of-detedness for some FS
> operations but not others /within a single txn/. So the decision
> whether the checks should be performed always or just at commit canbe
> made at txn creation time, and is a parameter of the transaction. Ten
> all FS functions that take a txn parameter can decide whether to
> perform the checks or not. The FS api remains unchanged (except for
> create_txn, which gets an extra flag); the repos wrappers go away, and
> everybody's happy.
>
> (s/out-of-date/lock/g in the above, same argument applies)
>
> -- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 3 18:12:49 2004