•  08-06-2019
  •  | 
  •  

문제

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은 변경 사항을 다시 병합하는 방법을 추적하지 못하게 됩니다.

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

그러나 새로 결제를 수행하고 동료의 변경 사항을 완료하면 이제 동료의 변경 사항을 제거하고 자신의 변경 사항으로 대체한 것처럼 보입니다.충돌도 없고 무언가 잘못되었다는 전복의 징후도 없습니다.

다른 팁

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

@앤드류 헤지스:이는 귀하의 솔루션이 이 문제를 해결하는 이유도 설명합니다.

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

물론 만약을 대비해 손상된 원본 작업 복사본을 백업해야 합니다.제 경우에는 모든 것이 잘 진행되었기 때문에 작업이 끝난 후 자유롭게 제거할 수 있었습니다.

.svn 폴더가 손상되면 이런 일이 발생합니다.해결책:해당 파일이 포함된 전체 폴더를 제거하고 해당 폴더를 다시 체크아웃하세요.

이 문제가 발생하면 개발 VM은 모두 *nix 워크스테이션 win32입니다.일부 바보는 *nix 상자에 같은 이름 (다른 경우)의 파일을 생성했습니다.WIN은 MD5에 동일한 이름의 두 파일 중 어느 것을 알지 못하기 때문에 *닉스의 체크 아웃은 괜찮 았습니다 ...잠시 머리를 긁적거리게 놔두고

좋은 작업 복사본이 있는 *nix 상자에서 ".svn" 폴더를 복사하여 win 상자의 저장소를 업데이트할 수 있었습니다.전체 체크아웃을 다시 수행할 수 있을 정도로 저장소를 정리할 수 있는지 아직 확인하지 못했습니다.

또 하나의 쉬운 방법....

  1. 최신 버전을 얻으려면 프로젝트를 업데이트하세요.
  2. 다른 폴더에서 동일한 버전을 체크아웃
  3. .svn 폴더를 새 체크아웃에서 작업 복사본으로 교체합니다(.svn-base 파일을 교체했습니다).
  1. 문제가 있는 파일이 있는 폴더만 저장소에서 다른 위치로 체크아웃하세요.
  2. 확실하게 하다 .svn\text-base\<problematic file>.svn-base 체크아웃한 것과 동일합니다.
  3. 문제가 있는 파일 섹션을 확인하세요. (섹션의 모든 라인) ~에 .svn\entries 체크아웃한 것과 동일합니다.

당신은 이것을 믿지 않을 것이지만 나는 실제로 오류를 제거하여 오류를 수정했습니다. <scm>...</scm> 체크인하려고 했던 문제가 있는 pom.xml 파일의 입장입니다.여기에는 체크인된 Subversion 저장소의 URL이 포함되어 있지만(이것이 Maven 설정의 목적입니다!) 체크인하는 동안 파일에 대해 잘못된 체크섬이 생성되었습니다.

이 문제를 해결하기 위해 앞서 언급한 모든 방법을 문자 그대로 시도했지만 소용이 없었습니다.체크섬 생성기가 충분히 강력하지 않은 매우 드문 상황이 발생했습니까?

나는 또한 이 문제를 우연히 발견했고 빠른 해결책을 찾으려고 노력했으며 이 스레드에 제공된 해결책 중 일부를 시도했습니다.이것이 내 개발 환경에서 이 문제를 해결한 방법입니다(나에게는 최소한의 변경이었습니다).

1- 파일이 손상된 로컬에서 삭제된 디렉터리(WEB-INF):

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

2- 새로운 결제에서 디렉터리(WEB-INF)를 복사하여 붙여넣었습니다.

3- svn을 실행했습니다. 이제 Eclipse/TortoiseSVN이 이 디렉토리에 충돌을 표시하기 시작했습니다.

4- 해결된 충돌로 표시

이것은 효과가 있었고 이전에 손상된 web.xml을 업데이트하고 커밋할 수 있었습니다.

내 경우에는 합계가 달랐다.내가 한 일은 다음과 같습니다.

1) 별도의 폴더로 체크아웃합니다.

2) .svn 디렉토리에 있는 이 폴더의 파일을 svn-client 오류 메시지에 표시된 내 프로젝트 문제 파일로 대체합니다.

3) ..이익!

오래된 문제이긴 하지만, 한 시간 넘게 그 문제와 씨름을 했으니 2센트라도 주겠다고 생각했습니다.

위의 솔루션은 나에게 적합하지 않거나 지나치게 복잡해 보였습니다.

내 솔루션은 단순히 프로젝트에서 모든 svn 폴더를 제거하는 것이었습니다.

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

그 후, 나는 프로젝트의 간단한 체크아웃을 다시 했습니다.따라서 커밋되지 않은 모든 파일은 그대로 유지하지만 여전히 모든 svn 파일을 다시 빌드했습니다.

우분투 14.04에서 이 문제가 발생했으며 다음 단계에 따라 해결했습니다.

  1. $ cd /var/www/myProject
  2. $ svn 업그레이드
  3. $ svn 업데이트

이 단계 후에는 오류 없이 파일을 커밋할 수 있습니다.

  1. 문제가 발생한 폴더로 이동
  2. 명령 실행 svn update --set-depth empty
  3. 이 폴더는 비워지고 빈 폴더로 되돌아갑니다.
  4. svn과 동기화하고 업데이트하세요.

이것은 나에게 효과적입니다.

문제를 해결한 방법은 다음과 같습니다. 간단하지만 위의 jsh에 따라 복사본이 가장 좋은지 확인해야 합니다.

간단히

  1. 모든 문제 파일을 동일한 폴더에 복사하십시오.
  2. svn rm으로 오래된 것을 삭제하세요
  3. 저지르다.
  4. 그런 다음 복사본의 이름을 원래 파일 이름으로 다시 바꿉니다.
  5. 다시 커밋하십시오.

이것이 아마도 해당 파일의 모든 종류의 개정 기록을 죽일 것이라고 생각하므로 이에 대해 처리하는 것은 꽤 추악한 방법입니다...

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top