Sorry for the delay (had to retest some things). Some answers below.
On Thu, Sep 23, 2010 at 7:18 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Johan Corveleyn wrote on Thu, Sep 23, 2010 at 12:40:35 +0200:
>> [now with better subject line (clicked send too soon on previous
>> mail), please use this thread iso the other one]
>>
>> Hi all,
>>
>> I don't know if this is already a known issue/bug (in issue tracker or
>> mailinglist), but I consider this a bug:
>>
>
> Which version of svn? Does it reproduce with trunk? (libsvn_wc has been
> largely rewritten, remember)
Sorry I forgot to mention this. This was with 1.6.12 (SlikSVN). But it
reproduces also with trunk (exactly the same behavior).
>> 1) Change a directory external definition and commit it (for instance,
>> let it point to a new release branch).
>>
>
> Is the commit necessary?
No.
Somehow I thought svn:external properties would only take effect after
being committed, but that seems not to be the case (I was confusing
with issue#2267: "support svn:externals on locally added
directories"). This means one can easily retest/reproduce this issue
with a working copy from some large public repository of your choosing
...
>> 2) svn update
>>
>> 3) Interrupt the update (Ctrl-C) while it is processing the "switch"
>> of the external. I did this after some files of the external were
>> already Updated.
>>
>
> It's not immediate to reproduce this in a greek tree repository (the
> update runs too fast)... :-(
>
> I suppose I could just use larger files in the test repository, though.
> Or perhaps compile a conditional-on-filename abort() into svn/notify.c.
>
> (but I'm sure there's an easier way... I have a tendency to overlook the
> simple solutions sometimes)
I don't have an idea right now how to reproduce this easily with a
self-constructed test-repository. But for now it may suffice to
reproduce this with a checkout from a large public repository (no need
to commit anything)?
>> 4) svn status now shows a lot of files and directories as S
>> (switched), and some directories missing. Running svn info on the
>> switched files/dirs shows that they are associated with the correct
>> (new) location (where the new external definition points to), but they
>> are still marked as switched.
Sorry, above information is incorrect: the files/dirs marked as
switched still point to the old external location, the wrong one. That
makes a lot more sense (the top external dir is pointing to the new
external location, not marked as switched, all is fine; some of its
children still point to the old location and are marked as switched).
>> Running svn update again fixes the "missing" dirs, but not the
>> switched nodes. "svn revert" does nothing (which is logical: there are
>> no local changes). "svn cleanup" does nothing.
>>
>
> Have you tried running 'svn switch $new_url $external_dir'?
This effectively fixes the broken external dir. Great, thanks!
So that's a good workaround (explicitly switch the
broken-by-interruption external dir to its correct external location).
I'll document this for our devs so they can fix it whenever they
encounter this.
But I think "svn update" should be able to do this (i.e. resume the
interrupted update, whatever that may entail). Don't you agree? If so,
I'll file an issue, referring to this thread, and documenting the
"explicit switch" workaround.
I wonder though: what would happen with a
broken-by-interrupt-external-dir that's pointing to a remote
repository (maybe we changed the remote repos location, or only the
relative path within the remote repos)? In that case a normal switch
wouldn't work, would it? Or would the same work with a switch
--relocate? I don't have time to test this right now, but it's
something to think about ...
I have no idea how externals are implemented (are they simply switched
(+relocated) working copy subtrees with some sugar on top?)
Cheers,
--
Johan
Received on 2010-09-30 03:17:24 CEST