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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
