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.
