Subversion의 이상한 문제-내 저장소에있는 데 사용 된 디렉토리를 다시 만들려고 할 때 "파일이 이미 있습니다."

Subversion의 이상한 문제-내 저장소에있는 데 사용 된 디렉토리를 다시 만들려고 할 때 "파일이 이미 있습니다."

---

그래서-몇 가지 수정 전에 mysql이라는 디렉토리를 사용했습니다. 나는 그것을 삭제하고 다시 시작하기로 결정했지만 새로운 mysql 디렉토리를 만들려고 할 때 'File already Exists'오류가 계속 발생합니다.

support:/etc/puppet/modules# mkdir mysql
support:/etc/puppet/modules# svn add mysql/
A         mysql
support:/etc/puppet/modules# svn commit -m " Test"
Adding         modules/mysql
svn: Commit failed (details follow):
svn: File already exists: filesystem '/var/lib/svn/puppet/db', transaction '11-r', path '/trunk/modules/mysql'
support:/etc/puppet/modules# svn delete mysql
svn: Use --force to override this restriction
svn: 'mysql' has local modifications
support:/etc/puppet/modules# svn --force delete mysql
D         mysql

강제 업데이트를 제안하는 다른 게시물을 보았습니다.

support:/etc/puppet/modules# svn status
support:/etc/puppet/modules# svn update
At revision 11.
support:/etc/puppet/modules# svn mkdir mysql
A         mysql
support:/etc/puppet/modules# svn commit -m "Test"
Adding         modules/mysql
svn: Commit failed (details follow):
svn: File already exists: filesystem '/var/lib/svn/puppet/db', transaction '11-s', path '/trunk/modules/mysql'

---

폴더 (및 하위 폴더)를 삭제하고 처음부터 다시 만들 때 이와 같은 문제가 발생 했습니다 . 폴더 를 수동으로 삭제하고 다시 추가하면이 오류가 발생합니다 ( 파일 이이 문제를 해결하는 것처럼 보임).

실망스러운 일을 겪은 후 다음을 수행해야 함을 알았습니다.
(Windows에서 TortoiseSVN 사용)

1. 충돌하는 폴더를 작업 복사본에서 이동 (진행중인 작업을 잃지 않도록)
2. 마십시오 svn update오래된 파일을 추가하는 / 폴더 작업 복사본으로 백업
3. svn delete 폴더
4. commit
5. 새 폴더를 작업 복사본으로 다시 복사합니다 (내부의 모든 .svn 폴더 삭제 확인).
6. commit

불행히도 (A)에는 두 개의 커밋이 필요하고 (B)는 최근 다시 추가로만 추적하기 때문에 파일 개정 기록을 잃습니다 (누군가이 문제를 해결하는 방법을 설명 할 수없는 경우). 이 두 가지 문제를 해결하는 대안은 3 단계와 4 단계 를 건너 뛰는 것입니다. 유일한 문제는 이전 / 불필요한 파일이 여전히 디렉토리에있을 수 있다는 것입니다. 수동으로 삭제할 수 있습니다.

다른 사람들이 이것에 대해 가질 수있는 추가 통찰력을 듣고 싶습니다.

사이먼.

---

[업데이트] 좋아요, 바로 그때도 같은 문제가 발생했지만 문제가되는 폴더가 마지막 커밋에 없어서 update복원하지 않았습니다. 대신 저장소와 delete문제가되는 폴더를 찾아야했습니다 . 그런 다음 add폴더를 다시 넣을 수 commit있습니다.

---

비슷한 문제가있었습니다. 이를 해결하기 위해 svn 트렁크에서 로컬 파일의 우선 순위 옵션을 업데이트했습니다.

svn update path/ --accept=mine-full

평소처럼 커밋 할 수 있습니다. 물론 사용에주의하십시오.

---

이미 이런 종류의 문제가있었습니다.

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

svn에서 폴더를 삭제하고 폴더 사본을 어딘가에 보관하고 변경 사항을 커밋하십시오. 백업 사본에서 모든 .svn 폴더를 재귀 적으로 삭제하십시오. 이를 위해 당신은 실행할 수 있습니다

#!/bin/bash

find -name '.svn' | while read directory;
do
    echo $directory;
    rm -rf "$directory";
done;

로컬 저장소를 삭제하고 전체 프로젝트를 다시 체크 아웃하십시오. 부분 삭제 / 체크 아웃이 충분한 지 알 수 없습니다.

문안 인사

---

