Re: Fwd: start-commit hook client capabilities - mergeinfo only?

Brett Randall <javabrett_at_gmail.com> writes:

> Is it still considered valid to filter the client-capabilities passed
> to start-commit? The topic seemed to start with a conversation about
> separately-reporting client RA/protocol versus client-feature
> capabilities, but this resulted in the aforementioned "censoring" of
> the list of capabilities. Shouldn't start-commit be passed everything
> the client sends, and the hook-script author can decide for themselves
> what is important (in the context of the hook-script) and what isn't?
> What start-commit sees and what the server deems important about the
> client-capabilities seem like two separate topics to me, but I may be
> misguided in my guess at what the intended scope of start-commit is.

That would be a topic for the dev list.

If the problem you are trying to solve is that you want your server to
know about clients then there is an alternative, the ephemeral
txnprops added to 1.8. See:

http://subversion.apache.org/docs/release-notes/1.8.html#ephemeral-txnprops

A start-commit script can use:

  svnlook propget --revprop -t "$4" "$1" svn:txn-user-agent
  svnlook propget --revprop -t "$4" "$1" svn:txn-client-compat-version

For example a server will detect my 1.9.x client as:

  svn:txn-client-compat-version
    1.9.2-dev

  svn:txn-user-agent
    SVN/1.9.2-dev (x86_64-unknown-linux-gnu) serf/1.3.9

As with client capabilites this can only be trusted in so far as you
trust the client to send the correct information.

-- 
Philip Martin
WANdisco