On Tue, Aug 21, 2012 at 9:52 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Tue, Aug 21, 2012 at 3:46 PM, Branko Čibej <brane_at_wandisco.com> 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 ...
[1] http://subversion.tigris.org/issues/show_bug.cgi?id=4065 (server
should enforce LF normalization for svn:eol-style=native files)
--
Johan
Received on 2012-08-21 22:29:37 CEST