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...@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
