On 08/21/2012 03:41 PM, Branko Čibej wrote: > 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?
The one that seems most common is to reject commits whose log messages don't conform to some ruleset. Since we lack a log message template feature, we advise folks to simply bounce non-conforming commits with the log template embedded in the bounce message. Subversion is also integrated into workflow systems that may demand that an issue tracker ID be associated with every commit -- again, something that can't be checked today until the whole commit crosses the wire. Some releases ago (1.5?) we made extra effort to allow folks to attach custom revprops to their commits as part of the process (rather than as a follow-up, post-commit thing): any validation of those things must necessarily wait until pre-commit today as well. We have all kinds of just-in-time checks that are part of our commit process: just-in-time out-of-dateness checks (this is why we do postfix text deltas), just-in-time lock token checks, etc. It seems like a deficiency that we have no just-in-time metadata checks, too. And even though this is isn't part of the codified roadmap yet, it seems reasonable to look to the future where we've discussed having clients pre-announce the to-be-modified files before sending even the first bit of real commit data across the wire and realize that we'd want a hook in place that could do something with that information to, again, prevent unnecessary additional wire transfer. -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
