[CC'ing users@] On Sunday, August 10, 2014 08:35:44 PM Ben Reser wrote: > > 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? > > Keeping in mind that Subversion doesn't have a central process that owns the > file system, it'd have to be something we write out to the transaction. > I'm not sure how practical that is given our current formats. But yes this > might not be a bad idea since it's not something we intend to allow. I > haven't done too much digging but that might even be what we're doing.
That's what I meant - the functions like svn_fs_change_node_prop() will return an error status, not that some "owner process" will report an error to the system log. Is there a way for these functions could check whether the FS root passed as the first argument belongs to a transaction that is currently executing the pre-commit hook? > > 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? > > Perhaps it would be better to tell us what you're trying to do rather than > talking about how you're trying to do it. I can't think of a good reason > why you need to be modifying properties on files like this. I described this in the previous email: I want to have one file, /project/trunk/include/version.h, reflect the last revision that touched any file in the project. For that purpose, pre-commit hook (on a server currently using SVN 1.6) checks if any file under /project/trunk is modified and if it's the case, modifies a property on the /project/trunk/include/version.h. This in turn causes $Revision$ in <version.h> to reflect the last revision when ANY file in the project was modified, not when the <version.h> itself was modified. There is another case where our current scripts modified the node properties during pre- commit: we use a modified version of FreeBSD's verify.py, and among other checks, it uses heuristics to determine whether a file is binary or text. The FreeBSD's version checks that every time, while we tried to cache the result of that heuristicss in a file's property. Am I missing some obvious way to do these tasks? > Additionally, I'd point out that this whole thread should probably be > happening on us...@subversion.apache.org. I don't think this is a bug. > You may also get more responses to your questions there, since you're > hitting a much broader audience that largely consists of admins instead of > just developers. I'd guess some of those admins have dealt with similar > problems. By contracts us developers don't typically administer > repositories, in fact since joining the ASF we don't even admin our own > repository. CC'ed users@; feel free to drop dev@ when replying. Regards, Alexey.
