You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Robert Dailey <rc...@gmail.com> on 2008/08/27 19:13:27 UTC

Problem with svn switch

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

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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Problem with svn switch

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Robert Dailey wrote on Wed, 27 Aug 2008 at 16:15 -0500:
> Will the patch that fixes this make it into subversion 1.5.2?
> 

No, since 1.5.2 is being rolled as I'm writing.  It might be in 1.5.3.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Problem with svn switch

Posted by Robert Dailey <rc...@gmail.com>.
On Wed, Aug 27, 2008 at 4:13 PM, Daniel Shahaf <d....@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Problem with svn switch

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org