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.
Received on 2014-08-11 04:36:54 CEST