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

Re: initial thoughts on issue #3818: fix handling of externals in wc-ng

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 23 Feb 2011 20:12:36 +0100

On Wed, Feb 23, 2011 at 12:46:44PM -0600, Hyrum K Wright wrote:
> On Wed, Feb 23, 2011 at 12:26 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> > We need to preserve 1.6 semantics of how operations affect externals.
>
> Why? People have been wanting to commit across externals and working
> copies for a *long* time. Putting them all in the same WC gives us
> this functionality for free (as well as other currently-not-atomic
> operations). Perserving these same limiting 1.6 semantics is
> something of a hard sell.

I would argue that we need to keep the existing behaviour working,
preferably as the default. If people want different behaviour, e.g. commit
across externals, it's possible to make that happen regardless of which
design we use to represent externals internally of libsvn_wc.

I think you're missing an important difference between switched paths
and externals, just like we did with file externals.

Externals can come from a different repository, while switched paths cannot.

At the UI level, a switch can be used as a shortcut to avoid a long checkout,
or to quickly commit a set of local changes to a new temporary branch in
case that aren't yet suitable for commit to the branch the working copy
originally came from. A switch is temporary and local to the working copy.

This is very different to the 'modules' concept externals implement.
Participants in introductory SVN courses I give are usually much more
interested in svn:externals than in svn switch. They immediately want
to use externals for very different use cases (e.g. pulling meta-project
components together from different repositories, or even for managing
variants of their products). An external is used as a permanent reference
to possibly foreign repositories.

I think it's a good idea to keep these concepts entirely separate.

> > If we cannot easily tell the difference between a switched path
> > and an external, that is bad design, IMHO, and will lead to problems
> > down the road just like we had with file externals in 1.6.
> > Let's not repeat that mistake. Externals are special and need their own,
> > unique, representation in our design.
>
> I submit that this may not be true. They have given us so many
> headaches precisely because we claim they are special. Treating
> externals as switched nodes will eliminate a number of these special
> cases.

It's entirely possible that people might want Subversion to treat external
references from foreign repositories different than switched paths (which
by definition come from the same repository as the rest of the working copy).

The most obvious example is that they might want to auto-commit to
switched paths, but not to foreign repositories referenced by externals.
For instance, say I don't have commit access to the repository the
external came from. Should svn try to commit to it, and fail every time,
with no way to turn this off? I would say "no".

> (And while I think this is a good discussion to have, I'm hopeful it
> doesn't lead to further delays in shipping 1.7.)

I think it's very good to have this discussion now, whether or not
it delays the release. It should probably have happened sooner :)
We cannot ship 1.7 with a broken externals implementation anyway.
Received on 2011-02-23 20:13:11 CET

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.