On Tue, Aug 21, 2012 at 11:22 PM, Branko Čibej <br...@wandisco.com> wrote: > On 21.08.2012 22:28, Johan Corveleyn wrote: >> On Tue, Aug 21, 2012 at 9:52 PM, Mark Phippard <markp...@gmail.com> wrote: >>> On Tue, Aug 21, 2012 at 3:46 PM, Branko Čibej <br...@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 ... > > That sort of thing belongs in server logs, not in the repository.
Ah, true, that would be even better. -- Johan
