You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Simon <tz...@snkmail.com> on 2010/04/13 01:17:35 UTC
Automatic upgrade of wc format annoying on shared drives
We have work directories shared between many physical machines here (via sshfs, nfs, etc). We also use subversion as our configuration management system for source files.
When a newer client ends up on on of the work machines, it automatically (and silently) upgrades the wc metadata format of any working copies it touches. This prevents future access of any of the other clients until the working copies are manually downgraded (such as via: http://subversion.apache.org/faq.html#working-copy-format-change ).
This is quite annoying.
I think correct behaviour here is that the client should at least prompt the user to ask if it should upgrade the wc metadata format before messing with the working copy.
Failing that, is there some way of locking a working copy to a particular version of the wc metadata format.
Regards,
Simon
RE: Automatic upgrade of wc format annoying on shared drives
Posted by Jeremy Mordkoff <jl...@ZeeVee.Com>.
Jeremy Mordkoff wrote:
>>> I second that. I support fedora 7, 8, 9, 10, 11 (and soon 12),
> various
>>> ubuntu releases, plus windows XP, Vista, and Win7, and Mac OS 10.4,
>>> 10.5. When one of them upgrades, it causes me to scramble to build
> and
>>> deploy upgrades to the others.
>>>
>> But working copies should really be disposable. As long as you keep
> your
>> changes commited, if the format is a problem for a different client,
> just delete
>> it and let that client build what it wants.
>>
>
> Our product also supports that variety of platforms. I request that
> changes be tested on all platforms before the changes are committed.
> That requires the engineer to either use a project branch or access a
> view from multiple machines. Since some machines are shared, sometimes
> views get inadvertently upgraded.
>
And you are not concerned that some uncommitted change in this working copy
might be the thing that makes all your tests pass? I like to make 'svn
checkout' or 'update' the only means to get the source to the testing platforms
to ensure that the test is of a reproducible state.
--
Les Mikesell
lesmikesell@gmail.com
Absolutely. We use svn:ignore and svn status to make it easy to make sure such
things don't happen. And then we also have a QA group (this is for developer
testing). I can't say they always adhere to it, but that can't say that
their tools don't support it.
jlm
Re: Automatic upgrade of wc format annoying on shared drives
Posted by Les Mikesell <le...@gmail.com>.
Jeremy Mordkoff wrote:
>>> I second that. I support fedora 7, 8, 9, 10, 11 (and soon 12),
> various
>>> ubuntu releases, plus windows XP, Vista, and Win7, and Mac OS 10.4,
>>> 10.5. When one of them upgrades, it causes me to scramble to build
> and
>>> deploy upgrades to the others.
>>>
>> But working copies should really be disposable. As long as you keep
> your
>> changes commited, if the format is a problem for a different client,
> just delete
>> it and let that client build what it wants.
>>
>
> Our product also supports that variety of platforms. I request that
> changes be tested on all platforms before the changes are committed.
> That requires the engineer to either use a project branch or access a
> view from multiple machines. Since some machines are shared, sometimes
> views get inadvertently upgraded.
>
And you are not concerned that some uncommitted change in this working copy
might be the thing that makes all your tests pass? I like to make 'svn
checkout' or 'update' the only means to get the source to the testing platforms
to ensure that the test is of a reproducible state.
--
Les Mikesell
lesmikesell@gmail.com
RE: Automatic upgrade of wc format annoying on shared drives
Posted by Jeremy Mordkoff <jl...@ZeeVee.Com>.
> Jeremy Mordkoff wrote:
> > I second that. I support fedora 7, 8, 9, 10, 11 (and soon 12),
various
> > ubuntu releases, plus windows XP, Vista, and Win7, and Mac OS 10.4,
> > 10.5. When one of them upgrades, it causes me to scramble to build
and
> > deploy upgrades to the others.
> >
>
> But working copies should really be disposable. As long as you keep
your
> changes commited, if the format is a problem for a different client,
just delete
> it and let that client build what it wants.
>
> --
> Les Mikesell
> lesmikesell@gmail.com
Our product also supports that variety of platforms. I request that
changes be tested on all platforms before the changes are committed.
That requires the engineer to either use a project branch or access a
view from multiple machines. Since some machines are shared, sometimes
views get inadvertently upgraded.
Thanks Daniel.
JLM
Re: Automatic upgrade of wc format annoying on shared drives
Posted by Les Mikesell <le...@gmail.com>.
Jeremy Mordkoff wrote:
> I second that. I support fedora 7, 8, 9, 10, 11 (and soon 12), various
> ubuntu releases, plus windows XP, Vista, and Win7, and Mac OS 10.4,
> 10.5. When one of them upgrades, it causes me to scramble to build and
> deploy upgrades to the others.
>
But working copies should really be disposable. As long as you keep your
changes commited, if the format is a problem for a different client, just delete
it and let that client build what it wants.
--
Les Mikesell
lesmikesell@gmail.com
RE: Automatic upgrade of wc format annoying on shared drives
Posted by Jeremy Mordkoff <jl...@ZeeVee.Com>.
I second that. I support fedora 7, 8, 9, 10, 11 (and soon 12), various ubuntu releases, plus windows XP, Vista, and Win7, and Mac OS 10.4, 10.5. When one of them upgrades, it causes me to scramble to build and deploy upgrades to the others.
JLM
-----Original Message-----
From: Simon [mailto:tzueskj268@snkmail.com]
Sent: Mon 4/12/2010 9:17 PM
To: users@subversion.apache.org
Subject: Automatic upgrade of wc format annoying on shared drives
We have work directories shared between many physical machines here (via sshfs, nfs, etc). We also use subversion as our configuration management system for source files.
When a newer client ends up on on of the work machines, it automatically (and silently) upgrades the wc metadata format of any working copies it touches. This prevents future access of any of the other clients until the working copies are manually downgraded (such as via: http://subversion.apache.org/faq.html#working-copy-format-change ).
This is quite annoying.
I think correct behaviour here is that the client should at least prompt the user to ask if it should upgrade the wc metadata format before messing with the working copy.
Failing that, is there some way of locking a working copy to a particular version of the wc metadata format.
Regards,
Simon
Re: Automatic upgrade of wc format annoying on shared drives
Posted by Simon <tz...@snkmail.com>.
On 13/04/2010, at 18:46 , Daniel Shahaf d.s-at-daniel.shahaf.name |
subversion users list| wrote:
> Simon wrote on Tue, 13 Apr 2010 at 01:17 -0000:
>> I think correct behaviour here is that the client should at least
>> prompt the user to ask if it should upgrade the wc metadata format
>> before messing with the working copy.
>>
>> Failing that, is there some way of locking a working copy to
>> a particular version of the wc metadata format.
>
> Subversion 1.7 will require explicit user action to upgrade a wc.
>
> % svn info wc1\trunk
> ...\..\..\subversion\libsvn_wc\upgrade.c:1086: (apr_err=155036)
> svn: Working copy format of 'C:\tmp\svn\wc1\trunk' is too old (10);
> please run 'svn upgrade'
>
That's great. Thanks for the info.
Simon
Re: Automatic upgrade of wc format annoying on shared drives
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Simon wrote on Tue, 13 Apr 2010 at 01:17 -0000:
> I think correct behaviour here is that the client should at least
> prompt the user to ask if it should upgrade the wc metadata format
> before messing with the working copy.
>
> Failing that, is there some way of locking a working copy to
> a particular version of the wc metadata format.
Subversion 1.7 will require explicit user action to upgrade a wc.
% svn info wc1\trunk
..\..\..\subversion\libsvn_wc\upgrade.c:1086: (apr_err=155036)
svn: Working copy format of 'C:\tmp\svn\wc1\trunk' is too old (10); please run 'svn upgrade'