Subversion에서 차단 된 폴더

Subversion에서 차단 된 폴더

---

Subversion에 체크인 할 때 "폐쇄 된"도대체 무엇을 의미합니까? 텍스트 상태가 "폐쇄 됨"인 두 개의 폴더가 빨간색으로 표시됩니다. 문서의 어느 곳에서 이것이 의미하는 바를 알 수 없습니다.

cleanup명령을 시도하면 "폴더 이름이 작업 디렉토리가 아닙니다"라는 메시지가 나타납니다. 이것은 VS에서 방금 만든 폴더이며 Subversion에 추가하려고하면 오류가 발생합니다. 다른 모든 폴더는 괜찮습니다.

---

SVN 명령을 거치지 않고 .svn 서브 디렉토리를 삭제하거나 이동할 때 발생하므로 SVN은 작업 사본의보기를 손상시킵니다.

먼저 정리를 시도한 후에도 해결되지 않으면 디렉토리를 되돌 리거나 업데이트하여 하위 디렉토리 .svn 폴더를 복원하십시오.

---

원인이 무엇인지 모르는 경우 해결책은 작업 복사본 (로컬에있는 전체 체크 아웃)을 다른 곳으로 내보내는 것입니다.

tortoisesvn을 사용하는 경우 "버전이없는 파일 내보내기"옵션이 있지만 명령 줄에서 버전 버전 파일 만 내 보내면 버전이없는 파일을 수동으로 복사하는 데 많은 노력이 필요합니다 .

완료되면 깨끗한 작업 복사본을 확인한 다음 내 보낸 백업을 맨 위에 놓습니다. 백업에 .svn 폴더가없는 것이 매우 중요합니다.

사람들이 다른 작업 복사본 또는 .svn 항목을 손상시키는 다른 작업 복사본 내에서 작업 복사본을 체크 아웃하기 전에이 오류를 보았습니다.

---

같은 문제가 있었고 다음과 같이 수정했습니다.

• 막힌 디렉토리 이름을 바꿨습니다.
• SVN에서 원래 이름으로 디렉토리를 생성했습니다 (예 : svn mkdir)
• 부모 폴더를 업데이트하여 새로 작성된 디렉토리가 작업 사본에 나타납니다.
• 차단 된 파일을 새로 생성 된 디렉토리로 복사하여 커밋

---

* nix 시스템을 사용하는 경우 파일을 작성하지 않았는지 확인하고 SVN에 추가 한 다음 삭제하여 동일한 이름의 폴더로 바꾸십시오. OP에 도움이되지는 않지만 누군가에게 많은 스트레스를 덜어주기를 바랍니다.

---

이는 어떤 이유로 조작 중에 충돌이 발생했음을 의미합니다. 버전이없는 파일 또는 폴더와 이름이 같은 기존 버전이없는 파일 또는 폴더가 있는지 확인하십시오.

(Tortoise SVN 클라이언트 도움말 파일에서 그래프로 표시됨)

---

아무것도 나를 위해 일하지 않았으므로 다음을 수행했습니다.

• 버전이없는 파일을 새 위치로 내 보낸 경우
• 기존 폴더의 이름을 바꿨습니다.
• 프로젝트의 내보내기 위치에서 폴더를 옮겼습니다.
• 새 폴더의 이름을 바꿨습니다
• 추가, 커밋
• 이름이 바뀐 이전 폴더를 제거했습니다.
• 새 폴더의 이름을 바꿨습니다
• 범하다

---

이 상황을 유발할 수있는 시나리오의 다양한 변형이 있습니다. 다음은 하나의 예입니다.

나는 결국! 'svn rename'명령을 사용하지 않고 www에서 www_a로 이름이 변경된 디렉토리에 표시하십시오.

1. 원래 이름이있는 현재 디렉토리의 이름을 바꾸십시오 (예 : www_b).
2. www_a의 이름을 www로 다시 변경
3. www 디렉토리에서 'svn update'또는 'svn revert'를 수행하십시오.
4. 'svn delete'를 사용 하지 않고 최신 www 디렉토리 를 삭제하십시오.
5. 상위 디렉토리로 이동하여 'svn update'를 발행하십시오.
6. 이것은 원래 www 디렉토리를 복원합니다
7. 이번에는 'svn rename'을 사용하여 www의 이름을 www_a로 바꿉니다.
8. www_b의 이름을 www로 다시 변경
9. 'svn add'를 사용하여 저장소에 추가하십시오.

