Re: maunal WC upgrade test fallout

[Branko Čibej <br...@wandisco.com>]

On 02.11.2012 04:34, Stefan Sperling wrote:
> On Fri, Nov 02, 2012 at 02:59:10AM +0100, Stefan Sperling wrote:
>> I went ahead and disabled auto-upgrades in r1404856.

During the SVN Live conferences I asked people, privately, about their
opinion on automatic vs. manual upgrades. The overwhelming response was
that they wait for all the clients to catch up before upgrading. Given
these results, my opinion leans towards leaving auto-upgrades on, but
spending more effort on documenting that there's no way back.

Regarding read-only access to old-format WCs: I studied the
implementation and came to the conclusion that it's not worth the
effort. There's no clear connection between read-only operations and
actually not modifying the wc.db, so unless someone wants to refactor
the WC code (and all the bits that rely on it) again, this is not going
to happen.

> This caused some test fallout which should be mostly fixed now.
> The main issue was that I temporarily broke most of the tests
> when run within a 1.7 WC.
>
> The only remaining issue I'm aware of is that upgrade_tests.py
> ends up upgrading the parent WC during the test run. I'm not quite
> sure yet what we can do to prevent that.

Sounds like a bug in either the test code, or the bits of wc-ng that try
to determine the wc root...

-- Brane

Re: maunal WC upgrade test fallout

[Ben Reser <be...@reser.org>]

On Fri, Nov 2, 2012 at 6:07 AM, Branko Čibej <br...@wandisco.com> wrote:
> During the SVN Live conferences I asked people, privately, about their
> opinion on automatic vs. manual upgrades. The overwhelming response was
> that they wait for all the clients to catch up before upgrading. Given
> these results, my opinion leans towards leaving auto-upgrades on, but
> spending more effort on documenting that there's no way back.

The impression I got was that the following two statements are true:

People would prefer auto-upgrading over a manual upgrade.
People had been negatively impacted due to auto-upgrades in the past.

While these two statements seem contradictory.  Ultimately, what
people really want is to just not worry about it at all.

But that's not really possible.  Especially in light of your following
statement:

> Regarding read-only access to old-format WCs: I studied the
> implementation and came to the conclusion that it's not worth the
> effort. There's no clear connection between read-only operations and
> actually not modifying the wc.db, so unless someone wants to refactor
> the WC code (and all the bits that rely on it) again, this is not going
> to happen.

My inclination is to use manual upgrades:

1) With auto-upgrades we can put warnings all over the place but if
the end user never reads it there's nothing we can do to help them.
So many of our users don't see our website or documentation, so the
only place we can really drive messages to them is through the error
messages we display.  By requiring the manual upgrade when you try to
use the working copy with a newer client we can display a message
explaining the issues.  It's not worry free for the user but at least
we have the opportunity to educate them.

2) This is a pretty weak argument but it seems really odd to me to
have an upgrade command in the client that's only used to go from 1.6
-> 1.7.

Re: maunal WC upgrade test fallout

["C. Michael Pilato" <cm...@collab.net>]

On 11/02/2012 01:15 PM, Branko Čibej wrote:
> On 02.11.2012 15:15, C. Michael Pilato wrote:
>> What would have been more interesting to know is how they felt about the
>> required one-time manual 'svn upgrade' in 1.7 -- was it troublesome for
>> their processes?
> 
> I got exactly one response about the 1.7 upgrade, and it went like this:
> "checked out new working copies because the upgrade didn't work for us."
> Which doesn't really help all that much in retrospect.

No, other than perhaps affirm what Mark Phippard said in earlier iterations
of this discussion topic about how the complaints he heard were generally
not of the "boo, manual upgrade is a pain" variety, but more like, "boo, the
upgrade failed in my scenario".

> Do we want to delay 1.8 until we /can/ do backward-compatible read-only
> operations? I somehow don't think so.

No.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

