On Sunday, August 10, 2014 08:46:45 PM Stefan Sperling wrote:
> On Sun, Aug 10, 2014 at 09:14:05AM -0700, Alexey Neyman wrote:
> > On Saturday, August 09, 2014 10:50:11 PM Alexey Neyman wrote:
> > > Hi Subversion developers,
> > >
> > > I am trying to migrate some scripts from 1.6 server that we're currently
> > > running to a newer SVN version, and encountered something that looks
> > > like
> > > a bug: with 1.7/1.8 the fs.change_node_prop (in Python bindings) is no
> > > longer able to modify a node's properties unless that node is already
> > > modified in the transaction being handled.
> >
> > How come the node is marked as changed, but the changes are lost?
>
> Ummm... hooks are not supposed to modify transactions.
>
> Have you seen this paragraph in the svn 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. While it might be tempting to use hook
> scripts to automatically correct errors, shortcomings, or policy violations
> present in the files being committed, doing so can cause problems.
> Subversion keeps client-side caches of certain bits of repository data, and
> if you change a commit transaction in this way, those caches become
> indetectably stale. This inconsistency can lead to surprising and
> unexpected behavior. Instead of modifying the transaction, you should
> simply validate the transaction in the pre-commit hook and reject the
> commit if it does not meet the desired requirements. As a bonus, your users
> will learn the value of careful, compliance-minded work habits.
> """
> http://svnbook.red-bean.com/en/1.7/svn.reposadmin.create.html#svn.reposadmin
> .create.hooks
Yes, I've seen it and I remember there have been discussion in the past on the mailing list
that the Subversion server should notify the client that the committed revision is
different from the client's submission - so that the client can invalidate those caches.
In our case, though, the modification is very benign: the script detects that any file under
/project/trunk gets modified, and if it does - updates the property on the
/project/trunk/include/version.h. The production build server checks out a fresh copy for
the build, so that there is no caches involved; and if the local (committer's) environment
has a stale version.h, it is not a big deal.
So the question still stands - was this change in svn_fs_change_node_prop() by design, or is
it an unwanted side effect of some other change? An in any case - is there way to modify
the transaction that *works*, even if not recommended?
Regards,
Alexey.
Received on 2014-08-11 00:00:16 CEST