SVN 오류-작업 사본이 아님

SVN 오류-작업 사본이 아님

---

최근에 svn 서버가 변경되었고 svn 스위치를 사용했습니다.

작업 복사본에는 버전이없는 많은 리소스가 있었기 때문에 작업 복사본이 잠기고 svn 아래의 모든 폴더에 대해 폴더별로 폴더를 전환하기 시작했습니다.

그러나 저장소의 최상위 레벨에서 파일을 업데이트하려고하면 svn : Working copy '.'가 표시됩니다. 잠긴 오류 및 정리도 도움이되지 않습니다. 정리할 때 다음과 같은 오류가 발생합니다 . svn : 'content'는 작업중인 복사 디렉토리가 아닙니다.

새로운 결제는 옵션이 아닙니다. 잠금 장치를 청소 및 해제하고 스위치를 완전히 수행하는 다른 방법이 있습니까?

편집 : JesperE의 답변에서 마지막 단락

재귀적인 "svn cleanup"을 수행 할 때 "작동중인 사본이 아님"을 얻는다면 내 추측은 작업 사본이어야하는 디렉토리 (예 : 최상위 레벨의 .svn 디렉토리는 그렇게 말합니다)이지만 자신의 .svn 디렉토리. 이 경우 해당 디렉토리를 제거 / 이동 한 다음 로컬 업데이트를 수행 할 수 있습니다.

저장소의 문제에 대한 해결책 인 것 같습니다. 해당 폴더를 식별하고 해당 폴더 만 새로 체크 아웃하고 와우, 잠금은 후속 정리에서 해제됩니다! 많은 JesperE 감사합니다!

그러나 여전히 svn 스위치 오류를 파악할 수 없으며 현재 다음과 같은 내용을 읽습니다.

svn : 'svn : // repourl / reponame / foldername'의 저장소에는 uuid 'm / reponame'이 있지만 WC에는 'b5b39681-0ff6-784b-ad26-2846b9ea8e7d'가 있습니다.

어떤 아이디어?

---

재귀를 할 때 "작업 복사본이 아님"을 얻는다면 svn cleanup내 추측은 작업 복사본이어야하는 디렉토리 (즉 .svn최상위 디렉토리 의 디렉토리)가 있지만 자체 .svn디렉토리 가 없다는 것입니다 . 이 경우 해당 디렉토리를 제거 / 이동 한 다음 로컬 업데이트 (예 :)를 시도 할 수 rm -rf content; svn checkout content있습니다.

당신이 얻을 경우 not a working copy오류를, 그것은 서브 버전은 적절한 발견 할 수 없다는 것을 .svn거기에서 디렉토리를. .svn디렉토리 가 있는지 확인하십시오contents

이상적인 해결책은 가능한 경우 새로 체크 아웃하는 것입니다.

---

비슷한 상황 ( svn: 'papers' is not a working copy directory)으로 다른 방식 으로 들어갔 으므로 전투 스토리를 게시하겠다고 생각했습니다 (간체).

$ svn add papers
svn: Can't create directory 'papers/.svn': Permission denied

죄송합니다! 권한 수정 ... 다음 :

$ svn add papers
svn: warning: 'papers' is already under version control
$ svn st
~     papers
$ svn cleanup
svn: 'papers' is not a working copy directory

그리고 papers길을 벗어나 달리고 svn up(OP에서 일한) 달리기도 해결하지 못했습니다. 내가 한 일은 다음과 같습니다.

$ mv papers papers_
$ svn cleanup
$ svn revert papers
Reverted 'papers'
$ mv papers_/ papers
$ svn add papers

효과가있었습니다.

---

나는 그것을 해결했다.

1. 영향을받는 폴더의 백업 복사
2. SVN은 영향을받는 폴더를 되돌립니다
3. 백업에서 파일을 다시 붙여 넣기

제 경우에는 문제가 삭제 된 .svn-files 때문이었습니다.

---

어쩌면 방금 폴더 트리를 복사하고 가장 낮은 폴더를 추가하려고했습니다.

SVN
|_
  |
  subfolder1
       |
       subfolder2   (here you get an error)

이 경우 상위 레벨에서 디렉토리를 커밋해야합니다.

---

