On Mon, Jun 25, 2012 at 07:51:59PM -0400, Greg Stein wrote:
> Historically, whenever we have changed the format, then the working
> copy is auto-upgraded the first time we (re)wrote the .svn/entries
> file. The upgrade was invisible and fast, so it Just Happened. At that
> moment, older versions of Subversion could no longer use the working
> copy.
>
> The 1.7 upgrade was considered too time-consuming and invasive to
> continue with the auto-upgrade mechanism. We required people to
> manually upgrade the working copy.
I would prefer to by default keep working copy upgrades manual from now on.
A silent auto-upgrade generates many problems and help desk cases in large
organisations. I've seen people complain about "Eclipse stopped working!!!!"
when what really happened is that JavaHL suddenly used a different set of
Subversion libs and eclipse dropped all working copies from the GUI. Which
can take them a day or so to figure out -- especially if the user who ran
into the problem doesn't have a good understanding about what's really
happening beneath the shiny icons in the GUI, which is more often the case
than not because these GUIs are designed with the goal of hiding complexity.
This and other issues are likely to happen when people mix TortoiseSVN and
eclipse, which is a common setup in many organisations I've walked into.
It's much better if they get an error saying "your working copy is too old,
please upgrade". They can handle that because they're being told what the
problem is.
We could add a config switch that says "please auto-upgrade" for those
who really need it (i.e. folks who have a million old and rotten
working copies which they may some day want to keep using with some
newer svn release without running 'svn upgrade' on each).
Received on 2012-06-26 10:52:04 CEST