[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Regression in bindings? 1.7/1.8 vs 1.6

From: Stefan Sperling <stsp_at_elego.de>
Date: Sun, 10 Aug 2014 20:46:45 +0200

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
Received on 2014-08-10 20:47:17 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.