SVN에서“작업 복사본 관리 영역이 포함되어 있지 않습니다”를 수정하는 방법은 무엇입니까?


184

내 저장소에서 오프라인으로 방금 추가 한 디렉토리를 수동으로 삭제했습니다. 디렉토리를 복원 할 수 없습니다.

업데이트 또는 커밋 시도는 다음과 같이 실패합니다.

"blabla/.svn" containing working copy admin area is missing.

이유를 이해하지만 어쨌든이 문제를 해결해야합니다.

전체 저장소를 체크 아웃하고 변경 사항을 수동으로 추가하지 않으려면 몇 시간이 걸립니다.

답변:


148

이것에 따르면 : http://www.devcha.com/2008/03/svn-directory-svn-using-working.html

"blabla"폴더를 다른 위치로 체크 아웃 한 다음 .svn 폴더를 원래 "blabla"로 다시 복사하십시오.


62
SVN이 너무 많습니다. .svn모든 곳의 쓰레기 하위 디렉토리는 버전 관리 기록에서 최악의 아이디어였습니다.
Johannes Fahrenkrug 2016 년

9
여러분, Rob의 아래 제안을 확인하십시오. 현재 솔루션보다 훨씬 쉽습니다.
Mohammad Arif 2016 년

모하메드, 고마워 그것은 나를 위해 일했다. SVN이 로그 디렉토리를 무시하도록하고 .svn을 삭제하면이 문제가 발생했습니다. Rob의 솔루션이 해결했습니다.
Asmor

Johannes, 나는 SVN의 지지자도 아니지만 .svn 디렉토리의 장점은 저장소의 하위 디렉토리를 체크 아웃하고 버전 제어를 유지할 수 있다는 것입니다.
Joseph Persie

@MohammadArif, 지금 두 개의 "Robs"가 있습니다
Charles Clayton

123

fwiw, 나는 비슷한 상황을 겪고 svn --force delete __dir__을 사용 했습니다 . 그것은 나를 위해 문제를 해결했습니다. 그런 다음 평소대로 작업 사본으로 계속 작업했습니다.


2
이것은 나를 위해 일했다. 디렉토리가 리포지토리에 없었기 때문에 업데이트 및 정리에 실패했지만 작업 복사본은 해당 디렉토리가 개정 관리 대상임을 확신했습니다. 디렉토리를 추가했는지 궁금하지만 커밋하기 전에 삭제했는지 궁금합니다.
Magnus

1
이것은 매우 좋습니다. 디렉토리를 추가하고 .svn을 삭제했지만 커밋하지 않았습니다. 이 전체가 트릭을 수행했습니다
Eric

8
감사합니다; 이 답변은 많은 시간을 절약했습니다. svn cleanup그런 다음 svn --force delete <directory-that-doesn't-exist-but-should>나를 위해 일했습니다.
mpontillo

두 번째 시도에서 처음으로 --force없이 시도했지만 수동으로 제거 해야하는 부모의 .svn에 잠금 파일을 남겼습니다. --force로 두 번째로 문제가 해결되었습니다.
Jörn Horstmann

3
흠, 그 명령은 단순히 같은 "작업 카피"오류를 발생시킵니다.
Oscar

72

이 문제를 해결하기 위해 문제가 발생한 폴더 의 로컬 복사본 을 삭제 한 다음 svn update바로 부모를 수행했습니다.

바로 고쳤습니다.


3
나는 믿을 수 없다 ... 나는 모든 것을 시도했다. .. 그리고 그것은 그렇게 쉬웠다! !! 완벽하게 작동했습니다. 많은 감사합니다 !!!!!
lucaferrario

가장 정답입니다.
joaerl

35

부모 디렉토리의 새 사본을 체크 아웃 할 수 있습니까?

편집 : 좀 더 구체적으로 말하면 한 수준 위로 올라가고 포함 디렉토리를 삭제하는 것이 좋습니다. 그런 다음

svn update --set-depth infinity

디렉토리를 교체하십시오.


나는 그것을 시도했지만 이상한 이유로 나는 빈 디렉토리로 끝납니다. 나는 그것을 얻지 못한다 ...
전자 만족

부모의 명시적인 <code> svn update blabla </ code>도 작동해야합니다.
jmanning2k

@ jmanning2k, 그것이 저의 생각이기도하지만 OP는 그가 시도했지만 작동하지 않았다고 말했습니다.
Rob Wells

