Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of ben@reser.org designates
 50.197.89.41 as permitted sender)
Message-ID: <53E83A10.7000004@reser.org>
Date: Sun, 10 Aug 2014 20:35:44 -0700
From: Ben Reser <ben@reser.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Alexey Neyman <stilor@att.net>, dev@subversion.apache.org
Subject: Re: Regression in bindings? 1.7/1.8 vs 1.6
References: <1423620.inSQzY4Xuy@mistral> <2341586.ATo68LPhJJ@mistral>
 <53E81A80.1090600@reser.org> <2779764.pChLshXY5o@mistral>
In-Reply-To: <2779764.pChLshXY5o@mistral>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

Side note this is in the pre-commit.tmpl that we create when you create a
repository:

[[[
#   ***  NOTE: THE HOOK PROGRAM MUST NOT MODIFY THE TXN, EXCEPT  ***
#   ***  FOR REVISION PROPERTIES (like svn:log or svn:author).   ***
]]]

On 8/10/14 7:36 PM, Alexey Neyman wrote:
> 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.

I think that's a safe assumption given the above statement in our template file.

> 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.

> 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.

No transactions cannot be based on transactions, they must always be based on
revisions.

Sure a post-commit can execute a commit.

> 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?

We build transactions up without any sort of locking.  The only sort of locking
that happens is when a transaction is being converted to a revision (which is
of course has to be serialized).  The post-commit hook runs outside that lock.
 There is in fact no guarantee the post-commit hook even runs (say power
failure between the commit completing and post-commit starting).  For that
matter, the post-commit hooks can even run out of order.

For all of those reasons, I think we should spend time discussing what you're
actually trying to do.

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.

So I'd suggest you start a new thread on users@subversion.apache.org asking how
to solve the actual problem you're trying to solve rather than the problem
you've run into solving it.  It's fine to mention that you tried pre-commit and
ran into these problems, but focus on your actual problem rather than the
solution you have in mind.