C. Michael Pilato wrote on Fri, 18 Jun 2010 at 22:02 -:
> Daniel Shahaf wrote:
> > You mean, to extend the dav_db structure to hold that information? If
> > that's possible, I suppose the only candidate for filling in that
> > information is db_open(), who can examine its dav_resource object.
Hi,
Daniel Shahaf wrote:
> But I wonder if, while here, we could go further and obtain
> the "expected old property value" from the RA layer (and
> pass it to the pre-hook). (This probably means revving
> svn_ra_change_rev_prop() the same way svn_fs_change_rev_prop()
> was revved.) That will all
Daniel Shahaf wrote:
> C. Michael Pilato wrote on Fri, 18 Jun 2010 at 09:48 -0400:
>> Does mod_dav open and close the DAV properties database exactly once
>> per PROPPATCH?
>
> Yes. (I checked dav_method_proppatch() in .) Why is
> this important to know?
Well, if it opened the props database on
C. Michael Pilato wrote on Fri, 18 Jun 2010 at 09:48 -0400:
> Daniel Shahaf wrote:
> > * ra_dav: I don't know about this one.
> >
> > From the neon/serf side, adding the optional "expected preexisting
> > value" should be straightforward (just another tag/attribute).
> >
> > From the mo
Daniel Shahaf wrote:
> * ra_dav: I don't know about this one.
>
> From the neon/serf side, adding the optional "expected preexisting
> value" should be straightforward (just another tag/attribute).
>
> From the mod_dav_svn side, however, the propchanges/propdeletes come
> from db_stor
[ summary: a question about the ra_dav protocol ]
Daniel Shahaf wrote on Thu, 17 Jun 2010 at 16:21 +0300:
> Philip Martin wrote on Thu, 17 Jun 2010 at 12:18 -:
> > Daniel Shahaf writes:
> > > But I wonder if, while here, we could go further and obtain the
> > > "expected old property value" f
Philip Martin wrote on Thu, 17 Jun 2010 at 12:18 -:
> Daniel Shahaf writes:
>
> > Philip Martin wrote on Tue, 15 Jun 2010 at 11:16 -:
> >
> >> Then the repos layer can loop (in practice only if the
> >> use_pre_revprop_change_hook flag is set):
> >>
> >>do
> >> svn_fs_re
Daniel Shahaf writes:
> Philip Martin wrote on Tue, 15 Jun 2010 at 11:16 -:
>
>> Then the repos layer can loop (in practice only if the
>> use_pre_revprop_change_hook flag is set):
>>
>>do
>> svn_fs_revision_prop(¤t_value)
>> action = ...
>> svn_repos__hook
Philip Martin wrote on Tue, 15 Jun 2010 at 11:16 -:
> Philip Martin writes:
>
> > Multiple clients. It arises from my idea to solve issue 3546
> >
> > http://subversion.tigris.org/issues/show_bug.cgi?id=3546
> >
> > In svn_repos_fs_change_rev_prop3 the code first gets the old property
> > va
Philip Martin wrote:
> Philip Martin writes:
>
>> Multiple clients. It arises from my idea to solve issue 3546
>>
>> http://subversion.tigris.org/issues/show_bug.cgi?id=3546
>>
>> In svn_repos_fs_change_rev_prop3 the code first gets the old property
>> value which it uses to calculate the action
Daniel Shahaf wrote on Wed, 16 Jun 2010 at 01:19 -:
> Philip Martin wrote on Tue, 15 Jun 2010 at 11:16 -:
> > Philip Martin writes:
> > > Putting the get, pre hook and set into a transaction would allow the
> > > action in the hook to accurately reflect the change made (or not made
> > > i
Philip Martin wrote on Tue, 15 Jun 2010 at 11:16 -:
> Philip Martin writes:
> > Putting the get, pre hook and set into a transaction would allow the
> > action in the hook to accurately reflect the change made (or not made
> > if the transaction fails).
>
> We don't need a new transaction to
Philip Martin writes:
> Multiple clients. It arises from my idea to solve issue 3546
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=3546
>
> In svn_repos_fs_change_rev_prop3 the code first gets the old property
> value which it uses to calculate the action: 'A', 'M' or 'D'. Then it
> pa
Peter Samuelson writes:
> pre-revprop-change is mainly useful for access control,
That's because it's not reliable and so can't be used for much else.
If it was reliable it could be used for more, such as solving issue
3546.
post-revprop-change also gets the same unreliable value.
--
Philip
[Philip Martin]
> In svn_repos_fs_change_rev_prop3 the code first gets the old property
> value which it uses to calculate the action: 'A', 'M' or 'D'. Then it
> passes the action to the pre-revprop-change hook, then it changes the
> property and finally it runs the post-revprop-change hook. Some
"C. Michael Pilato" writes:
> Philip Martin wrote:
>> Revision properties are unversioned that's well documented. There are
>> two hooks associated with a revprop change, the pre-revprop-change and
>> the post-revprop-change. What's not well documented is that these
>> hooks and the change are
Philip Martin wrote:
> Revision properties are unversioned that's well documented. There are
> two hooks associated with a revprop change, the pre-revprop-change and
> the post-revprop-change. What's not well documented is that these
> hooks and the change are not executed within a Subversion tra
17 matches
Mail list logo