이 시점에서 올바른 svn 작업 디렉토리를 가져와야합니다. 그리고 svn 디렉토리 혼란을 해결하는 방법에 대해 배우십시오.

---

Windows 시스템에서이 문제에 직면했습니다.

내가 속한 전체 프로젝트를 체크 아웃하기 전에 디렉토리를 체크 아웃했습니다. 그것은 나를 위해 '폐쇄 된'문제를 일으켰습니다.

단순히 해당 폴더를 삭제하고 (해당 폴더의) 루트에서 업데이트를 실행했습니다. 잘 작동했습니다.

정리 등의 명령이 작동하지 않았습니다.

주의 사항 :

1. 폴더가 크면 비용이 많이 듭니다.
2. 변경 사항이 있으면 모든 변경 사항을 잃게됩니다.

모두 제일 좋다.

---

리포지토리 디렉토리에 대한 심볼릭 링크를 만들었을 때 Windows에서도 이것을 보았습니다. 이 경우 리포지토리 루트는 "폐쇄"된 것으로 나타납니다. 그러나 이것은 아무런 영향을 미치지 않는 것 같습니다.

재현 단계 :

1. Checkout your repo

   svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir
   

2. Check that your directory is OK

   cd plugin_dir
   svn st -u
   

   Output should be

   Status against revision: 1234
   

3. Create the symlink (which shows the problem)

   cd ..
   mklink /d link_dir plugin_dir
   cd link_dir
   svn st -u
   

   Output will be

   ~           1234  .
   Status against revision: 1234
   

---

I ran into this problem when pasting at folder with subdirectories into my working copy using my FTP client - I knew I screwed up as soon as I hit the transfer button... the perils of working way too late.

I tried all the suggestions above and other found online to no avail. Every option produced the error that my directory was locked and the operation could not be performed.

I went into my Time Machine copy, restored the directory and was good to go. I cleaned the working copy as a precaution, updated my files properly and was back in business.

---

We often have multiple branches on the go at the same time, in order to save me switching or messing around with IIS configuration I check each branch out to a separate folder. I then use directory linking to connect those folders back to the main path configured in IIS.

So for me the linked directory always has a yellow exclamation and is marked as obstructed. I believe this is because it was technically created/moved outside of SVN.

---

I get this "obstructed" status on directories when I do updates to a CMS (WordPress or Drupal) through the web interface -- the application is unaware that its code is actually a subversion working copy, so when updating a plugin it removes that plugin's directory (including the .svn directory) and drops in a new directory from the new version of the plugin.

To get that .svn dir back, from the directory containing the obstructed dir. I do a checkout with --force. For example, if plugin_dir is marked "~", from its parent directory I run:

svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir

Any files already there are left alone and marked "E" on the output of the checkout command (marked as "M" when I run svn status).

I sometimes have to go back and add any files that were new with the update; or delete files that should be deleted as part of the update, since they re-appeared when I did the checkout. I believe these are marked as "A" on the checkout, but a subsequent svn status won't mention them.

---

I ran into this in Eclipse where some files were marked with a red exclamation point. The problem was a stray .svn folder in the source directory. I deleted the .svn folder, refreshed eclipse, and was able to check in the files.

---

This can also happen when you upgrade your subversion to a version that XCode does not support.

---

Here's the simplest (and safest) way I've found to resolve this:

1. Temporarily rename the offending file or directory (or a parent directory) that is obstructed (e.g. add ".backup").
2. Delete any .svn directories inside the renamed directory (if applicable).
3. svn revert the renamed (and now missing) object from step 1.
4. svn delete the reverted object.
5. Re-rename the backup from step 1 back to its original name.
6. Add and check-in the renamed object back into svn as a new object.

---

This occurred to me when I replaced a file with a folder, having the exact same name. Solved by deleting the old file, commit, and then add the new one. A little hacky, but worked for me :)

참고URL : https://stackoverflow.com/questions/890440/obstructed-folders-in-subversion