명확히하기 위해, 나는 제안 --set-depth infinity이 때문에 : stackoverflow.com/questions/866835/...
빔 COENEN

1
여기에는 훨씬 더 많은지지가 필요합니다. 빠르고 비교적 (svn 표준의 경우) 깨끗한 솔루션입니다.
디노

6

svn에 디렉토리를 추가 한 다음 실수로 .svn 폴더를 삭제했습니다.

나는 사용했다

svn delete --keep-local folderName

내 문제를 해결하기 위해.


IDE가 디렉토리를 추가했을 때 나에게 도움이되었고 같은 이름의 디렉토리를 커밋하기 전에 옮겼습니다.
quellish

이것을 시도했지만 여전히 커밋 할 수 없었습니다. svn checkout --force [url].svn 폴더를 다시 만든 것을 사용했습니다
Lex

4

방금 'svn revert / blabla'을하고 폴더가 돌아 왔으며 svn을 삭제할 수 있습니다.


감사. 나는이 문제가 있었고 당신의 제안을 시도해 보았습니다.
Boric

3

디렉토리를 저장소에 추가하려고 시도했지만 파일 시스템 권한이 충분하지 않은 경우 "작업 사본 관리 영역을 포함하는 디렉토리 'blah / .svn'이 누락되었습니다"오류가 발생했습니다. 디렉토리가 아직 저장소에 없지만 추가 실패 후 버전 제어를 받고 있다고 주장했습니다.

부모 디렉토리의 복사본을 다른 위치로 체크 아웃하고 작업 복사본의 부모 디렉토리에있는 .svn 폴더를 바꾸면 파일 권한을 수정 한 후 새 디렉토리를 성공적으로 추가하고 커밋 할 수있었습니다.


2

우리는 maven과 svn을 사용합니다. SVN에 대상 디렉토리를 잘못 체크인하여이 오류가 발생했습니다. 이 힌트가 누군가에게 도움이된다면 모든 것을 고쳤습니다.


정확히 어디에서 무엇을 제거합니까?
DerMike

maven은 빌드 할 때 "target"디렉토리를 만듭니다. 일반적으로 아무도이 중 하나를 체크인한다고 가정하지 않습니다. 악의적 인 체크인이 다음에 체크 아웃 할 때 권한 오류가 발생하여이 오류가 발생했습니다. SVN에서 "target"디렉토리를 제거하면 문제가 해결되었습니다.
Madu

2

나는 svn rm --force /path/to/dir아무 소용이 없었지만 그냥 달리는 것을 끝내고 svn up그것을 고쳤다.


1

SVN 전역의 설정으로 파일을 제외했을 때 최근 에이 오류가 발생했습니다. 리포지토리에서 파일을 직접 삭제했기 때문에 오류가 특히 심했습니다. 이는 위의 솔루션이 거부되었음을 의미합니다. 이 경우 SVN에서 제거한 디렉토리에서 .svn 디렉토리를 수동으로 삭제하면 업데이트를 실행하여 커밋 할 수있었습니다.


1

"C : \ superfolder"를 전환하려고 할 때도 같은 문제가있었습니다.

오류 메시지 :

Directory 'C:\superfolder\subfolder\.svn'
containing
working copy admin area is missing
Please execute the 'Cleanup' command.

"정리"를 시도한 후 다음 오류가 발생했습니다.

 Cleanup failed to process the following paths:
 C:\superfolder\
'C:\superfolder\subfolder\' is not a working copy directory

해결책:

  1. "하위 폴더"폴더를 삭제하십시오.
  2. "슈퍼 폴더"폴더 정리
  3. 폴더 "superfolder"를 다시 전환하십시오

이것은 나를 위해 일했습니다. 그것이 당신에게도 효과가 있는지 알려주십시오.


1

최근 에이 오류가 발생했습니다. 이 오류를 발생시키는 디렉토리에 두 개의 파일을 루트가 소유하고 있기 때문입니다.

권한을 변경 한 후 모든 것이 예상대로 작동했습니다.


1

게시물을 많이 이해하지 못했습니다. 내 해결책은

  1. 문제가있는 폴더를 잘라내어 특정 위치로 복사하십시오.
  2. Subversion에서 솔루션을 다른 작업 디렉토리 (새로운 디렉토리)로 가져 오기.
  3. 저장된 폴더를 새 작업 복사본에 추가하고 기존 프로젝트로 추가하십시오 (필자의 경우 프로젝트 인 경우).
  4. 범하다;

