On 10.08.2014 23:59, Alexey Neyman wrote: > > 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? >
Not in a hook. Let's not quibble about "benign" changes, and what the server could do in some parallel universe. Please just follow the restrictions plainly stated in our documentation since 1.0. -- Brane -- Branko Čibej | Director of Subversion WANdisco | Realising the impossibilities of Big Data e. br...@wandisco.com
