On Monday, August 11, 2014 01:55:41 AM Branko Čibej wrote:
> 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.reposadm
> > in>
> > > .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.
I would appreciate a more constructive response, for the following three reasons:
- First, if the fs.change_node_prop was not intended for use in scripts, why is it exposed in
bindings at all?
- Second, if you care to read the quoted paragraph, you'd notice that it is phrased as a
recommendation, not a restriction. For example, here's how the IETF determines the
requirement levels:
tools.ietf.org/html/rfc2119
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
- Third, if you care to read the original report I sent - you'd notice that it does not involve
client caches at all (which is the potential issue that the SVN book warns about with
respect to modifying the transaction). Instead, the transaction is modified in a way
different from how the script attempted to modify it.
Regards,
Alexey.
Received on 2014-08-11 02:19:58 CEST