You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Maxwell Ballenger <Ma...@spacex.com> on 2013/01/19 00:44:08 UTC
Working copy corrupted by branch deletion
Hi Subversion Users,
We're experiencing some new behavior after upgrading from TortoiseSVN 1.6.14 (Subversion client library 1.6.16) to TortoiseSVN 1.7.10 (Subversion client library 1.7.7). We noticed this using TortoiseSVN, but some folks on their mailing list believe that this is a result of the Subversion client library, not Tortoise. I am not sure whether this is a bug or intended behavior. Here is what happens:
1. Branch a subfolder of your working copy
2. Switch that subfolder onto that branch
3. Delete that branch using another working copy or the repo-browser
4. Update your working copy
5. That subfolder disappears. There is no way to recover that subfolder and have your working copy match the trunk again without doing a fresh checkout.
In TortoiseSVN 1.6.14 (Subversion 1.6.16), a mistake like this was much easier to recover from. Commanding a switch of a parent folder to trunk would restore the missing subfolder.
Is this intended behavior, or could it qualify for a bug fix? Does anyone know of a faster way to recover than a fresh checkout?
Thanks!
Max Ballenger
RE: Working copy corrupted by branch deletion
Posted by Maxwell Ballenger <Ma...@spacex.com>.
Thanks a lot, Bert!
I will keep an eye out for the fix.
Max
From: Bert Huijben [mailto:bert@qqmail.nl]
Sent: Saturday, January 19, 2013 3:59 PM
To: Maxwell Ballenger; users@subversion.apache.org
Cc: dev@subversion.apache.org
Subject: RE: Working copy corrupted by branch deletion
Hi,
Thanks for a very interesting issue to look at.
I'm happy to report that I would now call this issue fixed:
I think we can call this a known issue as it has been known for quite some time.
A workaround for this issue would be to do an explicit update of the missing target. (Or reducing and increasing the depth of the node).
I documented the issue as issue #4295 with the following recipe
$ svnadmin create repos
$ svn mkdir --parents file:///%CD%/repos/A/B/C<file:///\\%CD%25\repos\A\B\C> -m ""
$ svn cp file:///%CD%/repos/A<file:///\\%CD%25\repos\A> file:///%CD%/repos/AA<file:///\\%CD%25\repos\AA> -m ""
$ svn co file:///%CD%/repos/A<file:///\\%CD%25\repos\A> A
$ svn switch ^/AA/B A/B
$ svn rm file:///%CD%/repos/AA<file:///\\%CD%25\repos\AA>
$ svn up A
On 1.7 this reproduces your issue
And a
$ svn up A/B
Will bring back the missing directory.
When trying the same thing on trunk I found a completely different issue, where the complete update failed. I'm not going to bother you with the details of this report, as thanks to your bug report that huge regression will never be in a released version of Subversion. (Thanks!!!)
To close issue #4295, I added a small check to the update code that handles incoming deletes. When it encounters a delete of a switched path it will now place a similar hidden marker as you would get when you update a path to r0 (or commit a file delete). The next update will now bring in the missing node.
I will nominate the fix for backporting to a future 1.7 release.
Bert
From: Maxwell Ballenger [mailto:Maxwell.Ballenger@spacex.com]
Sent: zaterdag 19 januari 2013 00:44
To: users@subversion.apache.org<ma...@subversion.apache.org>
Subject: Working copy corrupted by branch deletion
Hi Subversion Users,
We're experiencing some new behavior after upgrading from TortoiseSVN 1.6.14 (Subversion client library 1.6.16) to TortoiseSVN 1.7.10 (Subversion client library 1.7.7). We noticed this using TortoiseSVN, but some folks on their mailing list believe that this is a result of the Subversion client library, not Tortoise. I am not sure whether this is a bug or intended behavior. Here is what happens:
1. Branch a subfolder of your working copy
2. Switch that subfolder onto that branch
3. Delete that branch using another working copy or the repo-browser
4. Update your working copy
5. That subfolder disappears. There is no way to recover that subfolder and have your working copy match the trunk again without doing a fresh checkout.
In TortoiseSVN 1.6.14 (Subversion 1.6.16), a mistake like this was much easier to recover from. Commanding a switch of a parent folder to trunk would restore the missing subfolder.
Is this intended behavior, or could it qualify for a bug fix? Does anyone know of a faster way to recover than a fresh checkout?
Thanks!
Max Ballenger
RE: Working copy corrupted by branch deletion
Posted by Maxwell Ballenger <Ma...@spacex.com>.
Thanks a lot, Bert!
I will keep an eye out for the fix.
Max
From: Bert Huijben [mailto:bert@qqmail.nl]
Sent: Saturday, January 19, 2013 3:59 PM
To: Maxwell Ballenger; users@subversion.apache.org
Cc: dev@subversion.apache.org
Subject: RE: Working copy corrupted by branch deletion
Hi,
Thanks for a very interesting issue to look at.
I'm happy to report that I would now call this issue fixed:
I think we can call this a known issue as it has been known for quite some time.
A workaround for this issue would be to do an explicit update of the missing target. (Or reducing and increasing the depth of the node).
I documented the issue as issue #4295 with the following recipe
$ svnadmin create repos
$ svn mkdir --parents file:///%CD%/repos/A/B/C<file:///\\%CD%25\repos\A\B\C> -m ""
$ svn cp file:///%CD%/repos/A<file:///\\%CD%25\repos\A> file:///%CD%/repos/AA<file:///\\%CD%25\repos\AA> -m ""
$ svn co file:///%CD%/repos/A<file:///\\%CD%25\repos\A> A
$ svn switch ^/AA/B A/B
$ svn rm file:///%CD%/repos/AA<file:///\\%CD%25\repos\AA>
$ svn up A
On 1.7 this reproduces your issue
And a
$ svn up A/B
Will bring back the missing directory.
When trying the same thing on trunk I found a completely different issue, where the complete update failed. I'm not going to bother you with the details of this report, as thanks to your bug report that huge regression will never be in a released version of Subversion. (Thanks!!!)
To close issue #4295, I added a small check to the update code that handles incoming deletes. When it encounters a delete of a switched path it will now place a similar hidden marker as you would get when you update a path to r0 (or commit a file delete). The next update will now bring in the missing node.
I will nominate the fix for backporting to a future 1.7 release.
Bert
From: Maxwell Ballenger [mailto:Maxwell.Ballenger@spacex.com]
Sent: zaterdag 19 januari 2013 00:44
To: users@subversion.apache.org<ma...@subversion.apache.org>
Subject: Working copy corrupted by branch deletion
Hi Subversion Users,
We're experiencing some new behavior after upgrading from TortoiseSVN 1.6.14 (Subversion client library 1.6.16) to TortoiseSVN 1.7.10 (Subversion client library 1.7.7). We noticed this using TortoiseSVN, but some folks on their mailing list believe that this is a result of the Subversion client library, not Tortoise. I am not sure whether this is a bug or intended behavior. Here is what happens:
1. Branch a subfolder of your working copy
2. Switch that subfolder onto that branch
3. Delete that branch using another working copy or the repo-browser
4. Update your working copy
5. That subfolder disappears. There is no way to recover that subfolder and have your working copy match the trunk again without doing a fresh checkout.
In TortoiseSVN 1.6.14 (Subversion 1.6.16), a mistake like this was much easier to recover from. Commanding a switch of a parent folder to trunk would restore the missing subfolder.
Is this intended behavior, or could it qualify for a bug fix? Does anyone know of a faster way to recover than a fresh checkout?
Thanks!
Max Ballenger
RE: Working copy corrupted by branch deletion
Posted by Bert Huijben <be...@qqmail.nl>.
Hi,
Thanks for a very interesting issue to look at.
I'm happy to report that I would now call this issue fixed:
I think we can call this a known issue as it has been known for quite some
time.
A workaround for this issue would be to do an explicit update of the missing
target. (Or reducing and increasing the depth of the node).
I documented the issue as issue #4295 with the following recipe
$ svnadmin create repos
$ svn mkdir --parents file:///%CD%/repos/A/B/C -m ""
$ svn cp file:///%CD%/repos/A file:///%CD%/repos/AA -m ""
$ svn co file:///%CD%/repos/A A
$ svn switch ^/AA/B A/B
$ svn rm file:///%CD%/repos/AA
$ svn up A
On 1.7 this reproduces your issue
And a
$ svn up A/B
Will bring back the missing directory.
When trying the same thing on trunk I found a completely different issue,
where the complete update failed. I'm not going to bother you with the
details of this report, as thanks to your bug report that huge regression
will never be in a released version of Subversion. (Thanks!!!)
To close issue #4295, I added a small check to the update code that handles
incoming deletes. When it encounters a delete of a switched path it will now
place a similar hidden marker as you would get when you update a path to r0
(or commit a file delete). The next update will now bring in the missing
node.
I will nominate the fix for backporting to a future 1.7 release.
Bert
From: Maxwell Ballenger [mailto:Maxwell.Ballenger@spacex.com]
Sent: zaterdag 19 januari 2013 00:44
To: users@subversion.apache.org
Subject: Working copy corrupted by branch deletion
Hi Subversion Users,
We're experiencing some new behavior after upgrading from TortoiseSVN 1.6.14
(Subversion client library 1.6.16) to TortoiseSVN 1.7.10 (Subversion client
library 1.7.7). We noticed this using TortoiseSVN, but some folks on their
mailing list believe that this is a result of the Subversion client library,
not Tortoise. I am not sure whether this is a bug or intended behavior. Here
is what happens:
1. Branch a subfolder of your working copy
2. Switch that subfolder onto that branch
3. Delete that branch using another working copy or the repo-browser
4. Update your working copy
5. That subfolder disappears. There is no way to recover that subfolder and
have your working copy match the trunk again without doing a fresh checkout.
In TortoiseSVN 1.6.14 (Subversion 1.6.16), a mistake like this was much
easier to recover from. Commanding a switch of a parent folder to trunk
would restore the missing subfolder.
Is this intended behavior, or could it qualify for a bug fix? Does anyone
know of a faster way to recover than a fresh checkout?
Thanks!
Max Ballenger
RE: Working copy corrupted by branch deletion
Posted by Bert Huijben <be...@qqmail.nl>.
Hi,
Thanks for a very interesting issue to look at.
I'm happy to report that I would now call this issue fixed:
I think we can call this a known issue as it has been known for quite some
time.
A workaround for this issue would be to do an explicit update of the missing
target. (Or reducing and increasing the depth of the node).
I documented the issue as issue #4295 with the following recipe
$ svnadmin create repos
$ svn mkdir --parents file:///%CD%/repos/A/B/C -m ""
$ svn cp file:///%CD%/repos/A file:///%CD%/repos/AA -m ""
$ svn co file:///%CD%/repos/A A
$ svn switch ^/AA/B A/B
$ svn rm file:///%CD%/repos/AA
$ svn up A
On 1.7 this reproduces your issue
And a
$ svn up A/B
Will bring back the missing directory.
When trying the same thing on trunk I found a completely different issue,
where the complete update failed. I'm not going to bother you with the
details of this report, as thanks to your bug report that huge regression
will never be in a released version of Subversion. (Thanks!!!)
To close issue #4295, I added a small check to the update code that handles
incoming deletes. When it encounters a delete of a switched path it will now
place a similar hidden marker as you would get when you update a path to r0
(or commit a file delete). The next update will now bring in the missing
node.
I will nominate the fix for backporting to a future 1.7 release.
Bert
From: Maxwell Ballenger [mailto:Maxwell.Ballenger@spacex.com]
Sent: zaterdag 19 januari 2013 00:44
To: users@subversion.apache.org
Subject: Working copy corrupted by branch deletion
Hi Subversion Users,
We're experiencing some new behavior after upgrading from TortoiseSVN 1.6.14
(Subversion client library 1.6.16) to TortoiseSVN 1.7.10 (Subversion client
library 1.7.7). We noticed this using TortoiseSVN, but some folks on their
mailing list believe that this is a result of the Subversion client library,
not Tortoise. I am not sure whether this is a bug or intended behavior. Here
is what happens:
1. Branch a subfolder of your working copy
2. Switch that subfolder onto that branch
3. Delete that branch using another working copy or the repo-browser
4. Update your working copy
5. That subfolder disappears. There is no way to recover that subfolder and
have your working copy match the trunk again without doing a fresh checkout.
In TortoiseSVN 1.6.14 (Subversion 1.6.16), a mistake like this was much
easier to recover from. Commanding a switch of a parent folder to trunk
would restore the missing subfolder.
Is this intended behavior, or could it qualify for a bug fix? Does anyone
know of a faster way to recover than a fresh checkout?
Thanks!
Max Ballenger
RE: Working copy corrupted by branch deletion
Posted by Bert Huijben <be...@qqmail.nl>.
I'm not 100% sure how to reproduce this yet, but updating the folder to r0
and then updating it again should give you all children again. (You can also
use -set-depth excluded, and then an explicit update on the target)
I don't have suggestions on how you can do this with TortoiseSVN.
Bert
From: Maxwell Ballenger [mailto:Maxwell.Ballenger@spacex.com]
Sent: zaterdag 19 januari 2013 00:44
To: users@subversion.apache.org
Subject: Working copy corrupted by branch deletion
Hi Subversion Users,
We're experiencing some new behavior after upgrading from TortoiseSVN 1.6.14
(Subversion client library 1.6.16) to TortoiseSVN 1.7.10 (Subversion client
library 1.7.7). We noticed this using TortoiseSVN, but some folks on their
mailing list believe that this is a result of the Subversion client library,
not Tortoise. I am not sure whether this is a bug or intended behavior. Here
is what happens:
1. Branch a subfolder of your working copy
2. Switch that subfolder onto that branch
3. Delete that branch using another working copy or the repo-browser
4. Update your working copy
5. That subfolder disappears. There is no way to recover that subfolder and
have your working copy match the trunk again without doing a fresh checkout.
In TortoiseSVN 1.6.14 (Subversion 1.6.16), a mistake like this was much
easier to recover from. Commanding a switch of a parent folder to trunk
would restore the missing subfolder.
Is this intended behavior, or could it qualify for a bug fix? Does anyone
know of a faster way to recover than a fresh checkout?
Thanks!
Max Ballenger