On 21.08.2012 21:29, C. Michael Pilato wrote:
> On 08/21/2012 03:14 PM, Branko Čibej wrote:
>> On 21.08.2012 21:07, Mark Phippard wrote:
>>> I am also not crazy about introducing a bunch of new hooks that are
>>> all more or less what the original start-commit hook was doing.
>> Have to agree here. I'm a bit worried that we're trying to introduce
>> features too specific to what some vendor's client requests. This
>> started off with finding ways to communicate the client version to the
>> server (doubtful, but marginally acceptable) and suddenly we're talking
>> about a new hook which, among other things, would set in stone the
>> process that the server must follow during a commit.
>> I'm not at all sure that enough thought has been put into the idea.
> While it is the case that client-version stuff stirred my creativity towards
> this change, I want to be clear that I didn't actually decide to make the
> change for that reason. I made the change to introduce the hook because
> when I mentioned the possibility of blocking a commit destined to fail
> before a gig of data was transmitted across the wire, I got feedback from
> several folks who were singing the praises of the idea.
Ah well, people are going to sing praises to all sorts of things.
> for the record, I
> still am not sure that the client-version stuff is best approached using
> txnprops. (But thanks anyway for the public implication that I'm merely a
> hive-mind hacker.)
Heh. I know I've been guilty of that kind of thinking every so often, so
welcome to the club. :)
Seriously though: How will the presence of revprops affect the decision
to reject a commit? If based on svn:author, we already have a better way
in place. What kind of other questions are relevant?
Certified & Supported Apache Subversion Downloads:
Received on 2012-08-21 21:41:38 CEST