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.