You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Max Bowsher <ma...@ukf.net> on 2006/04/09 14:31:58 UTC
Automatic upgrading of WC versions and the pain it causes
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At the moment, svn 1.4 will automatically upgrade WCs when it first
touches them, after which they become incompatible with svn 1.3.x and
earlier.
There has been a strong feeling that to require explicit upgrading of
WCs is too wasteful of average user's time.
I don't necessarily agree with that, but perhaps that's because I'm
unable to think myself back into an average user's point-of-view.
In any case, I've been annoyed to find that I've accidentally upgraded
WCs I didn't want to, and so have a proposal:
I would like to create a new configuration file setting,
config.[miscellany].allow-wc-upgrade, which defaults to yes, preserving
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.
Acceptable?
Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
iD8DBQFEORrefFNSmcDyxYARAggUAKDUjuwRp1Jad7qlIPg3EPWEY284XACdF/DM
IbB9/IfASNQn6epRQSfo768=
=VjHG
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Automatic upgrading of WC versions and the pain it causes
Posted by Peter Samuelson <pe...@p12n.org>.
[Max Bowsher]
> I would like to create a new configuration file setting,
> config.[miscellany].allow-wc-upgrade, which defaults to yes,
> preserving 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.
Well, if it is convenient, I'd suggest making it exit only if it would
have to *write* to the repository metadata. Obviously you need to
maintain the ability to read old metadata (to perform the upgrade), so
it doesn't seem like it would be much of a burden to continue to
support read-only access.
Also, if someone sets allow-wc-upgrade to no, I hope you're also
planning to support a way to tell the client to upgrade the repository,
be that a '--force'-like flag or a subcommand.
Re: Automatic upgrading of WC versions and the pain it causes
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Tue, Apr 11, 2006 at 12:01:43PM -0700, Justin Erenkrantz wrote:
> On 4/11/06, Malcolm Rowe <ma...@farside.org.uk> wrote:
> > Er, no. The cleanup comment was just that when the development version
> > errors out (instead of borking the working copy), it exits with a lock on
> > the wc, which isn't strictly necessary (it hasn't actually modified the
> > wc, so it could remove the lock). But it should be a rare occurrence,
> > so I don't see that as a big problem.
>
> If you're intending to use this 'not-WC-upgradable' version, doesn't
> it mean that everytime you see this error that the WC will no longer
> be usable? You won't be able to run cleanup (or any read-only ops)
> with the version you have because it'll need to open the WC, right?
That's true, but it's not a problem. Yes, if I try to run 'svn up' using
a trunk svn on my svn-trunk working copy, it will error and leave a wc
lock around, so I won't be able to access it with a trunk svn until I
clean up the lock (and as you correctly point out, I can't do that with
the trunk svn).
But the reason that I don't want to use a trunk svn on my working copy
is because I've got a 1.3.1 svn installed that I use for my day-to-day
use, and running a write operation on my (format 4) working copy was a
mistake in the first place.
So I unalias svn or fix my PATH (i.e. fix whatever caused me to make
the mistake in the first place), and just run 'svn cleanup' using my
installed 1.3.1 client and continue with my life (versus: work out how
to downgrade my working copy from format 6 to format 4).
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Automatic upgrading of WC versions and the pain it causes
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/11/06, Malcolm Rowe <ma...@farside.org.uk> wrote:
> Er, no. The cleanup comment was just that when the development version
> errors out (instead of borking the working copy), it exits with a lock on
> the wc, which isn't strictly necessary (it hasn't actually modified the
> wc, so it could remove the lock). But it should be a rare occurrence,
> so I don't see that as a big problem.
If you're intending to use this 'not-WC-upgradable' version, doesn't
it mean that everytime you see this error that the WC will no longer
be usable? You won't be able to run cleanup (or any read-only ops)
with the version you have because it'll need to open the WC, right?
-- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Automatic upgrading of WC versions and the pain it causes
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Tue, Apr 11, 2006 at 09:43:23AM -0700, Justin Erenkrantz wrote:
> On 4/11/06, Malcolm Rowe <ma...@farside.org.uk> wrote:
> > I like that idea. How about the attached?
> >
> > The only disadvantage of doing it this way is that the application doesn't
> > clean up the working copy lock when it exits, which arguably it could.
> > But I don't see a real problem with that.
>
> How would you upgrade the WC then?
>
You don't. Or at least, not using the client you've compiled in your
development tree. Bear in mind that this is supposed to help people
who have separate development and installed versions of Subversion - the
working copy will be upgraded only when you update your installed version.
> If it's via 'cleanup', well, if you leave a lock behind, then your WC
> gets upgraded... -- justin
>
Er, no. The cleanup comment was just that when the development version
errors out (instead of borking the working copy), it exits with a lock on
the wc, which isn't strictly necessary (it hasn't actually modified the
wc, so it could remove the lock). But it should be a rare occurrence,
so I don't see that as a big problem.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Automatic upgrading of WC versions and the pain it causes
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/11/06, Malcolm Rowe <ma...@farside.org.uk> wrote:
> I like that idea. How about the attached?
>
> The only disadvantage of doing it this way is that the application doesn't
> clean up the working copy lock when it exits, which arguably it could.
> But I don't see a real problem with that.
How would you upgrade the WC then?
If it's via 'cleanup', well, if you leave a lock behind, then your WC
gets upgraded... -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Automatic upgrading of WC versions and the pain it causes
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Tue, Apr 11, 2006 at 02:24:22PM +0200, Peter N. Lundblad wrote:
> Max Bowsher writes:
> > 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.
>
> What about adding a configure time option for this? It seems to be
> most interesting for developers anyway, and it avoids a confusing
> option for users.
>
I like that idea. How about the attached?
The only disadvantage of doing it this way is that the application doesn't
clean up the working copy lock when it exits, which arguably it could.
But I don't see a real problem with that.
[[[
Provide a configure-time option to disable automatic working copy format
upgrades.
* configure.in
Add the --disable-wc-upgrade option.
* subversion/libsvn_wc/lock.c
(maybe_upgrade_format): If SVN_DISABLE_WC_UPGRADE is set, replace the
implementation of this function with a version that refuses to update
working copies instead.
]]]
Regards,
Malcolm
Re: Automatic upgrading of WC versions and the pain it causes
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Wed, Apr 12, 2006 at 09:41:19AM +0100, Malcolm Rowe wrote:
> Okay, sounds like a configure option isn't necessary. Anyone have any
> objection to my checking in the libsvn_wc/lock.c part of the patch
> I posted?
>
See r19408.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Automatic upgrading of WC versions and the pain it causes
Posted by David James <dj...@collab.net>.
On 4/12/06, Malcolm Rowe <ma...@farside.org.uk> wrote:
> Okay, sounds like a configure option isn't necessary. Anyone have any
> objection to my checking in the libsvn_wc/lock.c part of the patch
> I posted?
Looks good.
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Automatic upgrading of WC versions and the pain it causes
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Tue, Apr 11, 2006 at 09:09:06PM +0100, Philip Martin wrote:
> Malcolm Rowe <ma...@farside.org.uk> writes:
> > which helpfully captures all the
> > configure options, but not the environment variables.
>
> Use 'configure CFLAGS=-DSVN_XXX' and it's a configure argument, not an
> environment variable, and thus it's sticky.
>
Thank you, I did not know that. (For some reason, I thought it'd act
as an override or something).
> > unlike the debugging options Philip mentions - or is it just Max and I
> > who are prone to accidental wc upgrades?
>
> I've not had a problem so far.
>
Okay, sounds like a configure option isn't necessary. Anyone have any
objection to my checking in the libsvn_wc/lock.c part of the patch
I posted?
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Automatic upgrading of WC versions and the pain it causes
Posted by Philip Martin <ph...@codematters.co.uk>.
Malcolm Rowe <ma...@farside.org.uk> writes:
> The advantage of a configure option are:
>
> It's sticky. I run configure directly very rarely - more frequently,
> I reconfigure by running config.nice,
Me too.
> which helpfully captures all the
> configure options, but not the environment variables.
Use 'configure CFLAGS=-DSVN_XXX' and it's a configure argument, not an
environment variable, and thus it's sticky.
> It's discoverable. I must admit that I've been assuming that this is
> something that most people here would want to use on a day-to-day basis,
I would not use it.
> unlike the debugging options Philip mentions - or is it just Max and I
> who are prone to accidental wc upgrades?
I've not had a problem so far.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Automatic upgrading of WC versions and the pain it causes
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Tue, Apr 11, 2006 at 08:30:53PM +0200, Peter N. Lundblad wrote:
> Philip Martin writes:
> > No need for an option, just use CFLAGS=-DSVN_XXX when running
> > configure or EXTRA_CFLAGS=-DSVN_XXX when running make, see
> > SVN_DEBUG_ERROR, SVN_FS__TRAIL_DEBUG, etc. for example.
> >
>
> Yeah, that's even less visible to people who shouldn't care:-)
>
The advantage of a configure option are:
It's sticky. I run configure directly very rarely - more frequently,
I reconfigure by running config.nice, which helpfully captures all the
configure options, but not the environment variables.
It's discoverable. I must admit that I've been assuming that this is
something that most people here would want to use on a day-to-day basis,
unlike the debugging options Philip mentions - or is it just Max and I
who are prone to accidental wc upgrades?
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Automatic upgrading of WC versions and the pain it causes
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
Philip Martin writes:
> "Peter N. Lundblad" <pe...@famlundblad.se> writes:
>
> No need for an option, just use CFLAGS=-DSVN_XXX when running
> configure or EXTRA_CFLAGS=-DSVN_XXX when running make, see
> SVN_DEBUG_ERROR, SVN_FS__TRAIL_DEBUG, etc. for example.
>
Yeah, that's even less visible to people who shouldn't care:-)
I can live with either of these; I'm about -0.1 to a runtime config
option until someone explains why this is useful to an end user (and
provides some evidence that the end user will actually know of the
option before needing it:-).
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Automatic upgrading of WC versions and the pain it causes
Posted by Philip Martin <ph...@codematters.co.uk>.
"Peter N. Lundblad" <pe...@famlundblad.se> writes:
> Max Bowsher writes:
> > 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.
>
> What about adding a configure time option for this? It seems to be
> most interesting for developers anyway, and it avoids a confusing
> option for users.
No need for an option, just use CFLAGS=-DSVN_XXX when running
configure or EXTRA_CFLAGS=-DSVN_XXX when running make, see
SVN_DEBUG_ERROR, SVN_FS__TRAIL_DEBUG, etc. for example.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Automatic upgrading of WC versions and the pain it causes
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
Max Bowsher writes:
> 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.
What about adding a configure time option for this? It seems to be
most interesting for developers anyway, and it avoids a confusing
option for users.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Automatic upgrading of WC versions and the pain it causes
Posted by Max Bowsher <ma...@ukf.net>.
-----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
Re: Automatic upgrading of WC versions and the pain it causes
Posted by Malcolm Rowe <ma...@farside.org.uk>.
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.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Automatic upgrading of WC versions and the pain it causes
Posted by Julian Foad <ju...@btopenworld.com>.
Julian Foad wrote:
> Max Bowsher wrote:
>
>> I would like to create a new configuration file setting,
>> config.[miscellany].allow-wc-upgrade, which defaults to yes, preserving
>> 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? Should svn v1.4 be able to work with old WCs without upgrading them,
so that it can be used in parallel with an older GUI client (for example)? If
so, should it have full functionality or just read-only ability?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Automatic upgrading of WC versions and the pain it causes
Posted by Julian Foad <ju...@btopenworld.com>.
Max Bowsher wrote:
> At the moment, svn 1.4 will automatically upgrade WCs when it first
> touches them, after which they become incompatible with svn 1.3.x and
> earlier.
[...]
> In any case, I've been annoyed to find that I've accidentally upgraded
> WCs I didn't want to, and so have a proposal:
>
> I would like to create a new configuration file setting,
> config.[miscellany].allow-wc-upgrade, which defaults to yes, preserving
> 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.
>
> Acceptable?
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.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org