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

Re: Two svn_wc__db_t for single-db upgrade

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Fri, 27 Aug 2010 17:54:38 +0100

On Fri, 2010-08-27 at 12:46 -0400, Hyrum K. Wright wrote:
> On Fri, Aug 27, 2010 at 12:32 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> > On Fri, Aug 27, 2010 at 12:03:04PM -0400, Bob Archer wrote:
> >> I'm just talking as a user here... and not an svn dev... but do you
> >> really need to spend time on a 1.6 to 1.7 WC upgrade? Why not just
> >> have 1.7 not work with 1.7 WCs and tell the users they need to do a
> >> new checkout with 1.7. I mean... it might annoy some people, but I
> >> just think that the svn dev team would have "that much" more time to
> >> work on the real features/functionality of 1.7. I'm sure upgrades from
> >> WC-NG to WC-NG.Next will be much simpler and can/should still be
> >> included.
> >
> > You're not alone. I just raised the same question in the dev IRC channel.
> > There's value in the upgrade capability for users who have many and large
> > working copies. But I also think that we shouldn't let weeks of developer
> > time sink into this feature.
> >
> > I think that getting the simple upgrade cases working (no local mods,
> > no conflicts) would already make many people happy.
>
> We've already punted on some aspect of upgradability (no pending logs,
> for instance), and it may be valuable to shift the line further toward
> the common case. "You have local mods? Better commit 'em or make a
> patch before upgrading."

The trouble is, people often won't find out until some time after
they've upgraded, especially if it's a WC they aren't working on at the
moment and they try to come back to work on it some weeks later. And
for most people un-upgrading in order to do fix it isn't a practical
option.

- Julian
Received on 2010-08-27 18:55:23 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.