Johan Corveleyn wrote on Thu, Sep 30, 2010 at 03:16:46 +0200:
> Sorry for the delay (had to retest some things). Some answers below.
>
No problem.
> 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:
> >> 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 (...).
Indeed.
> 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)?
>
Yes. (I don't recall offhand a repos that uses externals, myself..)
> >> 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 agree that the working copy shouldn't be left in the transient
half-switched state. However, before filing an issue, could you stop by
the dev@ list? With all the wc work going on, it might be better to
have the wcng people's input on this before filing an issue.
> 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 suppose some invocation of 'switch' would work? (All 'switch' means
is "Update this working copy to <this> revision of <that> URL; and, in
the end of the day, what you're trying to do /can/ be phrased this way.)
> I have no idea how externals are implemented (are they simply switched
> (+relocated) working copy subtrees with some sugar on top?)
>
Not sure, sorry. But feel free to stop by dev@ (or by the wcng design
docs) and get this question answered :-)
> Cheers,
> --
> Johan
Received on 2010-09-30 08:07:07 CEST