You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Madan U Sreenivasan <ma...@collab.net> on 2006/12/04 13:24:44 UTC
[MERGE-TRACKING][PATCH] Make use of the svn_client_commit_item2_t->wcprop_changes member during commit of wc to repos copy
Hi,
Please find attached a preparatory step to record copyfrom info on a wc
to repos copy. This patch makes use of the currently unused wcprop_changes
member of the svn_client_commit_item2_t structure, to push props
explicitly set in wcprop_changes to the repository editor.
The next step would be to calculate the mergeinfo and fill the
wcprop_changes member in libsvn_client/copy.c:wc_to_repos_copy().
I have tested this code for functionality with a simple script I wrote.
I have run 'make check' on local to test for regression, which I beleive
is sufficient given the change is only on the client side. Please let me
know if theres anything else I should be doing.
Regards,
Madan.
PS: This idea was suggested by cmpilato, and hence I have acknowledged the
same in the 'Patch By'. Mike, I hope you dont mind :)
Re: [MERGE-TRACKING][PATCH] Make use of the svn_client_commit_item2_t->wcprop_changes member during commit of wc to repos copy
Posted by Daniel Rall <dl...@collab.net>.
On Thu, 14 Dec 2006, Madan S. wrote:
> On Fri, 08 Dec 2006 06:29:25 +0530, Daniel Rall <dl...@collab.net> wrote:
>
> >On Thu, 07 Dec 2006, Madan S. wrote:
> >
> >>On Tue, 05 Dec 2006 23:45:32 +0530, Daniel Rall <dl...@collab.net> wrote:
> >>
> >>>On Tue, 05 Dec 2006, Madan S. wrote:
> >>>
> >>>>On Tue, 05 Dec 2006 00:42:39 +0530, Daniel Rall <dl...@collab.net>
> >>wrote:
> >...
> >>>Yes, the name doesn't match exactly what we want to do, as we're not
> >>>actually changing any WC properties here. Too bad the field isn't
> >>>named prop_changes. Hmmmmmm.
> >>>
> >>>All our options here appear to involving rev'ing the data structure
> >>>and its callers. :-\
> >>>
> >>>a) Rename wcprop_changes to prop_changes, and use it for both extra
> >>>client -> repos and repos -> WC property edits, with an API contract
> >>>indicating that it must be cleared after the client -> repos prop
> >>>edits. This could be confusing to developers using the structure for
> >>>the first time, but might use less memory.
> >>>
> >>>b) Add a repos_prop_changes field for client -> repos prop edits.
> >>>
> >>>Either way, wcprop_changes could REALLY use some better documentation!
> >>
> >>I would opt for (a) which would mean one more commit (to rename and
> >>change all occurances of the old name) before we can check this into
> >>trunk.
> >
> >Why do you think option (a) is better? I was leaning towards (b) on
> >the grounds that it could provide a more obvious API, but I could
> >really go either way.
>
> Because the two usages we have currently are mutually exclusive and we
> could reuse the same field. To me, just one field to carry some extra
> commit related information around... also we dont want a pointer in this
> structure that points to nothing for each and every commit, and used
> *only* in case of a wc to repos copy. I would prefer to reuse some
> existing (if apt) variable in the structure if am not affecting the
> existing functionality.
I was typing up a response on this thread last week, but my laptop ran
out of power and died before I had a chance to send it:
"Madan, Mike, and I discussed this in a phone conversation. Mike
and I favored option (b) for clarity in a public data structure, so
I've gone that direction. I've committed a patch to trunk making
incoming_prop_changes (replaceing wcprop_changes) and
outgoing_prop_changes fields available on the
svn_client_commit_item3_t struct."
So Madan, the client committables API is available to support WC ->
repos copy on the merge-tracking branch, if not exactly in your
preferred form. :)
Thanks, Dan
Re: [MERGE-TRACKING][PATCH] Make use of the svn_client_commit_item2_t->wcprop_changes member during commit of wc to repos copy
Posted by Madan U Sreenivasan <ma...@collab.net>.
On Fri, 08 Dec 2006 06:29:25 +0530, Daniel Rall <dl...@collab.net> wrote:
> On Thu, 07 Dec 2006, Madan S. wrote:
>
>> On Tue, 05 Dec 2006 23:45:32 +0530, Daniel Rall <dl...@collab.net> wrote:
>>
>> >On Tue, 05 Dec 2006, Madan S. wrote:
>> >
>> >>On Tue, 05 Dec 2006 00:42:39 +0530, Daniel Rall <dl...@collab.net>
>> wrote:
> ...
>> >Yes, the name doesn't match exactly what we want to do, as we're not
>> >actually changing any WC properties here. Too bad the field isn't
>> >named prop_changes. Hmmmmmm.
>> >
>> >All our options here appear to involving rev'ing the data structure
>> >and its callers. :-\
>> >
>> >a) Rename wcprop_changes to prop_changes, and use it for both extra
>> >client -> repos and repos -> WC property edits, with an API contract
>> >indicating that it must be cleared after the client -> repos prop
>> >edits. This could be confusing to developers using the structure for
>> >the first time, but might use less memory.
>> >
>> >b) Add a repos_prop_changes field for client -> repos prop edits.
>> >
>> >Either way, wcprop_changes could REALLY use some better documentation!
>>
>> I would opt for (a) which would mean one more commit (to rename and
>> change all occurances of the old name) before we can check this into
>> trunk.
>
> Why do you think option (a) is better? I was leaning towards (b) on
> the grounds that it could provide a more obvious API, but I could
> really go either way.
Because the two usages we have currently are mutually exclusive and we
could reuse the same field. To me, just one field to carry some extra
commit related information around... also we dont want a pointer in this
structure that points to nothing for each and every commit, and used
*only* in case of a wc to repos copy. I would prefer to reuse some
existing (if apt) variable in the structure if am not affecting the
existing functionality.
[snip]
Regards,
Madan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [MERGE-TRACKING][PATCH] Make use of the svn_client_commit_item2_t->wcprop_changes member during commit of wc to repos copy
Posted by Daniel Rall <dl...@collab.net>.
On Tue, 12 Dec 2006, Madan S. wrote:
> On Sat, 09 Dec 2006 02:27:03 +0530, Daniel Rall <dl...@collab.net> wrote:
...
> >Madan, I'm working on rev'ing the API in a fashion which will allow
> >for either of these options (since it turned out to be an enormous
> >amount of work). If you want to tweak your WC without concerns to
> >backwards compatibility to complete the WC -> repos copy/move Merge
> >Tracking work, that would be awesome. I'll fill in on trunk.
>
> That would be great... that would also help me move on to the two other
> copy/move commands... Thank you, Dan.
Madan, I've rev'd the API -- svn_client_commit_item3_t is now
available to the Subversion libraries, the command-line client, and
all the bindings, on both trunk and the merge-tracking branch. I have
not yet changed its definition, as we were still discussing how it
should look.
I was leaning towards option B (a new field, name repos_prop_changes
or something), but you seemed to favor option A (change the name of
the existing field). Let's complete that discussion (from previous
messages on this thread).
- Dan
Re: [MERGE-TRACKING][PATCH] Make use of the svn_client_commit_item2_t->wcprop_changes member during commit of wc to repos copy
Posted by Madan U Sreenivasan <ma...@collab.net>.
On Sat, 09 Dec 2006 02:27:03 +0530, Daniel Rall <dl...@collab.net> wrote:
[snip]
>
> Madan, I'm working on rev'ing the API in a fashion which will allow
> for either of these options (since it turned out to be an enormous
> amount of work). If you want to tweak your WC without concerns to
> backwards compatibility to complete the WC -> repos copy/move Merge
> Tracking work, that would be awesome. I'll fill in on trunk.
That would be great... that would also help me move on to the two other
copy/move commands... Thank you, Dan.
Regards,
Madan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [MERGE-TRACKING][PATCH] Make use of the svn_client_commit_item2_t->wcprop_changes member during commit of wc to repos copy
Posted by Daniel Rall <dl...@collab.net>.
On Thu, 07 Dec 2006, Daniel Rall wrote:
> On Thu, 07 Dec 2006, Madan S. wrote:
>
> > On Tue, 05 Dec 2006 23:45:32 +0530, Daniel Rall <dl...@collab.net> wrote:
> >
> > >On Tue, 05 Dec 2006, Madan S. wrote:
> > >
> > >>On Tue, 05 Dec 2006 00:42:39 +0530, Daniel Rall <dl...@collab.net> wrote:
> ...
> > >Yes, the name doesn't match exactly what we want to do, as we're not
> > >actually changing any WC properties here. Too bad the field isn't
> > >named prop_changes. Hmmmmmm.
> > >
> > >All our options here appear to involving rev'ing the data structure
> > >and its callers. :-\
> > >
> > >a) Rename wcprop_changes to prop_changes, and use it for both extra
> > >client -> repos and repos -> WC property edits, with an API contract
> > >indicating that it must be cleared after the client -> repos prop
> > >edits. This could be confusing to developers using the structure for
> > >the first time, but might use less memory.
> > >
> > >b) Add a repos_prop_changes field for client -> repos prop edits.
> > >
> > >Either way, wcprop_changes could REALLY use some better documentation!
> >
> > I would opt for (a) which would mean one more commit (to rename and
> > change all occurances of the old name) before we can check this into
> > trunk.
>
> Why do you think option (a) is better? I was leaning towards (b) on
> the grounds that it could provide a more obvious API, but I could
> really go either way.
>
> If we go with option (a), a single commit is actually better, since we
> have to rev API, since we're changing a field name in the the public
> the commit item data structure.
Madan, I'm working on rev'ing the API in a fashion which will allow
for either of these options (since it turned out to be an enormous
amount of work). If you want to tweak your WC without concerns to
backwards compatibility to complete the WC -> repos copy/move Merge
Tracking work, that would be awesome. I'll fill in on trunk.
Thanks, Dan
Re: [MERGE-TRACKING][PATCH] Make use of the svn_client_commit_item2_t->wcprop_changes member during commit of wc to repos copy
Posted by Daniel Rall <dl...@collab.net>.
On Thu, 07 Dec 2006, Madan S. wrote:
> On Tue, 05 Dec 2006 23:45:32 +0530, Daniel Rall <dl...@collab.net> wrote:
>
> >On Tue, 05 Dec 2006, Madan S. wrote:
> >
> >>On Tue, 05 Dec 2006 00:42:39 +0530, Daniel Rall <dl...@collab.net> wrote:
...
> >Yes, the name doesn't match exactly what we want to do, as we're not
> >actually changing any WC properties here. Too bad the field isn't
> >named prop_changes. Hmmmmmm.
> >
> >All our options here appear to involving rev'ing the data structure
> >and its callers. :-\
> >
> >a) Rename wcprop_changes to prop_changes, and use it for both extra
> >client -> repos and repos -> WC property edits, with an API contract
> >indicating that it must be cleared after the client -> repos prop
> >edits. This could be confusing to developers using the structure for
> >the first time, but might use less memory.
> >
> >b) Add a repos_prop_changes field for client -> repos prop edits.
> >
> >Either way, wcprop_changes could REALLY use some better documentation!
>
> I would opt for (a) which would mean one more commit (to rename and
> change all occurances of the old name) before we can check this into
> trunk.
Why do you think option (a) is better? I was leaning towards (b) on
the grounds that it could provide a more obvious API, but I could
really go either way.
If we go with option (a), a single commit is actually better, since we
have to rev API, since we're changing a field name in the the public
the commit item data structure.
> >>But I guess like you said above, setting restting the wcprop_changes
> >>with a new array (not just setting nelts to 0) would not interfere with
> >>the current implementation.
...
> >The doc string on apr_array_header_t's nelts field says "The number of
> >active elements in the array". It has a separate field, nalloc, which
> >represents "The number of elements allocated in the array". My
> >understanding of apr_array_header_t is that manipulating nelts is an
> >acceptable way to shrink or clear the list (though there's also the
> >apr_array_pop() API).
> >
> >process_committed_leaf() makes proper use of the nelts field:
> >
> > /* Do wcprops in the same log txn as revision, etc. */
> > if (wcprop_changes && (wcprop_changes->nelts > 0))
> > {
>
> True, but this sanity should not be expected by default. Am not an expert
> in APR, so you are most probably right... but I would prefer to err on the
> right side :)
...
I've confirmed this with APR's core developers, and submitted a patch
to APR adding an apr_array_clear() API which does exactly this (sets
nelts to 0). We can depend on this behavior.
Re: [MERGE-TRACKING][PATCH] Make use of the svn_client_commit_item2_t->wcprop_changes member during commit of wc to repos copy
Posted by Madan U Sreenivasan <ma...@collab.net>.
On Tue, 05 Dec 2006 23:45:32 +0530, Daniel Rall <dl...@collab.net> wrote:
> On Tue, 05 Dec 2006, Madan S. wrote:
>
>> On Tue, 05 Dec 2006 00:42:39 +0530, Daniel Rall <dl...@collab.net> wrote:
>>
>> >On Mon, 04 Dec 2006, Madan S. wrote:
[snip]
> Yes, the name doesn't match exactly what we want to do, as we're not
> actually changing any WC properties here. Too bad the field isn't
> named prop_changes. Hmmmmmm.
>
> All our options here appear to involving rev'ing the data structure
> and its callers. :-\
>
> a) Rename wcprop_changes to prop_changes, and use it for both extra
> client -> repos and repos -> WC property edits, with an API contract
> indicating that it must be cleared after the client -> repos prop
> edits. This could be confusing to developers using the structure for
> the first time, but might use less memory.
>
> b) Add a repos_prop_changes field for client -> repos prop edits.
>
> Either way, wcprop_changes could REALLY use some better documentation!
I would opt for (a) which would mean one more commit (to rename and change
all occurances of the old name) before we can check this into trunk.
>> But I guess like you said above, setting restting the wcprop_changes
>> with
>> a new array (not just setting nelts to 0) would not interfere with the
>> current implementation.
>
> Really? I didn't notice any place where it might interfere.
>
> The doc string on apr_array_header_t's nelts field says "The number of
> active elements in the array". It has a separate field, nalloc, which
> represents "The number of elements allocated in the array". My
> understanding of apr_array_header_t is that manipulating nelts is an
> acceptable way to shrink or clear the list (though there's also the
> apr_array_pop() API).
>
> process_committed_leaf() makes proper use of the nelts field:
>
> /* Do wcprops in the same log txn as revision, etc. */
> if (wcprop_changes && (wcprop_changes->nelts > 0))
> {
>
True, but this sanity should not be expected by default. Am not an expert
in APR, so you are most probably right... but I would prefer to err on the
right side :)
[snip]
>> >A change like this should be committed to trunk first, as it
>> >introduces a general non-WC property setting mechanism which is
>> >decoupled from Merge Tracking.
>>
>> Agree. Will submit a patch to trunk after testing on all ra_xxx's.
>> Does ra_serf need to be tested too?
>
> Yes, but if you get a patch working with the other three, I can give
> it a whirl over ra_serf.
hmm, I tested it over trunk, and it fails over ra_dav... will check out
the problem and let you know...
Thanks for offering to test over ra_serf.
Regards,
Madan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [MERGE-TRACKING][PATCH] Make use of the svn_client_commit_item2_t->wcprop_changes member during commit of wc to repos copy
Posted by Daniel Rall <dl...@collab.net>.
On Tue, 05 Dec 2006, Madan S. wrote:
> On Tue, 05 Dec 2006 00:42:39 +0530, Daniel Rall <dl...@collab.net> wrote:
>
> >On Mon, 04 Dec 2006, Madan S. wrote:
>
> [snip]
>
> >I have a question/concern about the use of svn_client_commit_item2_t's
> >wcprop_changes field (which references
> >http://subversion.tigris.org/issues/show_bug.cgi?id=806).
> >
> >The doc string on libsvn_client/ra.c:push_wc_prop() mentions that it
> >"implements the 'svn_ra_push_wc_prop_func_t' interface". This
> >function does make use of wcprop_changes, which contains property data
> >sent back from the repository for *post-commit* processing. That is,
> >it appears that any data left in wcprop_changes after a commit occurs
> >is intended to trigger some additional processing which sets its
> >property data on the WC. See 'svn di -r 3632:3635', which shows
> >wcprop_changes propogated down to
> >libsvn_wc/adm_ops.c:process_committed_leaf(), by way of what's now the
> >svn_wc_process_committed4() -- or _committed5, on the merge-tracking
> >branch -- API.
> >
> >While I didn't notice anything in particular which would prevent us
> >from using wcprop_changes as a pre-commit queue of additional property
> >changes to send from the client to the repository, won't we need to
> >clear out the wcprop_changes array after sending the data to the repos
> >as part of the commit to avoid doing unnecessary and incorrect
> >post-commit processing (which sets the WC's properties to what we sent
> >to the repos)? Something along the lines of a
> >"item->wcprop_changes->nelts = 0;" as the last statement at the end of
> >your "if (item->wcprop_changes)" block might suffice.
>
> You are correct. I didn't understand this logic earlier... but again, as
> you say, this should not prevent us from using the member prior to commit
> on the repos (maybe the name doesnt exactly match what we want to do ? -
> as it says 'wcprop' in a different sense?).
Yes, the name doesn't match exactly what we want to do, as we're not
actually changing any WC properties here. Too bad the field isn't
named prop_changes. Hmmmmmm.
All our options here appear to involving rev'ing the data structure
and its callers. :-\
a) Rename wcprop_changes to prop_changes, and use it for both extra
client -> repos and repos -> WC property edits, with an API contract
indicating that it must be cleared after the client -> repos prop
edits. This could be confusing to developers using the structure for
the first time, but might use less memory.
b) Add a repos_prop_changes field for client -> repos prop edits.
Either way, wcprop_changes could REALLY use some better documentation!
> But I guess like you said above, setting restting the wcprop_changes with
> a new array (not just setting nelts to 0) would not interfere with the
> current implementation.
Really? I didn't notice any place where it might interfere.
The doc string on apr_array_header_t's nelts field says "The number of
active elements in the array". It has a separate field, nalloc, which
represents "The number of elements allocated in the array". My
understanding of apr_array_header_t is that manipulating nelts is an
acceptable way to shrink or clear the list (though there's also the
apr_array_pop() API).
process_committed_leaf() makes proper use of the nelts field:
/* Do wcprops in the same log txn as revision, etc. */
if (wcprop_changes && (wcprop_changes->nelts > 0))
{
*shrug*
> >A change like this should be committed to trunk first, as it
> >introduces a general non-WC property setting mechanism which is
> >decoupled from Merge Tracking.
>
> Agree. Will submit a patch to trunk after testing on all ra_xxx's.
> Does ra_serf need to be tested too?
Yes, but if you get a patch working with the other three, I can give
it a whirl over ra_serf.
> Thanks for the review, Dan.
You're welcome, Madan!
- Dan
Re: [MERGE-TRACKING][PATCH] Make use of the svn_client_commit_item2_t->wcprop_changes member during commit of wc to repos copy
Posted by Madan U Sreenivasan <ma...@collab.net>.
On Tue, 05 Dec 2006 00:42:39 +0530, Daniel Rall <dl...@collab.net> wrote:
> On Mon, 04 Dec 2006, Madan S. wrote:
[snip]
> I have a question/concern about the use of svn_client_commit_item2_t's
> wcprop_changes field (which references
> http://subversion.tigris.org/issues/show_bug.cgi?id=806).
>
> The doc string on libsvn_client/ra.c:push_wc_prop() mentions that it
> "implements the 'svn_ra_push_wc_prop_func_t' interface". This
> function does make use of wcprop_changes, which contains property data
> sent back from the repository for *post-commit* processing. That is,
> it appears that any data left in wcprop_changes after a commit occurs
> is intended to trigger some additional processing which sets its
> property data on the WC. See 'svn di -r 3632:3635', which shows
> wcprop_changes propogated down to
> libsvn_wc/adm_ops.c:process_committed_leaf(), by way of what's now the
> svn_wc_process_committed4() -- or _committed5, on the merge-tracking
> branch -- API.
>
> While I didn't notice anything in particular which would prevent us
> from using wcprop_changes as a pre-commit queue of additional property
> changes to send from the client to the repository, won't we need to
> clear out the wcprop_changes array after sending the data to the repos
> as part of the commit to avoid doing unnecessary and incorrect
> post-commit processing (which sets the WC's properties to what we sent
> to the repos)? Something along the lines of a
> "item->wcprop_changes->nelts = 0;" as the last statement at the end of
> your "if (item->wcprop_changes)" block might suffice.
You are correct. I didn't understand this logic earlier... but again, as
you say, this should not prevent us from using the member prior to commit
on the repos (maybe the name doesnt exactly match what we want to do ? -
as it says 'wcprop' in a different sense?).
But I guess like you said above, setting restting the wcprop_changes with
a new array (not just setting nelts to 0) would not interfere with the
current implementation.
> A change like this should be committed to trunk first, as it
> introduces a general non-WC property setting mechanism which is
> decoupled from Merge Tracking.
Agree. Will submit a patch to trunk after testing on all ra_xxx s. Does
ra_serf need to be tested too?
Thanks for the review, Dan.
Regards,
Madan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [MERGE-TRACKING][PATCH] Make use of the svn_client_commit_item2_t->wcprop_changes member during commit of wc to repos copy
Posted by Daniel Rall <dl...@collab.net>.
On Mon, 04 Dec 2006, Madan S. wrote:
> Please find attached a preparatory step to record copyfrom info on a wc
> to repos copy. This patch makes use of the currently unused wcprop_changes
> member of the svn_client_commit_item2_t structure, to push props
> explicitly set in wcprop_changes to the repository editor.
This looks like the right spot to push the additional "svn:mergeinfo"
property information from the client to the repository. I like the
direct editor drive here in libsvn_client's do_item_commit(), rather
than in svn_wc_transmit_prop_deltas(), because in WC -> repos
copy/move, we don't intend to set this merge info on the WC -- we only
set it on the repository on the copy/move destination.
> The next step would be to calculate the merge info and fill the
> wcprop_changes member in libsvn_client/copy.c:wc_to_repos_copy().
I have a question/concern about the use of svn_client_commit_item2_t's
wcprop_changes field (which references
http://subversion.tigris.org/issues/show_bug.cgi?id=806).
The doc string on libsvn_client/ra.c:push_wc_prop() mentions that it
"implements the 'svn_ra_push_wc_prop_func_t' interface". This
function does make use of wcprop_changes, which contains property data
sent back from the repository for *post-commit* processing. That is,
it appears that any data left in wcprop_changes after a commit occurs
is intended to trigger some additional processing which sets its
property data on the WC. See 'svn di -r 3632:3635', which shows
wcprop_changes propogated down to
libsvn_wc/adm_ops.c:process_committed_leaf(), by way of what's now the
svn_wc_process_committed4() -- or _committed5, on the merge-tracking
branch -- API.
While I didn't notice anything in particular which would prevent us
from using wcprop_changes as a pre-commit queue of additional property
changes to send from the client to the repository, won't we need to
clear out the wcprop_changes array after sending the data to the repos
as part of the commit to avoid doing unnecessary and incorrect
post-commit processing (which sets the WC's properties to what we sent
to the repos)? Something along the lines of a
"item->wcprop_changes->nelts = 0;" as the last statement at the end of
your "if (item->wcprop_changes)" block might suffice.
A change like this should be committed to trunk first, as it
introduces a general non-WC property setting mechanism which is
decoupled from Merge Tracking.
> I have tested this code for functionality with a simple script I wrote.
> I have run 'make check' on local to test for regression, which I beleive
> is sufficient given the change is only on the client side. Please let me
> know if theres anything else I should be doing.
Changes like this which drive a RA editor should be tested over all RA
mechanisms.
...
> Preparatory step for recording copyfrom info on wc to repos copy.
>
> On the merge-tracking branch:
>
> * subversion/libsvn_client/commit_util.c
> (do_item_commit): Take into account the item's wcprop_changes value when
> the item's state flag has SVN_CLIENT_COMMIT_ITEM_PROP_MODS set.
...
> --- subversion/libsvn_client/commit_util.c (revision 22554)
> +++ subversion/libsvn_client/commit_util.c (working copy)
> @@ -1180,6 +1180,28 @@
> tempfile = apr_pstrdup(apr_hash_pool_get(tempfiles), tempfile);
> apr_hash_set(tempfiles, tempfile, APR_HASH_KEY_STRING, (void *)1);
> }
> +
> + /* Set other prop-changes, if available in the baton */
> + if (item->wcprop_changes)
> + {
> + svn_prop_t *prop;
> + apr_array_header_t *prop_changes = item->wcprop_changes;
> + int ctr;
> + for (ctr = 0; ctr < prop_changes->nelts; ctr++)
> + {
> + prop = APR_ARRAY_IDX(prop_changes, ctr, svn_prop_t *);
> + if (kind == svn_node_file)
> + {
> + editor->change_file_prop(file_baton, prop->name,
> + prop->value, pool);
> + }
> + else
> + {
> + editor->change_dir_prop(*dir_baton, prop->name,
> + prop->value, pool);
> + }
> + }
> + }
> }
>
> /* Finally, handle text mods (in that we need to open a file if it