SVN 체크섬 복구

SVN 체크섬 복구

---

Flex Builder 3에서 subclipse를 사용하고 있는데 최근 커밋하려고 할 때이 오류가 발생했습니다.

svn: Checksum mismatch for '/Users/redacted/Documents/Flex Builder 3/path/to/my/file.mxml'; expected: 'f8cb275de72776657406154dd3c10348', actual: 'null'

나는 다음과 같이 일했다.

1. 다른 모든 변경된 파일을 커밋하고 번거로운 파일을 생략합니다.
2. 문제 파일의 내용을 TextMate 창에 복사
3. FlexBuilder / Eclipse에서 내 프로젝트 삭제
4. SVN에서 내 프로젝트 확인
5. TextMate 창에서 문제 파일의 텍스트를 다시 복사
6. 변경 사항을 커밋합니다.

효과가 있었지만 더 나은 방법이 있다고 생각합니다. svn : checksum 오류의 원인이되는 현상은 무엇이며 최선의 해결책은 무엇입니까?

더 중요 할 수도 있습니다. 이것이 더 큰 문제의 증상입니까?

---

.svn 디렉토리에있는 파일은 특정 파일에 대해 체크 아웃 한 내용,시기, 개정판 및 위치를 추적합니다.

이것은 정상적인 홀수 파일 문제보다 더 위험하거나 중요하지 않으며, 변경 도중에 죽어가는 Subversion 프로그램, 전원 중단 등과 같은 다양한 문제 때문일 수 있습니다.

더 많은 일이 일어나지 않는 한 나는 그것을 많이 얻지 못할 것입니다.

수행 한 작업을 수행하고, 작업 파일의 복사본을 만들고, 새 복사본을 확인하고, 수정 된 파일을 다시 추가하여 문제를 해결할 수 있습니다.

일반적으로 변경 사항을 병합해야하는 바쁜 프로젝트가있는 경우 이로 인해 문제가 발생할 수 있습니다.

예를 들어, 귀하와 동료는 모두 새 복사본을 확인하고 동일한 파일에서 작업을 시작합니다. 어느 시점에서 동료가 수정 사항을 확인합니다. 같은 작업을 시도하면 체크섬 문제가 발생합니다. 이제 변경된 파일의 복사본을 만들고 새로 체크 아웃하면 Subversion이 변경 사항을 다시 병합하는 방법을 추적하지 못합니다.

이 경우 문제가 발생하지 않은 경우 수정 사항을 체크인 할 때 먼저 작업 복사본을 업데이트하고 파일과의 충돌을 처리해야합니다.

그러나 동료 변경 사항을 완료하고 새로운 체크 아웃을 수행하면 이제 변경 사항을 제거하고 자신의 변경 사항으로 대체 한 것처럼 보입니다. 갈등이 없으며 전복에서 무언가 잘못되었다는 표시가 없습니다.

---

버그 나 디스크 손상 등의 단순한 원인도 있습니다.이 문제가 발생할 가능성이 가장 높은 원인은 누군가가 .svn 파일을 제외하지 않고 작업 복사본에 재귀 적 텍스트 대체를 작성할 때 발생한다고 생각합니다.
즉, 파일의 원시 복사본 (기본적으로 .svn 관리 영역에 저장된 파일의 BASE 버전)이 수정되어 MD5 합계가 무효화됩니다.

@Andrew Hedges : 솔루션이이 문제를 해결하는 이유도 설명합니다.

---

SVN은 체크 아웃 한 모든 파일의 원본을 .svn 디렉토리에 보관합니다. 이것을 텍스트베이스라고합니다. 이를 통해 신속한 비교 및 ​​복귀가 가능합니다. 다양한 작업 중에 SVN은 이러한 텍스트 기반 파일에 대해 체크섬을 수행하여 파일 손상 문제를 포착합니다.

일반적으로 SVN 체크섬 불일치는 변경해서는 안되는 파일이 어떻게 든 변경되었음을 의미합니다. 그게 무슨 뜻입니까?

1. 디스크 손상 (불량 HDD 또는 IDE 케이블)
2. 불량 RAM
3. 잘못된 네트워크 링크
4. 어떤 종류의 백그라운드 프로세스로 인해 파일이 변경되었습니다 (멀웨어).

