subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Neyman <sti...@att.net>
Subject Re: Regression in bindings? 1.7/1.8 vs 1.6
Date Mon, 11 Aug 2014 06:25:44 GMT
[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@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.

Mime
View raw message