On Thu, 2005-07-07 at 18:48, kfogel@collab.net wrote:
> Madan U Sreenivasan <madan@collab.net> writes:
> [snip]
> Ah, I see. What I meant to express is: there's a difference between
> revving an API to take a new struct2, and actually changing the code
> behind that API to *use* the new fields in struct2. I'm only
> proposing the former; I agree that changing the code behind those
> other APIs can happen in a separate stage.
Okay.
>
> > >
> [snip]
> So, I think to keep the patches manageable (i.e., reviewable :-) ),
> the stages could be:
>
> 1. Introduce svn_client_commit_info2_t and its constructor.
>
> 2. Rev all APIs that take svn_client_commit_info_t to take
> svn_client_commit_info2_t instead, but don't actually do
> anything with the new field yet. IOW, no behavioral change,
> just the introduction of a new type, in preparation for
> stages 3, 4, and 5 below.
>
> 3. In one RA layer, start using the new field.
>
> 4. Same for the next RA layer :-).
>
> 5. Same for yet another RA layer :-).
>
> And if you can think of other intermediate stages that ought to be
> inserted into this process, go ahead -- the above is just a rough
> outline.
I think the server side changes ( for all three layers) should go in
before 3. the rest of the changes could be for the client side.
But sadly, a new test case cant be used for any of the intermediate
steps. It will have to come only with the last piece of change. :(
Whatever it is, am determined to get this into 1.3. I'll do the best I
can...
>
> Best,
> -Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 8 11:44:48 2005