On Mon, Aug 27, 2012 at 10:47 AM, Greg Stein <gstein_at_gmail.com> wrote:
> I'm thinking that we ought to continue auto-upgrade for the masses,
> especially given Bert's input. Much as I dislike config knobs, it seems
> prudent to introduce a "disable auto-upgrade" option for large, multi-client
> shops. IMO, you're tending towards sophisticated if you use more than one
> svn client. In turn, I further believe that implies minority. Let's give
> those users, who understand the issue, an option, and give simplicity to all
> the rest.
As I challenged Bert's input, it seems only right that I also
challenge your mail :-).
It's not at all clear to me, from Bert's statements, that the increase
of upgrade complaints is related to the non-automaticness. Besides,
users of AnkhSVN are lucky, because it so closely follows the main
release (as does TSVN) so the multi-tool situation poses less of a
problem, but not all users are so lucky. Some tools adopt the new
releases more slowly, which poses problems in multi-tool environments.
About multi-client setups being sophisticated and even the minority: I
must honestly say that I don't know. In my environment it's the norm
(IDE plugin, and then either TSVN or commandline or both (because the
IDE plugin doesn't do everything)), but that's only 50 developers :-).
I always tend to think that a lot of developers have at least two
clients: their IDE plugin and some other tool. But that may be
incorrect, biased, ... I don't really know.
Anyway, I can manage either way. It's also largely a matter of
internal communication and education.
In any case I'd like to remind that, IMHO, auto-upgrade requires that
there also be a way to downgrade (downgrade script like there was
before 1.7). At least then, if a user is surprised by the auto-upgrade
and doesn't feel like upgrading his other client(s), he still has a
Received on 2012-08-27 14:20:44 CEST