We use branches extensively and switches from branches with new
directories fail often. However the error we get is something like
"Obstructed update: ...." and the working directory is left in a completely
hosed state.
The recovery process has been to delete the working directory and
start with a new checkout. However having unversioned files in the new
checkout does not appear to cause a problem. I imagine this is the
same problem even though the error message is different. This is with
svn 1.4.3.
Abhi
On Fri, Jul 13, 2007 at 01:47:59AM +0100, james coleman wrote:
> Karl Fogel wrote:
> >james coleman <jamesc@dspsrv.com> writes:
> >>Here is the text of the FAQ entry I think would work:
> >
> >Thanks, I think this is worth having in the FAQ. Can you send it to
> >dev@ as a patch, using the instructions at
> >
> > http://subversion.tigris.org/mailing-list-guidelines.html#patches
>
> Thanks Karl, I've been composing my submission for a while now :-P :)
> Wondering what mime type Thunderbird will think a .patch is?
> Content-Type: text/x-patch; good. :)
>
> >
> >See comments below...
> >
> >>Why doesn't svn switch work in some cases?
> >>
> >>In some cases where there are unversioned (and maybe ignored) items
> >>in the working copy then you can get errors and end up with an
> >>unusable working copy. The more complex the changes on branch and trunk
> >>the more likely this is. See issue 2505.
> >
> >If you could provide some examples of local changes that are *not*
> >likely to interfere with switch, that would help; adding other
> >examples of changes that are likely to interfere would be great too.
>
> I didn't want to delve into detail and confuse people but Hmmm, yes.
> Seeing the exact error svn reports might make people searching for it hit
> the FAQ entry.
>
>
> One scenario:
>
> If any directory has been moved or renamed between the branches then
> anything unversioned in there will cause a problem. A switch requires that
> the
> directory doesn't exist after the switch so what to do with unversioned
> content?
> svn plays it safe and doesn't want to delete it.
>
> This is recoverable from actually, you have a half-switched working copy.
> You can rm the directory left behind (now also unversioned without .svn) and
> then run the svn switch again.
>
> If multiple things have been renamed the switch will trip up and break on
> each
> one so cleaning unversioned files would help.
>
> wc/$ svn switch $SVNROOT/foobar/branches/br1
> wc/$ mkdir foo
> wc/$ svn add foo
> wc/$ svn ci -m"add dir foo" foo
> wc/$ touch foo/unversioned_file
> wc/$ svn switch $SVNROOT/foobar/branches/br2
> svn: Won't delete locally modified directory '.'
> svn: Left locally modified or unversioned files
>
> # to recover:
>
> wc/$ svn status
> ! .
> S foo.c
> ~ foo
>
> wc/$ rm -rf foo
> wc/$ svn switch
>
> wc/$ svn up
> svn: Directory 'foo/.svn' containing working copy admin area is missing
>
> wc/$ svn switch $SVNROOT/foobar/branches/br2
> D foo
> U .
> Updated to revision 19.
>
>
>
> It is the first case listed by bug #2466 though I think.
> The error message is confusing and the user did not know what the error was
> telling them.
> The user did an svn revert which then put the working copy in broken state.
> It could do with a FAQ entry too:
> What does svn switch error "svn: Won't delete locally modified directory
> '.'" mean?
>
>
>
> Actually!
>
>
> ............
>
>
> Hmmmmmmmmmmmmmmmmmmmmmmm.
>
>
> I'm wondering is this example all there is to #2505?
> A confusing error followed by wrong corrective action then useless working
> copy.
> http://subversion.tigris.org/issues/show_bug.cgi?id=2505
>
> It could be. Both recipies in #2505 and #2466 could have been
> recovered from by removing the offending unversioned files and
> continuing the svn switch.
> And I did not know you could recover like this until starting to
> investigate this.
>
> Now there could be a nastier issue lurking here.
> But after thinking about this so much I'm beginning to think this _could_
> be all there
> is to the issue.
>
>
> If so it could be fixed by getting svn to fix error and direct user to rm
> all unversioned files and continue the script.
> It would be nice if there was a --force or --allow-delete-unversioned or
> something
> which would make svn brutally delete things in the way of a switch.
>
>
> Actually I'm wrecked and it's 1:30am here so I'm going to collapse to bed.
> :-7
> I could be completely delusional right now so will leave it here for now.
>
> This is taking me a while as I've started testing this more.
> I think I'll comment on 2505 about this. Tomorrow.
> I'll test and stop cleaning before I svn switch and see if I can recover
> every time.
> (Two dirty switches I started between branches that had problems before I
> have
> now recovered from.)
>
>
> >
> >Remember, the reader will be asking themselves "Am I in trouble or
> >not?" Anything we can do to help them know the answer to that
> >question is good.
> >
> >>A switch from a pristine clean checkout always works. There are two
> >>ways of working if you are using svn switch as part of your development
> >>process:
> >>
> >> 1. Fully clean your working copy of unversioned (including ignored)
> >> files before switch.
> >> WARNING! This deletes all unversioned dirs/files.
> >> Be VERY sure that you do not need anything that will be removed.
> >>
> >> alias svn-unversioned='svn status --no-ignore | grep "^[I?]" |
> >> sed 's/^[I?]//''
> >> alias svn-clean-wc='svn-unversioned |xargs rm -rf'
> >
> >Just show the commands as commands; aliasing mechanisms may differ
> >from shell to shell, and some people don't know what aliases are.
>
> Okay.
> I also see in contrib/client-side/svn-clean
> But it's a good few lines of perl and I'm thinking the simpler the better.
> Maybe these one-liners fit in contrib?
>
> >
> >-Karl
> >
>
> Sheesh. :-7 And thanks Karl.
>
> James.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
--
Abhinandan Jain, Ph.D.
Dynamics and Real-Time Simulation (DARTS) Lab
Mobilty and Robotic Systems Section
Jet Propulsion Laboratory
4800 Oak Grove Drive, Pasadena, CA 91109
(818)-354-3412 (818)-393-5007 (fax)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 13 03:26:48 2007