[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 users_at_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.
Received on 2014-08-11 08:26:18 CEST