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

Re: Automatic upgrading of WC versions and the pain it causes

From: Max Bowsher <maxb1_at_ukf.net>
Date: 2006-04-11 14:06:13 CEST

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Malcolm Rowe wrote:
> On Mon, Apr 10, 2006 at 06:37:48PM +0100, Julian Foad wrote:
>> Julian Foad wrote:
>>> Max Bowsher wrote:
>>>> the status quo, but which someone who knows that they will be working
>>>> with multiple client versions can set to false, which will cause new
>>>> clients to exit with an error when accessing an old WC, rather than
>>>> silently upgrading it.
>>> I think that wouldn't solve the problem. Most people would only find
>>> out about the config option after they had encountered the problem of
>>> being unable to use their WC with a v1.3 client after a silent upgrade
>>> by a v1.4 client. Unless we provide a "downgrade" operation, they would
>>> be stuck.
>> Or maybe it's OK that they have to abandon that WC, set the config option,
>> and then can make a new WC and ... do what with it? Work in it with their
>> old client only? I don't see the point of that. What exactly are we
>> trying to achieve?
>
> Julian,
>
> I think Max is positioning this as primarily being a useful feature for
> SVN developers, not users. On my development machines, I typically
> install the latest release (e.g. 1.3.1, now), and I use that for
> development against both Subversion itself and my own projects.
>
> But while I'm testing svn-trunk, I occasionally do something like alias
> 'svn' to the compiled trunk version, particularly when I'm trying to
> compare the output of a regression test script between two different
> versions (typically the installed and built versions).
>
> The danger is that if I forget what I'm doing, I can easily run 'svn up'
> with the new (dev) client and make the working copy unusable with the
> installed svn. That's a pain, because the only way to recover is to
> re-checkout and diff/patch across to a pristine tree.
>
> I'd certainly like to proactively set such a setting so that I don't
> accidentally upgrade my working copies, but I don't think this is a
> typical end-user feature.
>
> In fact, a much easier way for _me_ to achieve this is to locally
> disable maybe_upgrade_format(), which I've just done. Is there any
> merit in making this a feature that the rest of the world can use?
> I don't think so. Perhaps I misunderstood what Max was suggesting.

No, you understood completely - thanks for the accurate elaboration,
Malcolm.

Your suggestion of a local mod to maybe_upgrade_format() is a partial
solution, though it carries with it the disadvantages of needing to keep
a lurking local mod around in working copies, and to continually avoid
accidentally committing or reverting it.

Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)

iD8DBQFEO5u1fFNSmcDyxYARApL5AKDPr7h7evFaISTghiSkKed0J0/5pQCfeZpI
JpFDdoifj/QmtiSvknvia1k=
=gZ1X
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 11 14:06:57 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.