Issue
Basically, subversion 1.7 Windows command line client cannot make svn copy URL -> WC if the URL contains externals. It adds it to the working copy index, but cannot finish the operation due to fail like this:
svn: E720005: Can't move 'C:\svncopy-tools\svncopy_2pgsxIK_6s\stable1\.svn\tmp\svn-256CA474' to 'C:\svncopy-tools\svncopy_2pgsxIK_6s
\stable1\ExternalsContainer': Access is denied.
Here you can find the zipped reproducing script I have constructed according to recommendations.
Versions that have the issue: 1.7.1, 1.7.2.
Versions that do not have the issue: 1.6.*
UPD: The issue is acknowledged in dev@subversion.apache.org. But there is still no any estimate when it will be fixed. At the moment, it is being discussed if they have to include the code of the fix into Windows client only, or into all clients supported.
Solution.
Regrettably, I found no solution at the moment. As a workaround, you can use subversion 1.6 client, if you really need this workflow. I really need it, because this command workflow is used in svncopy.pl contribution script, and this script is used in my environment.
I think, we have to report the bug and wait for fix. I have reported it to users@subversion.apache.org, as recommended on http://subversion.apache.org/docs/community-guide/issues.html, and then it has been moved forward with reporting this issue to subversion development team.
Non-trivial IT technical issues, causes and solutions or workarounds.
Software Engineering is my primary game.
See also my technical reading feed
Thursday, February 16, 2012
Wednesday, February 1, 2012
Subversion 1.7, file & folders manipulation and Checksum mismatch error
Issue
In Subversion 1.6, we have got accustomed to manipulating working copy sub-directories as we wish, having a way to easily restore broken folder working copy. We performed it by deleting the problem folder and getting it fresh again by running svn update command.
After upgrading to 1.7, during such manipulation, we often encounter error like this:
svn: E155017: Checksum mismatch for 'D:\project\Aggregation\Service.cs':
expected: c446841fc97da2f6399ac77e334f2be2
recorded: 0a896afb3a1923f11ef3794e2aae428b
Any attempt to remove folder and get it updated again does not fix the problem. Checksum mismatch appears on commit, revert or other operations with the working copy.
Cause
Subverion 1.6 stored the working copy cached repository information, like base revision files and their hashes, in every directory. Owing to this, a lot of folders .svn were located in the working copy, and we had to deal with them if we tried to copy or move parts of our working copy without exporting them. But this allowed such manipulation as I described above.
Subverion 1.7 stores this stuff in the working copy root only (for externals, it stores it in the root of an external working copy too).
Solution (workaround)
Instead of just deleting folder and then updating it, you perform a hack with the depth of the problem folder, setting it first to empty, then to infinity:
D:\project\Aggregation\> svn update --set-depth empty
D Service.cs
Updated to revision 156.
D:\project\Aggregation\> svn update --set-depth infinity
A Service.cs
Updated to revision 156.
It will remove the cached information about the problem directory from the working copy "cash-hash", and then restore it again with the actual information from the repository. So the error should disappear.
Related links
This link is about Checksum mismatch error too, but it seems to solve another problem, and not related to 1.6-1.7 upgrade issues.
In Subversion 1.6, we have got accustomed to manipulating working copy sub-directories as we wish, having a way to easily restore broken folder working copy. We performed it by deleting the problem folder and getting it fresh again by running svn update command.
After upgrading to 1.7, during such manipulation, we often encounter error like this:
svn: E155017: Checksum mismatch for 'D:\project\Aggregation\Service.cs':
expected: c446841fc97da2f6399ac77e334f2be2
recorded: 0a896afb3a1923f11ef3794e2aae428b
Cause
Subverion 1.6 stored the working copy cached repository information, like base revision files and their hashes, in every directory. Owing to this, a lot of folders .svn were located in the working copy, and we had to deal with them if we tried to copy or move parts of our working copy without exporting them. But this allowed such manipulation as I described above.
Subverion 1.7 stores this stuff in the working copy root only (for externals, it stores it in the root of an external working copy too).
Solution (workaround)
Instead of just deleting folder and then updating it, you perform a hack with the depth of the problem folder, setting it first to empty, then to infinity:
D:\project\Aggregation\> svn update --set-depth empty
D Service.cs
Updated to revision 156.
D:\project\Aggregation\> svn update --set-depth infinity
A Service.cs
Updated to revision 156.
It will remove the cached information about the problem directory from the working copy "cash-hash", and then restore it again with the actual information from the repository. So the error should disappear.
Related links
- http://glob.bushi.net.nz/glob/2007/02/14/subversion-checksum-mismatch-easy-workaround/
This link is about Checksum mismatch error too, but it seems to solve another problem, and not related to 1.6-1.7 upgrade issues.
here's how we check out a second copy of the relevant directory, and swap it in. optionally then copying over any other corrupted files etc. you may need to add salt or sugar to suit your specific situation (ie, in my example, there are no subdirectories blocked by the corrupted file)
- PROBLEM: i can't check in the file 'lib/objects/blah.ext' because i get the error:
svn: Checksum mismatch for '.svn/text-base/blah.ext'; expected: 'f8d45250f7df5561635854165862fdd8', actual: '644f85c4befa671150c5c6ec5fad9885'
Subscribe to:
Posts (Atom)