On Thu, Jun 28, 2012 at 5:45 AM, Branko Čibej <branko.ci...@wandisco.com> wrote: > On 28.06.2012 05:24, Hyrum K Wright wrote: >> On Wed, Jun 27, 2012 at 9:13 PM, Branko Čibej <branko.ci...@wandisco.com> >> wrote: >>> On 28.06.2012 01:32, Greg Stein wrote: >>>> On Wed, Jun 27, 2012 at 7:19 PM, Johan Corveleyn <jcor...@gmail.com> wrote: >>>>> On Tue, Jun 26, 2012 at 10:51 AM, Stefan Sperling <s...@elego.de> wrote: >>>>>> On Mon, Jun 25, 2012 at 07:51:59PM -0400, Greg Stein wrote: >>>>> ... >>>>>> I would prefer to by default keep working copy upgrades manual from now >>>>>> on. >>>>> +1, let's please keep it an explicit action by the user. >>>> Not sure about that. The user will type 'svn move' and not get the >>>> benefits. All the docs will say it *should* work, but it doesn't. >>> Not to mention feature-invariant updates, such as the new MD5 index. if >>> you don't have it, nothing breaks except your patience. :) >>> >>> Realistically, we've "taught" users and especially packagers to expect >>> silent updates (and have said loudly enough that 1.7/WC-NG is an >>> exception). I think we should just keep on doing that. >> Agreed, and I'm against the auto-update as well. > > Impedance mismatch? "Just keep on doing that" refers to automatic, > silent WC updates. :) > > I cited the MD5 index as a case where you definitely want the update to > be automatic.
Why should this be automatic? Just because users will definitely want (the benifit of) this index, doesn't mean it should be applied automatically at the next (write) action of some 1.8 client. (besides, I'm not even sure if this index is "definitely useful": IIUC it came about after Michael implemented dont-download-existing-pristines-with-old-md5sending-servers, so at least only 1.8 clients benifit from it. (unless that index is also useful for other use cases??)) What if adding this index takes a significant amount of time? Maybe the user has 2 million nodes in his working copy. I can imagine that it may take several minutes for this index to be created. I'd not want this to be automatic, behind my back, when I apply a simple 'propset' or something like that. > Now ... do we want to come up with a WC versioning scheme that allows > partially automatic updates (e.g., for changes that are > backward-compatible, such as adding a new index) but requiring manual > intervention for incompatible changes? Maybe. Doing this would certainly > make the code a lot more complex, not just the update part but also the > requirement for newer versions to support (and emulate all the quirks > of) older WC(-NG) formats. > > I'd want to think very, very carefully about doing this, maintaining > such compatibility is likely to be quite tricky. That's an interesting line of thought. But in that case, adding the index (through some automatic upgrade) could also be backported to 1.7. Still, it might be a problem if the auto-upgrade is not fast enough. IMHO, to have automatic upgrade, we need at least: 1. It has to be fast, and O(1) (unless we can guarantee that it will still be fast for working copies of a couple million nodes). 2. There needs to be a way to downgrade, to mitigate the problem of accidental upgrades. Like the change-svn-wc-format.py script [1], which could downgrade from 1.6 back to 1.5 and back to 1.4. If the upgrade is manual, having no way to downgrade is still an annoyance, but it's not a disaster (after all, the user manually decided to upgrade, so he better be prepared for it). Most svn users I talked to (my colleagues mostly) are very happy with the non-auto-upgrade of 1.7, and they see it as a real improvement. It makes the entire process less scary. With auto-upgrade, the following often happens (happened): - User has 3 svn clients: a commandline client, a GUI tool, and some plugin in his IDE. These all have their own release cycles, so not all of them may release 1.8 support at the same time. - Somehow one of the three tools got upgraded to version 1.8 (maybe even without much thought of the user ... maybe one of those software packages is auto-updated, or it nags the users every time at startup that a newer version is available, "please click here" etc ...). - He touches his working copy with the upgraded tool: working copy is upgraded. - Later, he fires up his IDE, and boom, "working copy format not supported, please upgrade your client" - "WTF? What happened?" - search the net - "Need to upgrade all clients ... #@$#%! svn ..." - search the net some more - "@#$%@#$%! I can't upgrade my IDE plugin because it's not release yet" - drink coffee and try to calm down - search the net some more to find a way to downgrade - if there is no (easily found) downgrade path: "@$%@#$$%#%#!!!! I HATE SVN, I should have switched to git long ago." (random blurb in frustration) - Even if this ends well, the user will have easily lost half a day, when maybe he urgently needs to do something under a deadline. So, if working copy formats are backward-incompatible, I would really like to keep it a manual upgrade choice :-). [1] http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/change-svn-wc-format.py -- Johan