이 모든 것은 나쁘다.

그러나 나는 당신의 문제가 다르다고 생각합니다. 오류 메시지를보십시오. 일부 MD5 해시를 예상했지만 대신 'null'로 돌아 왔습니다. 이것이 단순한 파일 손상 문제 였다면 예상 / 곳에 대해 두 개의 다른 MD5 해시가있을 것으로 예상합니다. 'null'이 있다는 사실은 다른 것이 잘못되었음을 의미합니다.

두 가지 이론이 있습니다.

1. SVN의 버그.
2. 파일에 대한 배타적 잠금이 발생하여 MD5가 발생할 수 없습니다.

# 1의 경우 최신 SVN 버전으로 업그레이드하십시오. svn-devel 메일 링리스트 ( http://svn.haxx.se ) 에 이것을 게시 하여 개발자가 볼 수 있도록 할 수도 있습니다.

# 2의 경우 파일이 잠긴 것이 있는지 확인하십시오. Process Explorer의 사본을 다운로드하여 확인할 수 있습니다. 커밋하려는 실제 파일이 아닌 텍스트 기반 파일 에 대한 잠금을 가진 사람을보고 싶을 것입니다 .

---

나는 때때로 비슷한 것을 얻습니다. 보통 몇 주 동안 아무도 근처에 없었던 파일을 가지고 있습니다. 일반적으로 해당 디렉토리에서 작업하지 않았다는 것을 알고 있다면 문제가있는 디렉토리를 삭제하고 다음을 실행할 수 있습니다.

svn update

그것을 재현합니다.

디렉토리에 라이브 변경 사항이있는 경우 lassevk와 자신이 제안한대로보다 신중한 접근 방식이 필요합니다.

일반적으로 편집 된 파일을 커밋하지 않은 채로 두지 않고 작업 복사본을 깔끔하게 유지하는 것이 좋습니다. 사용하지 않을 작업 복사본에 많은 파일을 추가하지 마십시오. 정기적으로 커밋 한 다음 작업 복사본이 커지면 전체 내용을 삭제하고 잃어 버릴 수있는 내용에 대해 걱정하지 않고 다시 시작할 수 있으며 저장할 파일을 파악하려고 노력하지 않아도됩니다.

---

바로 오늘, 손상된 디렉토리의 복사본을 / tmp에 체크 아웃하고 .svn / text-base의 파일을 방금 만든 파일로 대체하여이 오류를 복구했습니다. 나는 여기 내 블로그에 절차를 좀 더 자세히 썼다 . 경험이 많은 SVN 사용자로부터 각 접근 방식의 장점과 단점이 무엇인지 듣고 싶습니다.

---

시도 : svn up --force file.c

이것은 추가 작업을 수행하지 않고도 나를 위해 일했습니다.

---

.svn / entries 파일 패치부터 새로운 체크 아웃까지 많은 솔루션을 관찰했습니다.

새로운 방법이 될 수 있습니다 (동료에게 감사합니다).

- go to work directory where recorder/expected checksum issue occured
- call "svn diff" and make sure that there isnt any local modifications
- cd ..
- remove trouble file's directory with "rm -rf"
- issue "svn up" command, svn client will restore new fresh files copies

---

Matt, .svn / entries 파일에서 체크섬을 수정하는 것보다 더 쉬운 방법이 있습니다. 전체 설명은 다음과 같습니다. http://maymay.net/blog/2008/06/17/fix-subversion-checksum-mismatch-error-by-editing-svnentries-file/

---

내가 찾은 체크섬 충돌에 대한 또 다른, 아마도 더 무서운 해결 방법은 다음과 같습니다.

주의 : 로컬 사본이 가장 잘 알려진 버전인지, 프로젝트의 다른 사람이 당신이하고있는 일을 알고 있는지 확인하십시오! (이미 명확하지 않은 경우).

파일의 로컬 사본이 "좋은 것"이라는 것을 알고 있다면 SVN 서버에서 파일을 직접 삭제 한 다음 로컬 사본을 강제로 커밋 할 수 있습니다.

직접 삭제 구문 :

