[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: Branko ─îibej <brane_at_wandisco.com>
Date: Sat, 25 Aug 2012 11:14:57 +0200

On 25.08.2012 11:00, Stefan Sperling wrote:
> On Fri, Aug 24, 2012 at 05:21:09PM -0400, Paul Burba wrote:
>> Currently trunk tries to auto-upgrade the WC pretty much every chance
>> it gets, even when the cwd is an unversioned directory within a WC.
>> I've been wondering if this is really such a good idea -- it's been
>> quite noticeable, in an annoying way, while working on the
>> inheritable-props branch.
>> What happens is this:
>> 1) I check out the iprops branch with a Subversion 1.7.6 client (WC
>> format 29) to C:\SVN\src-trunk-2)
>> 2) I build the iprops branch, which is using WC format 30.
>> 3) From the root of my iprop WC I run the test suite. The first
>> checkout done as part of the test auto-upgrades the WC rooted at
>> C:\SVN\src-trunk-2 to format 30, even though the cwd of the checkout
>> is an unversioned directory
>> (C:\SVN\src-trunk-2\Debug\subversion\tests\cmdline) and the checkout
>> target is below that
>> (C:\SVN\src-trunk-2\Debug\subversion\tests\cmdline\svn-test-work\working_copies\basic_tests-1).
>> Pretty much any command with an unversioned directory under an older
>> format WC root will attempt to upgrade that root.
>> Probably not a huge problem for anyone who is not a Subversion
>> developer, but it's something we might want to keep in mind as we bump
>> the WC format in the future.
> Can't we just disable auto-upgrade and add a config option to enable
> it for those who really want it?
> That would be the best behaviour IMO, also for our users.
> If there is concensus that this is a good idea I'll make it happen.

After all the discussions about this topic, I've slowly come to the
conclusion that this is the best option. The only trouble I see is in
properly supporting older WC formats, because as far as I can see,
there's not much infrastructure in place for that.

Unless you think that it's OK for newer SVN releases to simply not work
on old working copies?

Certified & Supported Apache Subversion Downloads:
Received on 2012-08-25 11:15:52 CEST

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