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.