Brett Randall <javabr...@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