mysql 디렉토리가있는 마지막 버전으로 되 돌린 다음 디렉토리의 내용을 삭제하고 새 내용을 넣은 다음 새 정보를 다시 확인하여 문제를 해결했습니다. 누구든지 도대체 무슨 일이 일어나고 있는지에 대한 더 나은 설명을 가지고 있습니다.

---

이것은 끔찍한 것입니다 ... 신비한 오류이며 명확한 수정이 없습니다.

업데이트 / 되돌리기 / 커밋이 내 상황에서 작동하지 않았습니다. 나는 이상한 일을하지 않았다. 단지 약간의 svn 움직임이다.

나를 위해 일한 것은 다음과 같습니다.

svn remove offender
svn commit
cd ..
rm -fR parent
svn up parent
cd parent
svn remove offender again
svn commit
copy offender back in (minus .svn dirs)
svn add
svn commit

최소한 말 이상합니다. 기본적으로은 svn remove --force offender어떤 이유로 든 완전히 제거하지 않았습니다. 오류 메시지가 말하는 것과 같습니다. 부모를 제거한 다음 부모를 업데이트해야만 범인이 다시 나타났기 때문에 이것이 분명해졌습니다! svn은 위반자를 다시 제거한 다음 올바르게 제거했습니다.

---

I'm not sure if this is helping you, but I guess that when you do a svn add mysql after you've deleted it it will just reinstantiate the directory (so don't do a mkdir yourself). If you create a directory yourself svn expects a .svn directory inside it because it already 'knows' about it.

---

1. rename the new path to temp
2. revert the new path (not temp!) so svn does not try to commit it
3. commit the rest of your changes
4. copy the path inside the repository: svn copy -m "copied path" -r
5. update your working copy
6. mv all files from temp to the new path, which comes from the update
7. commit your local changes since revision
8. Have a nice Day including history ;-)

---

I had this problem on a project I run on Netbeans. I simply right clicked on the file and update to fix it (after SVN up).

---

This solution merges smoothly and does not lose history:

1. Move /working-copy/offender to a temporary location.
2. Do an svn checkout of svn+ssh://svn.example.com/repo/offender to /working-copy/offender.
3. Manually move your files from the temporary location into the new checkout.
4. Delete the temporary location.

---

I ran into this problem today when Xcode crashed during a branch merge. Somehow the file was uploaded to the svn repository but it wasn't recorded in the svn db properly. I ran the following commands in the directory where the file existed locally:

svn revert bad.file
svn del svn://my.svnserver.com/svnDB/path/to/the/offending/file/bad.file

Then I re-added the file from my local system:

svn add bad.file
svn commit -m "Re adding bad.file"

Success!

---

This situation occured if there are object in repository, which creates by current transaction.

Simple scenario:

1. checkout some directory two times, as DIR1 and DIR2
2. make 'svn mkdir test' in both
3. make commit from DIR1
4. try to make commit DIR2 (without svn up), SVN shall return this error

Same thing when adding same files from two working copies.

---

As per Atmocreation's solution, except you don't need to re-checkout the whole project, which is useful if you have existing work in progress.

Let's say you have a working copy:

/foo/

which contains directories:

/foo/bar/baz

and you're getting the error message on commit:

svn: File already exists: filesystem '/foo/bar'

Backup the contents of bar somewhere:

mkdir -p ~/tmp/code_backup
cp -r /foo/bar ~/tmp/code_backup

Delete the .svn control directories from the backup. Make sure you get this command right, or you can do pretty serious damage!! Delete them manually if you're unsure.

find ~/tmp/code_backup/bar -name .svn -type d -exec rm -rf {} \;

Double check that the copy is identical:

diff -r -x .svn dist ~/tmp/code_backup/dist

Remove the offending directory from the working copy: cd /foo rm -rf bar

And then restore it from the repository:

cd /foo
svn update bar

Copy back the modified files from backup:

cp -r ~/tmp/code_backup/bar /foo/

You should now be able to commit without the error.

---

What you need is the svn 'export' command. With this you can put a file or entire directory tree in the state of another revision in another branch.

So something like

rm file #without 'svn' in front!
svn export myrepo/path/to/file@<revision> .
svn commit

---

The problem is that the checkout takes place on a laptop and in this case subversion can not cope with the off-line synchronization. The problem is reproducable on an other laptop while on a desktop I have no problem checking out the same repository.

I hope this answer wil help you, it took me quite long to find out.

참고URL : https://stackoverflow.com/questions/1407973/strange-problem-with-subversion-file-already-exists-when-trying-to-recreate