svn checksum mismatch解决办法之一
来源:互联网 发布:开淘宝店的银行卡 编辑:程序博客网 时间:2024/06/07 02:59
将要提交的文件(提交该文件时出现checksum mismatch错误)所在目录的.svn文件夹替换为最新(svn服务器上的.svn文件夹)的即可!
参考:
----------------------------------------------------------------------------------------------------------------------------------------
How-to recover from checksum mismatch errors in SVN
You know Coda, the text editor I sometimes rave about? Like many text editors, it has this handy feature for doing global searches and replaces. But, unlike any other I’ve ever seen, it will happily, and without prompting for an administrator password, let you replace text in files for which you don’t have permission to write. You know, like Subversion repo copies. D’oh!
Don’t get me wrong. I love Coda. I love it enough to choose to spend most of every day with it front-and-center on my screen. But, for the life of me, I can’t imagine why it allows me to replace, without prompting me for an administrator password, text in a file with the following permissions:
-r--r--r--
For the uninitiated, the distinct lack of w’s in that line is supposed to mean that the file is read-only.
Enough, already! Show me how to fix it!
Whatever the reason, Coda changed the files, which just happened to be the Subversion (SVN) reference versions of some of my repository files. The next time I tried to commit changes to my repository, I got an error message something like the following:
svn: Checksum mismatch for '.svn/text-base/blah.ext';
expected: 'f8d45250f7df5561635854165862fdd8',
actual: '644f85c4befa671150c5c6ec5fad9885'
The above is actually taken straight from an article called “subversion checksum mismatch - easy workaround.” I’m glad I found the article because it helped me fix the problem. Contrary to the title of the blog post, however, I didn’t find Chris’s instructions all that clear, so I thought I’d take a shot at explaining it in a way that is maybe a little easier to follow.
A side trip down Background Lane
Feel free to skip this section if you are familiar with how SVN works or are just in a hurry to fix your issue and get on with life!
SVN is software that helps you track revisions to files. As such, it is very important for SVN to know when a file changes. SVN stores information about every change made to files under its control locally in plain text files inside hidden .svn directories. Trust me, you don’t want to edit those files directly.
Before committing (saving) a file, SVN compares the latest revision of the file in the repository with the corresponding, locally saved, latest revision. Actually, it doesn’t compare the files directly. Instead, it compares the checksums. A checksum is a shortened hash that represents the contents of a file. If the checksum for a file changes, you know it has been altered.
Once you change a file, it’s really hard to get it back to its original state for the purposes of this check. Directly putting back the text that was changed didn’t work for me. I don’t know exactly how checksums are calculated, but it could be that they’re based on the contents of the file plus some meta-data (like the last modified date) or else I just missed some of the changes.
In any case, I was having a bugger of a time with this, until I discovered the above-linked article. Then, I was, to quote The Proclaimers, on my way from misery to happiness. Uh-huh. Uh-huh.
Enough, already! Show me how to fix it!
The process we will follow to restore the repo to a state where we can commit entails the following steps:
Check out the latest revision of the corrupted directory into a temporary directory
Delete the munged SVN revision files
Copy the correct SVN revision files into the working directory
As you can see, it’s not difficult. You just have to know where to look for the correct files to swap out.
A benefit of my way over other procedures I’ve seen described is that I didn’t have to do anything special to get back to a state where I could commit the latest changes I had made. After doing the above, SVN told me I had changes to commit. I committed them, and I was done.
Ominous disclaimer: what I am describing worked for me, for text files. It may not work for you. It should work for binary files, but I haven’t personally tried it. Following this procedure, you may lose your life’s work, putting you on an irreversible path to destitution and despair. You have been warned.
OK, now that you’re too scared out of your wits to try them, know that these steps have face validity and worked in my case. If that’s enough assurance for you, let’s get this road on the show.
The following are the commands I used to restore my repo. The paths and filenames have been changed to protect the innocent. Also, I am describing the process for Mac OS X, so if you’re on a different operating system, make the proper adjustments.
Open Terminal.app or your command line interface of choice
Change to a directory that is not under version control. /tmp works nicely:
$ cd /tmp
Checkout the latest revision of the corrupted directory:
$ svn co svn://me@myserver/path/to/directory
Change into the directory that holds the SVN revision files:
$ cd directory/.svn/text-base/
Open a second terminal window and change into the directory with the corrupted revision files:
$ cd /path/to/working/directory/.svn/text-base/
At this point, if you were to list the contents of the text-base directories in both windows, they should be identical and consist of a list something like the following:
$ ls -la
drwxr-xr-x 31 andrew andrew 1054 24 Jan 14:52 .
drwxr-xr-x 8 andrew andrew 272 25 Jan 15:50 ..
-r--r--r-- 1 andrew andrew 198 16 Nov 18:21 .project.svn-base
-r--r--r-- 1 andrew andrew 27 19 Dec 09:27 myTextFile.svn-base
In the second window (the one with your working copy), delete the corrupted revision files. If you know which one(s) they are, just delete them. Otherwise, you can delete everything in this directory:
$ sudo rm *
(Note for the paranoid: you could backup this directory before performing this step if you want. I figured why bother since it’s corrupted already and I had a backup in the form of the newly checked out version in /tmp)
Back in the first window, copy the contents of the text-base directory into your working directory:
$ sudo cp * /path/to/working/directory/.svn/text-base/
That’s it. You should now be able to commit to your heart’s content.
参考:
----------------------------------------------------------------------------------------------------------------------------------------
How-to recover from checksum mismatch errors in SVN
You know Coda, the text editor I sometimes rave about? Like many text editors, it has this handy feature for doing global searches and replaces. But, unlike any other I’ve ever seen, it will happily, and without prompting for an administrator password, let you replace text in files for which you don’t have permission to write. You know, like Subversion repo copies. D’oh!
Don’t get me wrong. I love Coda. I love it enough to choose to spend most of every day with it front-and-center on my screen. But, for the life of me, I can’t imagine why it allows me to replace, without prompting me for an administrator password, text in a file with the following permissions:
-r--r--r--
For the uninitiated, the distinct lack of w’s in that line is supposed to mean that the file is read-only.
Enough, already! Show me how to fix it!
Whatever the reason, Coda changed the files, which just happened to be the Subversion (SVN) reference versions of some of my repository files. The next time I tried to commit changes to my repository, I got an error message something like the following:
svn: Checksum mismatch for '.svn/text-base/blah.ext';
expected: 'f8d45250f7df5561635854165862fdd8',
actual: '644f85c4befa671150c5c6ec5fad9885'
The above is actually taken straight from an article called “subversion checksum mismatch - easy workaround.” I’m glad I found the article because it helped me fix the problem. Contrary to the title of the blog post, however, I didn’t find Chris’s instructions all that clear, so I thought I’d take a shot at explaining it in a way that is maybe a little easier to follow.
A side trip down Background Lane
Feel free to skip this section if you are familiar with how SVN works or are just in a hurry to fix your issue and get on with life!
SVN is software that helps you track revisions to files. As such, it is very important for SVN to know when a file changes. SVN stores information about every change made to files under its control locally in plain text files inside hidden .svn directories. Trust me, you don’t want to edit those files directly.
Before committing (saving) a file, SVN compares the latest revision of the file in the repository with the corresponding, locally saved, latest revision. Actually, it doesn’t compare the files directly. Instead, it compares the checksums. A checksum is a shortened hash that represents the contents of a file. If the checksum for a file changes, you know it has been altered.
Once you change a file, it’s really hard to get it back to its original state for the purposes of this check. Directly putting back the text that was changed didn’t work for me. I don’t know exactly how checksums are calculated, but it could be that they’re based on the contents of the file plus some meta-data (like the last modified date) or else I just missed some of the changes.
In any case, I was having a bugger of a time with this, until I discovered the above-linked article. Then, I was, to quote The Proclaimers, on my way from misery to happiness. Uh-huh. Uh-huh.
Enough, already! Show me how to fix it!
The process we will follow to restore the repo to a state where we can commit entails the following steps:
Check out the latest revision of the corrupted directory into a temporary directory
Delete the munged SVN revision files
Copy the correct SVN revision files into the working directory
As you can see, it’s not difficult. You just have to know where to look for the correct files to swap out.
A benefit of my way over other procedures I’ve seen described is that I didn’t have to do anything special to get back to a state where I could commit the latest changes I had made. After doing the above, SVN told me I had changes to commit. I committed them, and I was done.
Ominous disclaimer: what I am describing worked for me, for text files. It may not work for you. It should work for binary files, but I haven’t personally tried it. Following this procedure, you may lose your life’s work, putting you on an irreversible path to destitution and despair. You have been warned.
OK, now that you’re too scared out of your wits to try them, know that these steps have face validity and worked in my case. If that’s enough assurance for you, let’s get this road on the show.
The following are the commands I used to restore my repo. The paths and filenames have been changed to protect the innocent. Also, I am describing the process for Mac OS X, so if you’re on a different operating system, make the proper adjustments.
Open Terminal.app or your command line interface of choice
Change to a directory that is not under version control. /tmp works nicely:
$ cd /tmp
Checkout the latest revision of the corrupted directory:
$ svn co svn://me@myserver/path/to/directory
Change into the directory that holds the SVN revision files:
$ cd directory/.svn/text-base/
Open a second terminal window and change into the directory with the corrupted revision files:
$ cd /path/to/working/directory/.svn/text-base/
At this point, if you were to list the contents of the text-base directories in both windows, they should be identical and consist of a list something like the following:
$ ls -la
drwxr-xr-x 31 andrew andrew 1054 24 Jan 14:52 .
drwxr-xr-x 8 andrew andrew 272 25 Jan 15:50 ..
-r--r--r-- 1 andrew andrew 198 16 Nov 18:21 .project.svn-base
-r--r--r-- 1 andrew andrew 27 19 Dec 09:27 myTextFile.svn-base
In the second window (the one with your working copy), delete the corrupted revision files. If you know which one(s) they are, just delete them. Otherwise, you can delete everything in this directory:
$ sudo rm *
(Note for the paranoid: you could backup this directory before performing this step if you want. I figured why bother since it’s corrupted already and I had a backup in the form of the newly checked out version in /tmp)
Back in the first window, copy the contents of the text-base directory into your working directory:
$ sudo cp * /path/to/working/directory/.svn/text-base/
That’s it. You should now be able to commit to your heart’s content.
0 0
- svn checksum mismatch解决办法之一
- SVN checksum mismatch
- svn: Checksum mismatch for
- svn: Checksum mismatch for
- SVN:checksum mismatch的解决方案
- svn:Checksum mismatch while updating
- 报错svn: E200014: Checksum mismatch for
- SVN提交出现Checksum mismatch for '.........';
- svn报错“Checksum mismatch for”解决方案
- svn: Checksum mismatch for 报错
- svn报错:svn: E155017: Checksum mismatch for
- Fix Subversion “checksum mismatch” error by editing .svn/entries file
- svn提交失败: Checksum mismatch for(转)
- svn Checksum mismatch ………… 问题
- 解决SVN提交失败 svn: Commit failed (details follow): A checksum mismatch occurred svn: /xxx.java
- svn: Checksum mismatch while updating 'D:\workspace\demo\test\.svn\text-base\test.php.svn-base'
- SVN快捷临时解决问题 (如报 svn: Checksum mismatch while updating ..... )
- svn更新报错:svn:Checksum mismatch while updating;expected: '9a8c8856b74e4545bf2e52e2b54b23a6', actual: '
- Android四大基本组件介绍与生命周期
- svn 版本库数据的移植:svnadmin dump、svnadmin load 导出
- svn由于目标计算机积极拒绝 无法连接
- Nutch1.7学习笔记2:基本工作流程分析
- 配置h2数据库
- svn checksum mismatch解决办法之一
- ios 学习总结之动画
- qt学习之个人画板的实现(3)
- Nutch1.7学习笔记3:Injector源代码分析
- POJ - 2965 - The Pilots Brothers' refrigerator (高效贪心!!)
- 使用高德地图时工程配置
- cvSetCaptureProperty
- Nutch1.7学习笔记4:Generator源代码分析
- Listener与Adapter比较区别