You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ryan J Ollos <rj...@apache.org> on 2016/04/23 23:23:37 UTC

Modifying transaction properties (svnadmin setrevprop)

For a long time I've known the rule "don't modify a transaction in a
pre-commit hook", documented in (1) and recently repeated in (2).

I was therefore surprised to read about the "svnadmin setrevprop" command
(3) in 1.9, and to see an example of modifying transaction properties in
the hook-scripts: "persist-ephemeral-txnprops.py" (4).

Are there some conditions under which it's okay to modify the transaction,
or are there only specific use-cases when this should be done?

Thanks,
- Ryan

(1)
http://svnbook.red-bean.com/en/1.8/svn.reposadmin.create.html#svn.reposadmin.create.hooks
(2) http://markmail.org/message/kmxxbk4nrvmpc66r
(3)
https://subversion.apache.org/docs/release-notes/1.9.html#svnadmin-revprop
(4)
http://svn.apache.org/viewvc/subversion/trunk/tools/hook-scripts/persist-ephemeral-txnprops.py?view=markup

Re: Modifying transaction properties (svnadmin setrevprop)

Posted by Daniel Shahaf <da...@apache.org>.
Ryan J Ollos wrote on Sat, Apr 23, 2016 at 17:43:44 -0700:
> On Sat, Apr 23, 2016 at 3:19 PM, Daniel Shahaf <da...@apache.org> wrote:
> 
> > Daniel Shahaf wrote on Sat, Apr 23, 2016 at 21:48:38 +0000:
> > > Ryan J Ollos wrote on Sat, Apr 23, 2016 at 14:23:37 -0700:
> > > > For a long time I've known the rule "don't modify a transaction in a
> > > > pre-commit hook", documented in (1) and recently repeated in (2).
> > > >
> > > > I was therefore surprised to read about the "svnadmin setrevprop"
> > command
> > > > (3) in 1.9, and to see an example of modifying transaction properties
> > in
> > > > the hook-scripts: "persist-ephemeral-txnprops.py" (4).
> > > >
> > > > Are there some conditions under which it's okay to modify the
> > transaction,
> > > > or are there only specific use-cases when this should be done?
> >
> > I think I can give a simpler answer: anything you can do using only
> > svnadmin/svnlook is okay.  The rule you quote refers to people who
> > directly use the svn_fs_* APIs, or DAV clients.
> >
> > Cheers,
> >
> > Daniel
> >
> 
> Thanks, that makes sense. In the past, I have applied the rule in an
> overly-restrictive way when considering pre-/post-commit hook use cases.

Then perhaps the book's warning box [1] should be clarified with the
information in this thread [2].  CCing svnbook-dev@.

Cheers,

Daniel
(Ryan: svnbook is maintained outside ASF by the same people that make up
the svn PMC)

[1] http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html#svn.reposadmin.hooks.summary
[2] http://svn.haxx.se/users/archive-2016-04/index.shtml#57

Re: Modifying transaction properties (svnadmin setrevprop)

Posted by Ryan J Ollos <rj...@apache.org>.
On Sat, Apr 23, 2016 at 3:19 PM, Daniel Shahaf <da...@apache.org> wrote:

> Daniel Shahaf wrote on Sat, Apr 23, 2016 at 21:48:38 +0000:
> > Ryan J Ollos wrote on Sat, Apr 23, 2016 at 14:23:37 -0700:
> > > For a long time I've known the rule "don't modify a transaction in a
> > > pre-commit hook", documented in (1) and recently repeated in (2).
> > >
> > > I was therefore surprised to read about the "svnadmin setrevprop"
> command
> > > (3) in 1.9, and to see an example of modifying transaction properties
> in
> > > the hook-scripts: "persist-ephemeral-txnprops.py" (4).
> > >
> > > Are there some conditions under which it's okay to modify the
> transaction,
> > > or are there only specific use-cases when this should be done?
>
> I think I can give a simpler answer: anything you can do using only
> svnadmin/svnlook is okay.  The rule you quote refers to people who
> directly use the svn_fs_* APIs, or DAV clients.
>
> Cheers,
>
> Daniel
>

Thanks, that makes sense. In the past, I have applied the rule in an
overly-restrictive way when considering pre-/post-commit hook use cases.

- Ryan

Re: Modifying transaction properties (svnadmin setrevprop)

Posted by Daniel Shahaf <da...@apache.org>.
Daniel Shahaf wrote on Sat, Apr 23, 2016 at 21:48:38 +0000:
> Ryan J Ollos wrote on Sat, Apr 23, 2016 at 14:23:37 -0700:
> > For a long time I've known the rule "don't modify a transaction in a
> > pre-commit hook", documented in (1) and recently repeated in (2).
> > 
> > I was therefore surprised to read about the "svnadmin setrevprop" command
> > (3) in 1.9, and to see an example of modifying transaction properties in
> > the hook-scripts: "persist-ephemeral-txnprops.py" (4).
> > 
> > Are there some conditions under which it's okay to modify the transaction,
> > or are there only specific use-cases when this should be done?

I think I can give a simpler answer: anything you can do using only
svnadmin/svnlook is okay.  The rule you quote refers to people who
directly use the svn_fs_* APIs, or DAV clients.

Cheers,

Daniel

Re: Modifying transaction properties (svnadmin setrevprop)

Posted by Daniel Shahaf <da...@apache.org>.
Ryan J Ollos wrote on Sat, Apr 23, 2016 at 14:23:37 -0700:
> For a long time I've known the rule "don't modify a transaction in a
> pre-commit hook", documented in (1) and recently repeated in (2).
> 
> I was therefore surprised to read about the "svnadmin setrevprop" command
> (3) in 1.9, and to see an example of modifying transaction properties in
> the hook-scripts: "persist-ephemeral-txnprops.py" (4).
> 
> Are there some conditions under which it's okay to modify the transaction,
> or are there only specific use-cases when this should be done?

Modifying transaction/revision properties is fine, since they are
mutable data that may change at any time after the commit: the
committing client's worldview will be as though somebody edited the
revprop immediately after its commit went through.

For everything else (text, property, and tree modifications), the client
assumes that what it submitted is what is stored in the repository in
the revision the commit created [that revision's number is reported to
the client], so if the hooks break that assumption, the committing
client may have a broken worldview.

Cheers,

Daniel