1

나는이 문제가 있었다. blabla를 일시적으로 다른 위치로 옮기고 svn에게 되돌 리라고 지시 한 다음 뒤로 이동하십시오. 새로운 추가로 취급됩니다. 단순한!


1

나를 도운 가장 간단한 것 :

rm -rf _dir_in_question_
svn up

문제가있는 디렉토리에 변경 사항이 있으면 이것은 좋은 해결책이 아닙니다.


1

타사 API 라이브러리를 최신 버전으로 교체 할 때이 문제가 발생했으며 SVN 버전을 로컬 버전으로 바꾸고 싶었 기 때문에 실제로 해결책이 없었습니다. 내 해결책은 다음과 같습니다.

1) 문제가되는 폴더를 내 홈 디렉토리로 이동하고 SVN에서 삭제하고 커밋하십시오.

mv foldercausingproblem ~/
svn --force delete foldercausingproblem
svn commit --message "Temporary removing folder with old API"

2) 폴더를 다시 넣고 SVN에 추가하고 다시 커밋하십시오.

mv ~/foldercausingproblem ./
svn --force add .
svn commit --message "Finally all working!"

두 번 커밋해야한다는 약간의 자극이 있지만 제대로 작동하는 것 같습니다.


나는 일반적으로 repo의 작업 사본과 별개로 코드 작업을 좋아합니다. 즉, 기본 SVN 커밋 프로세스는 다음과 같습니다. 1. repo의 작업 복사본 확인 2. 프로젝트의 루트 디렉토리 삭제 3. 업데이트 된 프로젝트 디렉토리를 복사하여 작업 복사본의 프로젝트 상위 디렉토리에 붙여 넣기 4. svn --force <projname> 추가 5. 커밋. 이것은 일반적으로 작동하지만 때로는 OP의 오류가 발생할 수 있습니다. Jamie Brown의 수정은 제 경우에
효과적

0

누군가 다른 솔루션을 원할 경우를 대비하여 :

  1. 새 폴더에서 "foldername2"로 체크인하십시오.
  2. Tortise SVN repo 브라우저로 이동
  3. "foldername2"의 이름을 "foldername"으로 변경
  4. Windows 탐색기에서 업데이트를 수행하십시오.

그것이 누군가를 돕기를 바랍니다.

-Ev


Windows 전용 솔루션.
랩터

0

나에게도 같은 문제가 발생했습니다.

  • --force.map 파일을 삭제 ( )했습니다.
  • svn:ignorevia 에 * .map 추가svn propedit svn:ignore .

내 해결책은 다음과 같습니다.

  1. 속성 변경 취소
  2. 파일에 대한 변경 사항을 커밋
  3. 저장소의 새로운 사본을 체크 아웃하십시오 (alas!)
  4. 속성을 변경하고 커밋

0

svn에 디렉토리를 추가하려고 할 때이 문제가 발생했습니다. repo 브라우저로 이동하여 해결했습니다. 왼쪽 창을 마우스 오른쪽 버튼으로 클릭하고 폴더 추가를 선택하고 repo 브라우저에서 직접 디렉토리를 추가하십시오.

그런 다음 디렉토리를 로컬로 삭제하고 (물론 백업 후) 정리 및 svn 업데이트를 수행하고 모든 것이 다시 작동했습니다.


이 파일이 "svn sucks"파일에 추가되었다고 덧붙일 수 있습니다.
Speck

0

먼저 폴더의 시스템으로 프로젝트를 체크 아웃하십시오. 그런 다음 충돌 프로젝트에서 .svn 폴더를 제거하고 새 체크 아웃 폴더에서 .svn 폴더를 복사하여 작업 사본 폴더에 붙여 넣습니다. 그런 다음 문제가 해결됩니다.


0

내가 경험 한 일반적인 작업은 준비 할 때 하나의 repo 디렉토리를 가져 와서 SVN 하에서 동일한 이름으로 불리는 다른 저장소에 복사하는 것이 었습니다. 나를 위해 일한 방식은 다음과 같습니다.

svn --force delete PROBLEMATIC-DIR
svn export "https://OLD REPO-A/ new-repo-A"
svn add new-repo-A
svn commit new-repo-A
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.