[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 21 Aug 2012 15:29:57 -0400

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. 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.)

If the community decides to simply modify start-commit to run *after* the
txn gets created and populated with txnprops, that's fine with me. I
assumed that that change was undesirable due to the fact mentioned
elsethread about how start-commit would no longer be useful for keeping a
would-be read-only repository read-only.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

Received on 2012-08-21 21:30:31 CEST

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