Thanks Ben for a detailed answer. A few follow-up questions below: On Sunday, August 10, 2014 06:21:04 PM Ben Reser wrote: [... snip ...] > Here's the most important sentence form the book: > > "While hook scripts can do almost anything, there is one dimension in which > hook script authors should show restraint: do not modify a commit > transaction using hook scripts." > > Yes the word should appears in that sentence. But we really are intending > to tell you not to modify a transaction. I suspect the word should is > there because there is actually one thing that is ok to modify in a hook > script and that's the unversioned properties that will become revision > properties. Perhaps the language could be improved, but I do think that > italics on the word "not" and the following text should give you a pretty > good idea that this is not a supported operation.
So, the unversioned properties are ok to modify? Our scripts do that, too - so I'd like to know if it's ok to depend on this not to be broken by future releases. Also, I think it would be a good idea to have the transaction-modifying functions return an error once the transaction reached the stage of pre-commit hooks from functions like svn_fs_change_node_prop() - to avoid getting one's hopes high because it works in the current release. Something like SVN_TXN_READONLY. What do you think? [... snip ...] > Actually this still makes the client that's doing the commit have a stale > cache of the property. It will believe that "myprop" either has no value > or whatever the previous value is. > > You probably won't pick up any change to this property until the next time > the node changes. However, you can get away this if you're not terribly > concerned about the client having the correct state of the property because > we never send deltas for property changes. We just send the whole property > value. > > If that ever changes (which is entirely conceivable since there are property > use case that quite honestly have probably grown beyond the original intent > of properties, including svn:mergeinfo) you will be in a world of hurt > since your existing working copies when upgraded and run with clients that > understand this and servers that handle this will suddenly be busted. > Every commit until you remove this will break the working copy. I understand why it's bad for properties that Subversion interprets. In our case - as I explained, we don't care if the developer's build environment keeps a stale version of that property forever. But back to use case: I am thinking about alternative approaches to doing such auto- updates of properties and/or other content. I assume that it is not possible to create a transaction B based on a transaction A in the pre-commit hook (so that when transaction A becomes a revision, transaction B uses that new revision as a base), is it? It seems that the only supported way to do that would be to schedule the "update tasks" to be done in the pre-commit script, but actually execute them in a new transaction. Hence, another question - is a post-commit hook allowed to create and commit a transaction, or does it have to be deferred until after the post-commit hook finishes? And finally, is there a way to prevent further transactions from being created and/or turned into revisions until the post-commit hook has finished performing the scheduled tasks? In other words, can Subversion start another transaction before the post-commit hook finishes on the revision just created? [... snip ...] > I haven't dug in to the specifics of how we broke this particular use case. > But I suspect you'll find that if you create a transaction, call > svn_fs_change_node_prop() and commit the transaction that this call works > just fine. So I'd bet that the problem only happens when you try to do > this from the pre-commit hook. Indeed. So because of this it makes even more sense to have functions like svn_fs_change_node_prop() fail explicitly with an error, rather than modifying a transaction in an unpredictable way. Thanks again, Alexey.
