On Thu, 14 Dec 2006, Madan S. wrote:
> On Fri, 08 Dec 2006 06:29:25 +0530, Daniel Rall <email@example.com> wrote:
> >On Thu, 07 Dec 2006, Madan S. wrote:
> >>On Tue, 05 Dec 2006 23:45:32 +0530, Daniel Rall <firstname.lastname@example.org> wrote:
> >>>On Tue, 05 Dec 2006, Madan S. wrote:
> >>>>On Tue, 05 Dec 2006 00:42:39 +0530, Daniel Rall <email@example.com>
> >>>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
> >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
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. :)
Received on Tue Dec 19 02:57:38 2006
- application/pgp-signature attachment: stored