Re: Regression in bindings? 1.7/1.8 vs 1.6

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