subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <>
Subject 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/ tests/cmdline/svntest/
Date Tue, 21 Aug 2012 21:22:12 GMT
On 21.08.2012 22:28, Johan Corveleyn wrote:
> On Tue, Aug 21, 2012 at 9:52 PM, Mark Phippard <> wrote:
>> On Tue, Aug 21, 2012 at 3:46 PM, Branko Čibej <> wrote:
>>> On 21.08.2012 21:37, Mark Phippard wrote:
> ...
>>>> 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.
>> Mike would have to answer that, but ISTR that the client/server
>> negotiation kept the client from sending this information.  So older
>> servers would not get the props.
> Actually, as an svn admin, I wouldn't mind having the version revprops
> written to the repository. That can be very interesting information,
> especially if you're diagnosing some kind of problem, trying to find a
> pattern, pinpointing it to particular clients, ...
> Last year I had a couple of situations where I really wanted to find
> out what client (and client-version) had performed a particular
> commit, or trying to find a common pattern between various occurrences
> of strangeness (mostly related to issue #4065 [1], which was first
> "broken" by some git-svn clients, and then later on by some versions
> of svnkit).
> But that might be a rather exceptional use case, so not sure if it's
> worth it ...

That sort of thing belongs in server logs, not in the repository.

-- Brane

Certified & Supported Apache Subversion Downloads:

View raw message