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? -- Brane -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
