[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Auto Upgrade Behavior

From: Stefan Sperling <stsp_at_elego.de>
Date: Sun, 26 Aug 2012 21:38:41 +0200

On Sun, Aug 26, 2012 at 02:29:45PM -0400, Greg Stein wrote:
> On Aug 25, 2012 8:08 PM, "Branko ─îibej" <brane_at_wandisco.com> wrote:
> >
> > On 26.08.2012 00:31, Greg Stein wrote:
> > > In the past, we used auto-upgrade because it "just worked". Most users
> > > don't need or want to worry about working copy formats. They just want
> svn
> > > to work.
> > >
> > > I don't think we should be making things more difficult for the
> majority in
> > > order to help a few users who use multiple clients. That is backwards.
> :-(
> >
> > Well, evidence appears to suggest that users who use multiple clients
> > are in fact the majority. Hearsay evidence, but that's the only kind I
> > see hereabouts.
>
> I'd call it a vocal minority. We've got millions of users. I can't see the
> majority using multiple clients. Nobody runs into issues using a single
> client, so there is no need to speak up.

I keep getting these complaints often. Mostly from users I personally
talk to during workshops, consulting, etc. Dunno how much of our user
population they represent. However it would be nice for me and them
if auto-upgrade was disabled by default. Because the problem would
be solved for them, and I could spend the time during my workshops
talking about more interesting stuff than why we auto-upgrade and
how to avoid the pitfalls. My desire to make this changed is based
on real user feedback. I wouldn't want to make it if these people
didn't request it.

That's where I come from. I'm trying to keep you happy too by adding
a global config knob you can enable. I know you don't like config
knobs either but I cannot think of any other solution to make both
us of happy. Do you have any suggestions other than keeping auto-upgrade
the default? Any chance of compromise?
Received on 2012-08-26 21:39:17 CEST

This is an archived mail posted to the Subversion Dev mailing list.