Re: [MERGE-TRACKING][PATCH] Make use of the svn_client_commit_item2_t->wcprop_changes member during commit of wc to repos copy

On Thu, 14 Dec 2006, Madan S. wrote:

> On Fri, 08 Dec 2006 06:29:25 +0530, Daniel Rall <dlr@collab.net> wrote:
>
> >On Thu, 07 Dec 2006, Madan S. wrote:
> >
> >>On Tue, 05 Dec 2006 23:45:32 +0530, Daniel Rall <dlr@collab.net> wrote:
> >>
> >>>On Tue, 05 Dec 2006, Madan S. wrote:
> >>>
> >>>>On Tue, 05 Dec 2006 00:42:39 +0530, Daniel Rall <dlr@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