"svn upgrade" does nothing
Hello, I'm having a weird issue with subversion: Every command is interrupt with this: svn: E155036: Please see the 'svn upgrade' command svn: E155036: The working copy at '/home/jabiason/{work}' is too old (format 10) to work with client version '1.8.10 (r1615264)' (expects format 31). You need to upgrade the working copy first. I run svn upgrade (even multiple times) but the problem still happens. As a temporary solution, I checked the source out in a different directory, but there is a little snag: For my reluctance in commiting mid change, there are some files that are not part of the repo yet but I can't see them because "svn st" is interrupted mid processing with the error above. svn --version svn, version 1.8.10 (r1615264) compiled Aug 20 2014, 08:13:28 on x86_64-redhat-linux-gnu (It is the default subversion packaged by Fedora, btw). -- Enviado via UCSMail.
RE: "svn upgrade" does nothing
I suggest you do a new, clean checkout. You can just copy the dirty files into the new working copy. From: Julio Andre Biason [mailto:jabia...@ucs.br] Sent: Tuesday, October 21, 2014 12:11 PM To: users@subversion.apache.org Subject: "svn upgrade" does nothing Hello, I'm having a weird issue with subversion: Every command is interrupt with this: svn: E155036: Please see the 'svn upgrade' command svn: E155036: The working copy at '/home/jabiason/{work}' is too old (format 10) to work with client version '1.8.10 (r1615264)' (expects format 31). You need to upgrade the working copy first. I run svn upgrade (even multiple times) but the problem still happens. As a temporary solution, I checked the source out in a different directory, but there is a little snag: For my reluctance in commiting mid change, there are some files that are not part of the repo yet but I can't see them because "svn st" is interrupted mid processing with the error above. svn --version svn, version 1.8.10 (r1615264) compiled Aug 20 2014, 08:13:28 on x86_64-redhat-linux-gnu (It is the default subversion packaged by Fedora, btw). Enviado via UCSMail.
Re: "svn upgrade" does nothing
On Tue, Oct 21, 2014 at 02:10:39PM -0200, Julio Andre Biason wrote: > Hello, > > I'm having a weird issue with subversion: Every command is interrupt with > this: > > svn: E155036: Please see the 'svn upgrade' command > svn: E155036: The working copy at '/home/jabiason/{work}' is too old > (format 10) to work with client version '1.8.10 (r1615264)' (expects format > 31). You need to upgrade the working copy first. > > I run svn upgrade (even multiple times) but the problem still happens. Normally 'svn upgrade' should either print nothing and succeed (allowing the 1.8 client to operate on the working copy), or it should complain with some error message and fail. I can't explain the behaviour you seem to be describing (no output but not success either). Can you please show how you invoked the svn upgrade command exactly? And show the current working directory where you invoked it? It seems you edited the error message, "/home/jabiason/{work}" is not a usual path. Can you please at least give something that looks like what you're seeing? If you insist on changing paths, please change the path's components to some nonsense but leave the paths as-is otherwise, rather than possibly redacting entire portions of a path.
Re: "svn upgrade" does nothing
I run "svn upgrade" in two different forms: 1. First, a simple "svn upgrade". No output at all. "svn update" after that fails: Updating '.': svn: E155036: Please see the 'svn upgrade' command svn: E155036: The working copy at '/home/jabiason/src/work/nephalem/12514-old/nephalem/media' is too old (format 10) to work with client version '1.8.10 (r1615264)' (expects format 31). You need to upgrade the working copy first. 2. Then, dunno why, I tried "svn upgrade ." (see the dot at the end of the command). Again, no output and "svn update" fails again. Yes, "{work}" is my current working directory, which includes information that I'm not comfortable sharing, even if there is no way to access, simply because I'm working for a client and I'd have to ask him permission to access. If that makes you happy, "/home/jabiason/foo/bar/zaz/12312", where "12312" is the branch name -- yes, it's a number and no, "zaz" is not "branches" because I checked out only the branch I need to work. Personally, path shouldn't affect the result of a program: It has direct access to its local repository/data (/home/jabiason/foo/bar/zaz/12312/.svn) and there is nothing that the base OS can't handle (otherwise I wouldn't even be able to access my files). On 21 October 2014 16:34, Stefan Sperling wrote: > On Tue, Oct 21, 2014 at 02:10:39PM -0200, Julio Andre Biason wrote: > > Hello, > > > > I'm having a weird issue with subversion: Every command is interrupt with > > this: > > > > svn: E155036: Please see the 'svn upgrade' command > > svn: E155036: The working copy at '/home/jabiason/{work}' is too old > > (format 10) to work with client version '1.8.10 (r1615264)' (expects > format > > 31). You need to upgrade the working copy first. > > > > I run svn upgrade (even multiple times) but the problem still happens. > > Normally 'svn upgrade' should either print nothing and succeed (allowing > the 1.8 client to operate on the working copy), or it should complain with > some error message and fail. > > I can't explain the behaviour you seem to be describing (no output but > not success either). > > Can you please show how you invoked the svn upgrade command exactly? > And show the current working directory where you invoked it? > > It seems you edited the error message, "/home/jabiason/{work}" is not > a usual path. Can you please at least give something that looks like > what you're seeing? If you insist on changing paths, please change the > path's components to some nonsense but leave the paths as-is otherwise, > rather than possibly redacting entire portions of a path. > -- Enviado via UCSMail.
Re: "svn upgrade" does nothing
On Tue, Oct 21, 2014 at 04:42:14PM -0200, Julio Andre Biason wrote: > I run "svn upgrade" in two different forms: > > 1. First, a simple "svn upgrade". No output at all. "svn update" after that > fails: > > Updating '.': > svn: E155036: Please see the 'svn upgrade' command > svn: E155036: The working copy at > '/home/jabiason/src/work/nephalem/12514-old/nephalem/media' > is too old (format 10) to work with client version '1.8.10 (r1615264)' > (expects format 31). You need to upgrade the working copy first. > > 2. Then, dunno why, I tried "svn upgrade ." (see the dot at the end of the > command). Again, no output and "svn update" fails again. The current directory is the default path if not specified, so both of these invocations did the same thing (whatever they did instead of what we'd expect they'd do). What happens if you run this? svn upgrade '/home/jabiason/src/work/nephalem/12514-old/nephalem/media' > Personally, path shouldn't affect the result of a program: This expectation doesn't hold in the case of 'svn upgrade', unfortunately. It must be passed the path to the top-level directory of a working copy. I've spent quite some time in the 'svn upgrade' code in an effort to fix that but to no avail. In some situations (involving nested working copies of various formats) svn just can't make a well-informed guess. Still, if the path you pass is not a working copy root, I'd expect to see an error such as: svn: E155019: Can't upgrade '/tmp/svn-sandbox/trunk/gamma' as it is not a working copy root, the root is '/tmp/svn-sandbox/trunk' I'd like to reproduce your problem locally but so far I haven't succeeded in doing so.
Re: "svn upgrade" does nothing
I had pretty much the idea that "svn upgrade" and "svn upgrade ." were the same, I was just trying to scratch both options out of the list. Upgrading the directory itself fixed the problem. This makes me think (I'm saying this just seeing the behaviour, I have no idea how the code works): It seems upgrade didn't go deep into the directory structure because the root (of the local repo) was already in the latest version[1]. Does upgrade try to go recursively into all directories, checking for ".svn" and updating if necessary? [1] Which also makes me wonder how a single directory got behind in the update process... On 21 October 2014 16:53, Stefan Sperling wrote: > On Tue, Oct 21, 2014 at 04:42:14PM -0200, Julio Andre Biason wrote: > > I run "svn upgrade" in two different forms: > > > > 1. First, a simple "svn upgrade". No output at all. "svn update" after > that > > fails: > > > > Updating '.': > > svn: E155036: Please see the 'svn upgrade' command > > svn: E155036: The working copy at > > '/home/jabiason/src/work/nephalem/12514-old/nephalem/media' > > is too old (format 10) to work with client version '1.8.10 (r1615264)' > > (expects format 31). You need to upgrade the working copy first. > > > > 2. Then, dunno why, I tried "svn upgrade ." (see the dot at the end of > the > > command). Again, no output and "svn update" fails again. > > The current directory is the default path if not specified, so both of > these invocations did the same thing (whatever they did instead of what > we'd expect they'd do). > > What happens if you run this? > svn upgrade '/home/jabiason/src/work/nephalem/12514-old/nephalem/media' > > > Personally, path shouldn't affect the result of a program: > > This expectation doesn't hold in the case of 'svn upgrade', unfortunately. > It must be passed the path to the top-level directory of a working copy. > I've spent quite some time in the 'svn upgrade' code in an effort to > fix that but to no avail. In some situations (involving nested working > copies of various formats) svn just can't make a well-informed guess. > > Still, if the path you pass is not a working copy root, I'd expect to > see an error such as: > svn: E155019: Can't upgrade '/tmp/svn-sandbox/trunk/gamma' as it is not a > working copy root, the root is '/tmp/svn-sandbox/trunk' > > I'd like to reproduce your problem locally but so far I haven't succeeded > in doing so. > -- Enviado via UCSMail.
Re: "svn upgrade" does nothing
On Tue, Oct 21, 2014 at 05:03:07PM -0200, Julio Andre Biason wrote: > Upgrading the directory itself fixed the problem. > > This makes me think (I'm saying this just seeing the behaviour, I have no > idea how the code works): It seems upgrade didn't go deep into the > directory structure because the root (of the local repo) was already in the > latest version[1]. Does upgrade try to go recursively into all directories, > checking for ".svn" and updating if necessary? Every 'svn' operation scans upwards to find the working copy root. So 'svn upgrade' scans for a working copy root upwards from the directory you pass in. If the nearest root found is already at the latest format it has nothing to do and exits. I suppose this is exactly what happened here. The other commands you ran probably scanned upwards from a different path and therefore found a different working copy at the old format. > [1] Which also makes me wonder how a single directory got behind in the > update process... You likely had disjoint nested working copies in 1.6 format. If you ran 'svn checkout URL1 A' and then 'svn checkout URL2 A/B' this would happen. The same situation could be created by an svn:externals configuration. The upgrade command does not look at what is above working copies created via svn:externals because the external working copy does not know that it is considered an external by some other working copy (don't ask me why -- this is how it was implemented years ago). In the 1.7/1.8 format, there is a single .svn directory at the top-level of each working copy. Now that the upgrade is complete you should be able to tell how many working copies you've got by looking for .svn directories.