On Mon, Aug 18, 2008 at 6:21 AM, Stefan Sperling <stsp_at_elego.de> wrote:
>...
> Can we put new stuff into libsvn_wc2 then?
I thought about this, but decided that would be seriously painful.
Given our versioning guidelines, we have to support the WC API
*forever* in the 1.x series of releases. That means we'd have to
support wc1 forever. All that software out there using wc1 would have
to continue to function.
I'd much prefer to get rid of the wc1 code entirely.
>...
> Note that active development on libsvn_wc (version 1) is still
> happening, e.g. on the tree-conflicts branch and on Rui Guo's
> branch. So it would be nice to still have libsvn_wc in its
> current state around, without wc-ng changes creeping in.
> Especially on the tree-conflicts branch, which has also already
> touched a lot of the current libsvn_wc code.
My changes won't interfere with your work for at least a month, I'd
think. I've gotta code and test a whole new storage subsystem, and
that is completely orthogonal to other WC work.
Are there any changes which can safely be backported from the branch?
i.e. to minimize the delta between trunk/branch, and to get that work
"visible" to the wc-ng work.
> There's no doubt that tree-conflicts and wc-ng need to merge
> at some point (or rather, even better tree-conflict handling
> needs to be added to wc-ng),
Yes and yes.
> but right now wc-ng is in too
> early a state of development to even think about doing this.
> We might still end up shipping tree-conflict handling
> based on libsvn_wc1 before wc-ng is stable.
Well, I think wc1 gets revamped rather than deprecated. In terms of
whether t-c is based on wc1 or wc-ng... I think we'll just have to see
how it goes.
And it looks like I'm going to need to do a diff between trunk/branch
and see what you've done so far.
>...
> Yes, that might be true. I've never reviewed a change this
> large, so I'll just have to take your word for it :)
hehe... yeah, it is true. Anything more than 1000 lines is effectively
unreviewable. wc-ng will be an order of magnitude larger than that.
>...
> Given that most of the work is done in new files, there's no problem
> with wc-ng work affecting other branches. But if that turns out not
> to be the case, I'd strongly favour branching.
Let's see where things are when I get the storage subsystem done. Your
work will definitely be much further along, and I'll hopefully have
more information about the "next steps" after the subsystem is in
place.
>...
> - Maintain both libraries for a while until the features
> of both libraries are on par, then deprecate and finally
> abandon libsvn_wc1.
This is the key part. We could deprecate wc1, but I think we'd always
have to fix bugs in it. And we could never truly abandon it
unless/until we shift to 2.0.
(and don't get me started on a 2.0 discussion :-P )
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-18 15:38:22 CEST