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.
[snip]
Regards,
Madan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 14 05:53:21 2006