> 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
