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