Re: maunal WC upgrade test fallout

[Branko Čibej <br...@wandisco.com>]

On 02.11.2012 15:15, C. Michael Pilato wrote:
> On 11/02/2012 09:07 AM, Branko Čibej wrote:
>> On 02.11.2012 04:34, Stefan Sperling wrote:
>>> On Fri, Nov 02, 2012 at 02:59:10AM +0100, Stefan Sperling wrote:
>>>> I went ahead and disabled auto-upgrades in r1404856.
>> During the SVN Live conferences I asked people, privately, about their
>> opinion on automatic vs. manual upgrades. The overwhelming response was
>> that they wait for all the clients to catch up before upgrading. Given
>> these results, my opinion leans towards leaving auto-upgrades on, but
>> spending more effort on documenting that there's no way back.
> I'm not convinced that your results (as presented, at least) actually tell
> us anything other than that our more-aware users already expect
> auto-upgrading to occur and to screw them over, so they avoid it.  That's
> seems to fall quite a bit short of a validation of the auto-upgrade
> approach!  ;-)

True.

> What would have been more interesting to know is how they felt about the
> required one-time manual 'svn upgrade' in 1.7 -- was it troublesome for
> their processes?

I got exactly one response about the 1.7 upgrade, and it went like this:
"checked out new working copies because the upgrade didn't work for us."
Which doesn't really help all that much in retrospect.

>   If our more-aware users already work to upgrade their
> software in concert, and have no concerns with the manual 'svn upgrade'
> step, then our auto-or-not-upgrade decision is a moot point for them.  Their
> opinion is, therefore, disinteresting.
>
> What remains, then, are our less-aware users, who'll -- if we decide to
> continue auto-upgrading -- will wind up fussing with all the inherent
> problems of mixed-pedigree Subversion clients and for whom extra
> documentation is pointless (because if they read *that*, they'd be more
> aware!).  :-)

The real problem I see with manual upgrades is that you can do /nothing/
with the new client until you've upgraded your working copy. That's a
regression from what we did up to and including 1.6, but it's not easy
to fix because the WC-NG design does not really admit the concept of
read-only operations. Of course, in this respect automatic upgrades are
no better, just the other way around.

Do we want to delay 1.8 until we /can/ do backward-compatible read-only
operations? I somehow don't think so.

-- Brane

Re: maunal WC upgrade test fallout

["C. Michael Pilato" <cm...@collab.net>]

On 11/02/2012 09:07 AM, Branko Čibej wrote:
> On 02.11.2012 04:34, Stefan Sperling wrote:
>> On Fri, Nov 02, 2012 at 02:59:10AM +0100, Stefan Sperling wrote:
>>> I went ahead and disabled auto-upgrades in r1404856.
> 
> During the SVN Live conferences I asked people, privately, about their
> opinion on automatic vs. manual upgrades. The overwhelming response was
> that they wait for all the clients to catch up before upgrading. Given
> these results, my opinion leans towards leaving auto-upgrades on, but
> spending more effort on documenting that there's no way back.

I'm not convinced that your results (as presented, at least) actually tell
us anything other than that our more-aware users already expect
auto-upgrading to occur and to screw them over, so they avoid it.  That's
seems to fall quite a bit short of a validation of the auto-upgrade
approach!  ;-)

What would have been more interesting to know is how they felt about the
required one-time manual 'svn upgrade' in 1.7 -- was it troublesome for
their processes?  If our more-aware users already work to upgrade their
software in concert, and have no concerns with the manual 'svn upgrade'
step, then our auto-or-not-upgrade decision is a moot point for them.  Their
opinion is, therefore, disinteresting.

What remains, then, are our less-aware users, who'll -- if we decide to
continue auto-upgrading -- will wind up fussing with all the inherent
problems of mixed-pedigree Subversion clients and for whom extra
documentation is pointless (because if they read *that*, they'd be more
aware!).  :-)

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development