해결 방법 : '작업 복사본'이 아닌 디렉토리 이름 바꾸기이 디렉토리를 다시 체크 아웃 / 업데이트 / 복원 이름이 바뀐 디렉토리에서 새 커밋 변경으로 파일 이동

이유 : .svn 디렉토리에있는 일부 파일을 변경하면 '작업 사본'이 중단됩니다.

---

If you created a file inside a new directory, instead of 'svn add newdir/newfile' use 'svn add newdir' because you need to add the directory. All the files inside the directory will be added by default.

---

I just got "not a working copy", and for me the reason was the Automouter on Unix. Just a fresh "cd /path/to/work/directory" did the trick.

---

Same, I needed to update a 'contrib' folder:

1. Moved the old folder out,
2. Copied the new one
3. Copied the .svn folders into each (only three in my case) new folder.

I my case too the problem was due to deleted .svn folders.

Solved.

---

I tried pasting the .svn folder from the sub folder to the root folder. It works!!!

---

This is what I did:

1. rename trunk to trunk_
2. create a new folder trunk
3. Re-checkout and interrupt the process after few files are checked-out
4. Move the files from trunk_ to trunk
5. Do svn cleanup
6. Do svn update. This will update the status of files and then all your files will be versioned.

---

I also meet this problem in svn diff operation, it was caused by incorrect file path, you should add './' to indicate the current file directory.

---

svn: The repository at 'svn://repourl/reponame/foldername' has uuid 'm/reponame', but the WC has 'b5b39681-0ff6-784b-ad26-2846b9ea8e7d'

Every subversion repo has a unique identifier (uuid). Subversion uses this to make sure that the repo is actually the same when doing things like switching. You should probably change the uuid on the server to be the same as before.

---

Could it be a working copy format mismatch? It changed between svn 1.4 and 1.5 and newer tools automatically convert the format, but then the older ones no longer work with the converted copy.

---

You must have deleted a SVN - base file from your project (which are read-only files). Due to this you get this error.

Check out a fresh project again, merge the changes (if any) of your older SVN project with new one using "Winmerge" and commit the changes in your latest check out.

---

@JesperE mentions that you need to change the uuid. The following should help you achieve this.

On SVN 1.5+, you can do svnadmin setuuid; you can then check that it's been set correctly using svnlook uuid. On earlier versions of SVN, it's a harder process. See http://chestofbooks.com/computers/revision-control/subversion-svn/Managing-Repository-UUIDs-Reposadmin-Maint-Uuids.html

Additionally the UUID of "m/reponame" looks suspicious. I believe it should be a hex-formatted number like the working copy's, so maybe this action will improve things all round :-)

[I originally commented on @JesperE's answer, but created this answer to make it more obvious to people and more helpful for Google. I've since removed my comments. ]

---

Had this same problem, turns out we had Slik 1.6.2 as well as Tortoise on the same machine. Tortoise had been updated (and had updated the working copy) but Slik had not, so Tortoise worked OK, but command lines failed with:

svn: '.' is not a working copy directory

Removing both Tortoise and Slik, then reinstalling Tortoise with command line tools enabled fixed this for me.

---

for mac :- take checkout from server side and a new window will open to select directory from your local machine than put your all code in selected folder then open svn local side and add and commit the project

---

Today i have found same issue /FILE_NAME/ is not a working copy in morning and i have spent more then two hours to solve it. After long of RND and Google i found some solution and that is CHECKOUT.

1. CHECKOUT from SUBVERSION to local as new project.
2. Change some of code in java file and COMMIT the project.
3. It's Works for me.

Hope it will helpful for you.

---

Recently I was using other developers Mac I had the same situation, problem was; first I needed to type get repo path to terminal but I didn't, than it says what is your user name and password.

---

I just ran into a case where the .svn directory is on a nfs server on a different machine, and the nfs client was not running the file locking service (lockd).

svn: E155007: '/mnt/svnworkdir' is not a working copy

This went away once lockd was started on the nfs client host.

It seems like subversion could come up with a better error message when it has trouble locking files. This was subversion 1.10.0

---

I made a new checkout from the same project to a different location then copied the .svn folder from it and replaced with my old .svn folder. After that called the svn update function and everything were synced properly up to date.

---

Delete .svn folder that is present in your local machine. Press windows icon and type .svn, delete the entire folder. It worked for me.

참고URL : https://stackoverflow.com/questions/374313/svn-error-not-a-working-copy