On Wed, Aug 27, 2008 at 4:13 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> 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.
>>
>
Will the patch that fixes this make it into subversion 1.5.2?
---------------------------------------------------------------------
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:15:33 CEST