Re: svn commit: r1375675 - in /subversion/trunk/subversion: include/svn_repos.h libsvn_repos/fs-wrap.c libsvn_repos/hooks.c libsvn_repos/repos.c libsvn_repos/repos.h tests/cmdline/commit_tests.py tests/cmdline/svntest/actions.py

On 21.08.2012 21:37, Mark Phippard wrote:
> On Tue, Aug 21, 2012 at 3:29 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>
>> If the community decides to simply modify start-commit to run *after* the
>> txn gets created and populated with txnprops, that's fine with me. I
>> assumed that that change was undesirable due to the fact mentioned
>> elsethread about how start-commit would no longer be useful for keeping a
>> would-be read-only repository read-only.
> start-commit does not currently receive the txn-id, so I do not see
> how we can use/move it for svn:log access anyway. How about a single
> new hook called something like start-commit-txn or something like
> that?
>
> FWIW, I agree it would be nice to have access to svn:log before the
> data is sent from the client.

I expect this would mean checking for log-file format conformance?

> People could do a lot with that, and if
> it is easier to attach the client version to the txn properties, then
> that is another good reason.
>
> IMO, we have had a LOT of users@ requests for the client version in
> hook scripts.

Yeah, well, if these requests can also define what the client version
actually is, we can start thinking about a solution. In the meantime,
I'd prefer this information to not be mixed with revision properties;
not least because I can't think of a way of preventing older servers
from just writing such props into the repository.

-- Brane

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download