Re: [Issue 4124] New - Give servers sufficient means to disallow commits from clients based on version numbers

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 <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development