On 08/17/2012 12:14 PM, C. Michael Pilato wrote: > Well, I just ran into my first hurdle: the current svnserve protocol > demands that capabilities in the standard capabilities string list be of the > protocol data class "word", which is limited to strings with letters, > numbers, and hyphens only.
Okay, how about an altogether different approach that just occurred to me.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* *
* WARNING: I WILL REFER TO THE USE OF PROPERTIES BELOW. THOSE *
* WITH HEIGHTENED SENSITIVITIES SHOULD TURN BACK NOW. *
* *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
What if instead of the capabilities mechanism, we use txnprops?
The start-commit hook wrapper logic already has access to a set of txnprops
destined for the commit transaction which will be created pending successful
completion of the hook. But the props aren't passed to the hook today.
They aren't really accessible to the hook as txnprops either because the
hook runs *before* the commit txn is created.
So, picture this crazyiness:
1. The RA layer drops the client version info we've been talking about into
txnprops ("svn:client-name", "svn:client-version", and
"svn:client-compat-version") along with svn:log and the user-provided
txnprops ('svn ci --with-revprop') and hands that off to the run-the-
start-commit-hook-and-then-make-a-txn function.
2. At this point we either:
a. serialize the revprops-to-be and hand them off to the start-commit
hook somehow (hands waving frantically), or
b. change the nature of the start-commit hook such that it runs
immediately *after* the txn is created, gets handed the txn-name so
that txnprops can be examined, and simply aborts the txn if the
start-commit hook fails. (Does this create a race condition of
txn existence that we don't want?)
3. After successful completion of the start-commit hook, we can then either:
a. remove the magic txnprops, or
b. just leave them to serve as a record of the client information
forever stored in the repository and associated with the commit.
4. As a bonus side-effect, users can now deny commits with substandard log
messages *before* the whole commit comes across the wire, which they
can't do today.[1]
It's Monday. My ceiling was leaking water over the weekend. I have two
extra children in my house this morning. [Insert additional excuses.]
Discuss.
-- C-Mike
[1] mod_dav_svn is an exception here, because the log message is
PROPPATCHed into the transaction after it's creation. start-commit
hooks would have to assume that a non-existent log message is simply
suffering delayed arrival, and their pre-commit hook will have to
continue doing this validation just as it does today.
--
C. Michael Pilato <[email protected]>
CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
