Re: Interrupting an update after change of externals causes corrupt working copy

[Johan Corveleyn <jc...@gmail.com>]

Hi devs,

As per Daniel Shahaf's suggestion, I'm continuing this discussion on
the dev list. See the previous mails in this thread on the users list
for some context (or
http://svn.haxx.se/users/archive-2010-09/0406.shtml). I'll summarize
below.

This issue reproduces with 1.6.12 as well as with trunk. It would be
interesting to know the WC-NG folks take on this.

Note: the subject line may be slightly exaggerated, as there seems to
be a good workaround to repair things (at least in case of
intra-repository externals).

Summary
-------

Steps to reproduce:
1) Change a directory external definition.

2) svn update

3) Interrupt (Ctrl-C) while it is processing the "switch" of the
external. I did this after some files of the external were already
Updated.

Result:
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 still point to the old external location.

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.

Workaround:
Running "svn switch $new_url $external_dir" brings everything back to normal.


So:
- Wouldn't it be better if "svn update" could repair this (as in
"resuming the interrupted update from before")?
- Should I file an issue for this?
- I'm not sure how all this plays out with externals from remote
repositories (haven't tested this). With or without a change of the
remote location. Would an "svn switch --relocate" fix things in the
same way then?

Note: this can be easily reproduced with any large (public) repository
(I think). Just define some externals in working copy only (no need to
commit), update, change external definition (no need to commit),
update, interrupt.

Cheers,
-- 
Johan

Re: Interrupting an update after change of externals causes corrupt working copy

[Johan Corveleyn <jc...@gmail.com>]

Almost forgot about this. It's now filed in the issue tracker:
http://subversion.tigris.org/issues/show_bug.cgi?id=3751

Cheers,
Johan

On Thu, Sep 30, 2010 at 10:03 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> Hi devs,
>
> As per Daniel Shahaf's suggestion, I'm continuing this discussion on
> the dev list. See the previous mails in this thread on the users list
> for some context (or
> http://svn.haxx.se/users/archive-2010-09/0406.shtml). I'll summarize
> below.
>
> This issue reproduces with 1.6.12 as well as with trunk. It would be
> interesting to know the WC-NG folks take on this.
>
> Note: the subject line may be slightly exaggerated, as there seems to
> be a good workaround to repair things (at least in case of
> intra-repository externals).
>
> Summary
> -------
>
> Steps to reproduce:
> 1) Change a directory external definition.
>
> 2) svn update
>
> 3) Interrupt (Ctrl-C) while it is processing the "switch" of the
> external. I did this after some files of the external were already
> Updated.
>
> Result:
> 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 still point to the old external location.
>
> 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.
>
> Workaround:
> Running "svn switch $new_url $external_dir" brings everything back to normal.
>
>
> So:
> - Wouldn't it be better if "svn update" could repair this (as in
> "resuming the interrupted update from before")?
> - Should I file an issue for this?
> - I'm not sure how all this plays out with externals from remote
> repositories (haven't tested this). With or without a change of the
> remote location. Would an "svn switch --relocate" fix things in the
> same way then?
>
> Note: this can be easily reproduced with any large (public) repository
> (I think). Just define some externals in working copy only (no need to
> commit), update, change external definition (no need to commit),
> update, interrupt.
>
> Cheers,
> --
> Johan
>