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 <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-08-21 21:53:19 CEST