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 <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.
>
> 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
- application/pgp-signature attachment: stored
Received on Fri Dec 8 21:58:35 2006