RE: Two svn_wc__db_t for single-db upgrade

> On Fri, Aug 27, 2010 at 05:54:38PM +0100, Julian Foad wrote:
> > 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.
>
> That's reality, but not exactly best-practice.
> If your local mods have been lying in the working copy for weeks,
> they're probably not that important. If it's important, it should
> be checked in, or backed up in patch, or something.
>
> But yes, I can see how communicating this problem in a large
> organisation can be hard. The admin installs the new software,
> working copies stop working, and weeks later they still get support
> calls about subversion being broken.
>
> Still, we should dicide on a reasonable feature set for 1.6->1.7
> working
> copy upgrades, and try not to get carried away by the huge amount
> of
> complicated details of this problem.
>
> Stefan

Is there any way the 1.6 revert/cleanup/patch stuff can be left in 1.7? So if you have a 1.6 repo those are the only commands you can use on it? Or are there just to many dependencies?

I do agree, if you have pending changes siting in a WC for weeks.. you probably don't need em. ;)

Or, if not, the user can do a new checkout, and then use a compare tool to apply your pending changes to your new WC. This means, don't auto-update a WC that has pending changes in it.

BOb
  
Received on 2010-08-27 19:21:10 CEST