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.
Received on 2014-10-21 22:03:14 CEST