"C. Michael Pilato" <cmpilato@collab.net> writes:
> > I don't care much whether we do the work on a branch or on the trunk
> > with a disabling #ifdef. One requires more merging work and one
> > potentially puts vestigial code into releases (or requires us to remove
> > code in dist.sh, which some might find distasteful), but neither cost is
> > very high.
>
> I prefer this work be done on a branch. Merging isn't scary,
> navigating around #ifdefs is annoying, and doing magic code removal
> tricks in our distribution script is silly.
I think you might be overestimating the complexity here.
First: the abstraction work (independent of the new backend) is
destined for trunk as soon as possible, right?
If that's so, then once the abstraction is in place, there should only
be one or two spots requiring a conditional about what backend to use.
There should be *no* #ifdefs to navigate. (And we should feel free to
toss my off-the-cuff proposal to temporarily disable the new backend
at compile time, for releases that happen while it's under
development, if it gets in the way at all.) The new code will be in
new files; to avoid the code, just don't open those files :-).
No "magic code removal trick" was ever proposed. I think you may have
something different in mind from what I was talking about (and even
what I was talking about isn't truly necessary).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 30 20:47:50 2004