Robert Dailey wrote on Wed, 27 Aug 2008 at 14:13 -0500:
> Hi,
>
> I originally posted this on the Tortoise SVN developer mailing list,
> because I wasn't sure where to post it. However, I was informed that
> the topic would be better suited for the subversion mailing list. Note
> that I don't have a lot of experience with working with subversion
> directly, so I can only explain the problem as I found it through
> TortoiseSVN. I apologize for the inconvenience, but I hope that you'll
> get the basic description of the problem I'm facing. The original post
> I made to TortoiseSVN has been pasted below:
> ----------------------------------------------------
>
> This may be a Subversion issue, but I'm not sure. I'll ask here and
> then if need be I'll forward this on to the subversion mailing list.
>
> When I'm working out of a feature branch, sometimes I will want to do
> an SVN Switch back to trunk, but instead of going to the HEAD of trunk
> I'll go to some extremely early version. In my specific test case,
> doing so results in a folder like C:\IT\work\jewett\vfx\mycomponent
> (Assuming C:\IT\work\jewett is my working copy root) being deleted,
> but the update dialog fails with:
>
> Switch C:\IT\work\jewett to
> http://teamserver:1337/svn/vfxrepo/vfx/trunk, Revision 260
> C:\IT\work\jewett\tools
> Won't delete locally modified directory 'C:\IT\work\jewett\vfx'
> Left locally modified or unversioned files
>
>
> What I believe is happening here is that the entire switch process is
> failing because I have unversioned (but svn:ignore'd) files and
> directories in parent directories that are versioned, but are
> attempting to be removed from the working copy by TSVN.
I think it's issue #2505, for which Danil Shopyrin posted a patch
earlier this week:
http://thread.gmane.org/gmane.comp.version-control.subversion.devel/103153
http://subversion.tigris.org/issues/show_bug.cgi?id=2505
As I said there, I intend to review/commit this patch in the next few
days.
> What I would
> expect to happen here is that the switch process does *not* fail here,
> but instead it silently unversions the respective directories that
> contain unversioned items, but does not delete them (Like it does for
> single files), only the .svn folders would be removed. Why is this
> treated as an exceptional error? I don't like that the switch process
> fails because of this. Now my working copy is so messed up that I
> cannot recover it without doing a completely new checkout, or deleting
> some very large directories that cause some expensive bandwidth to get
> back. (such as jewett/vfx directory).
>
> I'm using TortoiseSVN 1.5.2.
>
OT: TSVN 1.5.2 is linked against libsvn 1.5.1, and it's the latter
number that matters to us. I think it just invites confusion...
> Note also that when I do a "Check for Modifications" after the switch
> fails, I see one folder inside of C:\IT\work\jewett\vfx that is
> colored red and marked as "Obstructed". This folder has no icon
> overlay and no .svn folder inside of it. For example,
> jewett/vfx/configuration, a directory, would only contain the files
> inside of it that were previously unversioned, but all of the
> versioned contents are removed.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-27 23:13:31 CEST