[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: To Greg Stein

From: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 18 Aug 2008 15:21:06 +0200

On Mon, Aug 18, 2008 at 08:41:36AM -0400, Karl Fogel wrote:
> Branko ─îibej <brane_at_xbc.nu> writes:
> > In general I dislike creating branches if the same work can be done on
> > trunk without affecting the rest of the code. And I don't see a
> > problem with including such work-in-progress code in a release.
> I'm with Brane on this one. We haven't actually had a problem yet, and
> IMHO it's unlikely that we will. The new wc-ng code is quite separate
> from the old wc code. And there's nothing wrong with shipping a
> work-in-progress, as long as it's clearly labeled as such: we did that
> with serf for several releases, IIRC.

Can we put new stuff into libsvn_wc2 then?
Current commits seem to go directly to libsvn_wc.

Mixing both versions in a single directory on the same branch
is a bit chaotic. libsvn_wc2 could either start out as an empty
directory, or as a copy of libsvn_wc, whichever is more convenient.

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.

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), 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.

> Regarding this:
> > a) It will make the end result of your effort much easier to review.
> With something like wc-ng, if we're not reviewing the commits as they
> come in, then it's hopeless anyway :-). Once finished, a change like
> that is much too big to review all at once.

Yes, that might be true. I've never reviewed a change this
large, so I'll just have to take your word for it :)

> (But just to play the other
> side: the bulk of the work is going into new files anyway, so if one
> wanted to review the "state of wc-ng" at any point, one would just look
> at those files.

This is inherently an argument in favour of a new directory, right?

Also, you seem to be addressing my point b) here, let me restate:
  Potential problems caused by changes entering trunk affects *all*
  feature branches, because they regularly sync with trunk

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.

> This will remain true until the work starts touching
> libsvn_client, and at that point, I'd much rather have it in trunk so we
> can keep the changes closely coordinated with old libsvn_wc maintenance.)

OK. This implies that we'd want to support both working copy libraries
for a while. If that's the case, then it's obvious that we will
need both of them in trunk at some point anyway.

> Let's please go with trunk until there's actually a problem. We can
> make a branch at any time if we need to.

So if the plan for wc-ng is:

- Add new code in libsvn_wc2 only.

- Tweak some existing files to enable compile-time/run-time
  switching between working copy library implementations.
  Add other small glue that might be needed, but do NOT add new
  features to existing code, and do NOT break existing code.

- Maintain both libraries for a while until the features
  of both libraries are on par, then deprecate and finally
  abandon libsvn_wc1.

... then I'm entirely OK with wc-ng development on trunk.


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:21:32 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.