[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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/commit_tests.py tests/cmdline/svntest/actions.py

From: Branko Čibej <brane_at_wandisco.com>
Date: Tue, 21 Aug 2012 21:41:00 +0200

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:
Received on 2012-08-21 21:41:38 CEST

This is an archived mail posted to the Subversion Dev mailing list.