svn delete -m "deleting corrupted file XXXX" 
svn+ssh://username@svnserver/path/to/XXXX

행운을 빕니다!

제이

---

새 복사본 (다른 모든 옵션을 시도한 후 수행해야 함)을 확인하는 대신 이전에 저장 한 모든 변경 사항을 병합하는 것보다 다음 접근 방식이 동일한 방식으로 작동했지만 상당한 양을 절약했습니다. 시간 및 가능한 일부 오류 :

1. 새로운 작업 사본 확인
2. 새 복사본의 .svn 폴더를 손상된 복사본으로 복사하십시오.
3. Voila

Of course, you should backup your original corrupt working copy just in case. In my case, I was free to remove it after I was done, as everything went fine.

---

This will happens when the .svn folder corrupted. Solution: Remove the entire folder of the file contains and checkout the folder again.

---

Had this issue, our dev VM's are all *nix our workstations win32. some fool(s) created files of the same name (different case) on the *nix box all of a sudden checkouts on Win32 blows up... because win doesn't know which of the 2 files of the same name to MD5 against, checkouts on *nix were fine... leaving us to scratch our heads for a bit

I was able to update the repo on the win box by copying the ".svn" folders over from a *nix box with a good working copy. have yet to see if the repo can be cleaned to the point where we can do a full checkout again

---

One other easy way....

1. Update your project to get latest version
2. checkout the same version in an other folder
3. replace .svn folder from the new checkout to the working copy ( i've replaced .svn-base files )

---

1. Check out only folder with problematic file from repository to some other location.
2. Make sure .svn\text-base\<problematic file>.svn-base is identical to one checked out.
3. Make sure problematic file section (all lines of the section) in .svn\entries is identical to one checked out.

---

You won't believe this, but I have actually fixed my error by removing the <scm>...</scm> stance from the offending pom.xml file I was hoping to check in. It contained the URL of the subversion repository it is checked in (this is what the Maven setting is for!), but somehow it generated a faulty checksum for the file while checking in.

I literally tried all aforementioned methods of fixing this, but to no avail. Did I encounter a very rare situation in where the checksum generator is not robust enough?

---

I also stumbled upon this issue and was trying to look for quick solutions, tried some of the solution given in this thread. This is how I resolved this issue in my development environment (to me it was minimal change):

1- Locally deleted directory in which the file got corrupted (WEB-INF):

 svn: Checksum mismatch for 'path-to-folder\WEB-INF\web.xml':
   expected:  d60cb051162e4a6790a3ea0c9ddfb434
     actual:  16885ded2cbc1adc250e4cbbc1427546

2- Copied and pasted directory (WEB-INF) from a fresh checkout

3- Did svn up, now Eclipse/TortoiseSVN started showing conflict in this directory

4- Marked conflict as Resolved

This worked, I was able to update, commit earlier corrupted web.xml

---

In my case the sum was different. All I've done was:

1) Make Check Out to separate folder

2) Replace by file from this folder in .svn directory with my project problem-file which was said in svn-client error message

3) ..Profit!

---

Although this is an old issue, I thought I would give my 2 cents as well, since Ive just wrestled with the problem for more than an hour.

The solutions above either didn't work for me, or seemed over-complicated.

My solution was simply to remove all svn folders from the project.

find . -name .svn -exec rm -rf {} \;

After this, I did simple checkout of the project again. Thus leaving all my un-committed files intact, but still got a rebuild of all the svn files.

---

I had this problem on ubuntu 14.04 and solve it by follow steps:

1. $ cd /var/www/myProject
2. $ svn upgrade
3. $ svn update

after these steps i could commit file without error.

---

1. Go to the folder causing problem
2. Execute command svn update --set-depth empty
3. This folder will empty and revert the empty folder
4. Sync with the svn and update.

This work for me.

---

here's how i fixed the issue - v simple, but as per jsh above, need to be sure your copy is the best one.

simply

1. make a copy all problem files, in the same folder.
2. delete the old ones with svn rm
3. commit.
4. then rename the copies back to the original file names.
5. commit again.

suspect this probably kills all sorts of revision history on that file, so it's a pretty ugly way to go about it...

참고URL : https://stackoverflow.com/questions/6130/repair-svn-checksum