After IRC conversation between myself, brane, markphip, stsp, danielsh, and (to a less degree) julianf, I think I have a clear path forward on this now. The general sentiments are:
* that 'start-commit' is today useful for making a repository "truly
read-only" (as in, not modifiable at all) is an undocumented side-effect,
but one that we suspect folks aren't relying /precisely/ on.
* rather, the use-cases we were collectively aware of involved ensuring
that the repository could be simply put into a state where no new
revisions are created, and no existing revprops are modified.
* changing 'start-commit' to be invoked after txn creation and txnprop
population, and to receive the txn-id as a new final arg, would:
- allow existing start-commit hooks to continue to provide the
don't-allow-any-new-revisions behavior, and
- allow hook authors to create/amend their start-commit hooks to
examine txnprops and potentially offer the early detection of
commits destined to fail that we've been talking about.
* besides, philip's freeze/unfreeze offers a far more logical way to
get honest-to-goodness-read-only-ness.
So, based on the above, the my new plan of action is as follows:
1. Revert the addition of the 'init-commit' hook script feature.
2. Change 'start-commit' to run after txn creation and txnprop population
(literally, like, moving a function call down two or three lines).
3. Add the txn-id argument to the end of the 'start-commit' arg list.
Bert asked the question of what would trigger the new start-commit behavior
-- upgrade to 1.8? A format bump for the repository? Personally, I lean
towards just the 1.8 upgrade. I don't feel like this only justifies a
format bump for the repository. That said, if Philip's freeze/unfreeze
brings in a format bump, I'm happy to tie this start-commit change to that
bump, too.
--
C. Michael Pilato <[email protected]>
CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
