In my experience (I work in finance/banking sector), the issue with WC
upgrades tend to come from reliance on multiple tools:
cmd line - for scripts
IDE plugin - for development
plugin for the file explorer - for task that are quicker done outside IDE
Continuous Integration plugin
in "enterprise" environments, I know of, the latest versions of svn
based tools don't become available at the same time. As a result it
tends to hit new joiners (who just get latest software installed) or
when new version of IDE is out. What helps the most, is when software
gives clear error message in that case. Example from real life:
1.7 svn cmd line package (custom built) installed binaries in a
location that were earlier in the $PATH than binaries from the 1.6
package. So when 1.7 was installed it became default without anyone
realizing. Issue cropped up when CI integration build that used a mix
of svn cmd line and SvnKit started breaking (this was at least a week
after the 1.7 was installed). NOTE: Auto upgrade was not even
relevant as 1.7 was responsible for performing the "checkout" command.
Having the right message, allowed to quickly identify the cause and
fix the issue but putting 1.6 binaries as default.
In my experience, having to do an explicit operation to change state
leads to less issues in the "enterprise" setup, because that decision
has to be made by someone, rather being a side effect of another
decision which one might not be aware of.
Hope this background info helps,
Vladimir
On Mon, Aug 27, 2012 at 4: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.
>
> Would that work for you?
>
> Cheers,
> -g
>
> On Aug 26, 2012 3:38 PM, "Stefan Sperling" <stsp_at_elego.de> wrote:
>>
>> 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-27 14:46:23 CEST