SVN에서 작업 사본 XXX 잠김 및 정리 실패

SVN에서 작업 사본 XXX 잠김 및 정리 실패

---

다음을 수행 할 때이 오류가 발생합니다 svn update.

작업 복사본 XXXXXXXX 잠김 "정리"명령을 실행하십시오.

정리를 실행하면

다음 경로를 정리하지 못했습니다. XXXXXXXX

이 루프에서 벗어나려면 어떻게해야합니까?

---

한 가지 접근 방식은 다음과 같습니다.

1. 편집 한 항목을 다른 위치로 복사합니다.
2. 문제 경로가 포함 된 폴더를 삭제하십시오.
3. Subversion을 통해 포함 폴더를 업데이트합니다.
4. 파일을 다시 복사하거나 필요에 따라 변경 사항을 병합합니다.
5. 범하다

또 다른 옵션은 최상위 폴더를 삭제하고 다시 체크 아웃하는 것입니다. 그래도 그렇게되지 않기를 바랍니다.

---

저에게있어 트릭은 svn cleanup문제가 발생하기 전 내내 작업했던 폴더가 아니라 작업 복사본의 맨 위에서 실행 하는 것이 었습니다.

---

당신의 모습 .svn이라는 폴더에이 파일이있을 것이다 lock. 해당 파일을 삭제하면 업데이트 할 수 있습니다. .svn각 하위 디렉토리의 디렉토리에 더 많은 잠금 파일이있을 수 있습니다 . 또한 삭제해야합니다. 이것은 예를 들어 명령 줄에서 아주 간단하게 일괄 처리로 수행 할 수 있습니다.

find . -name 'lock' -exec rm -v {} \;

.svn폴더의 파일을 수동으로 편집하고 있습니다 . 거기에 이유가 있습니다. 그 이유는 실수 일 수 있지만 그렇지 않으면 로컬 사본을 손상시킬 수 있습니다.

출처 : http://www.svnforum.org/2017/viewtopic.php?p=6068

---

제 경우에는 WC_LOCK 테이블의 SQLite ".svn \ wc"파일 잠금 레코드에서 레코드를 수동으로 삭제하여 문제를 해결했습니다.

SQLite 편집기로 "WC"파일을 열고 실행했습니다.

delete from WC_LOCK

eakkas 의 설명에 따라 WORK_QUEUE테이블 에서 모든 항목을 삭제해야 할 수도 있습니다.

---

가장 쉬운 방법 :

1. 프로젝트의 상위 디렉토리 (폴더) 로 이동합니다 .
2. 프레 마우스 오른쪽 단추로 클릭
3. 눌러 TortoiseSVN을 누르면 다음 정리 ...
4. 정리 대화 상자가 자동으로 나타납니다.
5. 선택 Clean up working copy status, Break locks, Fix time stamps, Vacuum pristine copies, Refresh shell overlays,Include externals
6. 대가로 OK

당신은 당신의 일을 성공적으로 수행했습니다.

참조를 위해 스크린 샷을 확인하십시오.

첫 번째 단계:

두 번째 단계 : 잠금 해제 옵션 활성화 (정리 팝업 창의 두 번째 확인란)

이것이 당신에게 많은 도움이되기를 바랍니다.

---

직장 동료는이 메시지를 지속적으로보고 있으며, 그 이유 는 SVN에서 삭제 하지 않고 SVN 버전 관리하에있는 디렉터리 를 삭제 한 다음 동일한 이름으로 버전 관리가 아닌 위치에 새 디렉터리를 만들었 기 때문입니다.

이것이 문제라면 ... :

디렉토리가 어떻게 / 왜 바뀌 었는지에 따라 여러 가지 방법으로 수정할 수 있습니다.

어느 쪽이든 다음을 수행해야합니다.

A) 기존 디렉토리의 이름을 임시 이름으로 바꿉니다.

B) SVN 되돌리기를 수행하여 SVN이 아닌 파일 시스템에서 삭제 된 디렉터리를 복구합니다.

거기에서 당신은

A) 삭제 된 디렉토리에 관련 파일을 복사합니다.

B) If you had a significant change of contents in the directory, do an SVN delete on the original, commit, and rename your new directory back to the desired name, followed by an SVN add to get that one under version control.

---

For me none of the above solutions worked. I found a solution by breaking locks. When I performed svn cleanup, I selected "Break Locks" along with "Clean up working copy status".

---

This one worked for me.

1. Go to the root folder,
2. Right click and cleanup
3. Check all available options
4. Press ok

After clean up it will allow you to update to the latest version.

---

For me, it was actually Tortoise's fault, sort of. Tortoise just complained "cannot clean up, run clean up", but when I ran the command line (svn cleanup), it clearly told me that it couldn't delete some files that were in use, the solution to which was obvious. Once I closed Visual Studio (which was keeping the files open), then the cleanup worked fine.

Other programs can also keep files open in the repo causing this issue. Excel holding an xls open was a culprit in another instance so it may be wise to close all programs that may be using anything in the repo or even rebooting to force programs to close out and then trying cleanup again.

---

I had this problem because external folders do not want to be linked into an existing folder. If you add an svn:externals property line where the destination is an existing (versioned or non-versioned) folder, you will get the SVN Woring Copy locked error. Here a cleanup will also tell you that everthing is all right but still updating won't work.

Solution: Delete the troubling folder from the repository and make an update in the root folder where the svn:externals property is set. This will create the folder and all will be fine again.

This problem arose for me because svn:externals for files requires the destination folder to be version controlled. After I noticed that this doesn't work across different repositories, I swaped from external files to external folder and got into this mess.

---

The easiest way to do this is show hidden folders and then open the .SVN folder. You should see a zero KB file named "lock" deleting this will fix the problem

---

I came across the exact same issue using SVN 1.7 and none of the fixes mentioned above worked.

Foremost, make sure you backup all your edited content.

After spending a couple of hours (didn't redownload everything as my branch is over 6gb in size), I found that there is a db file called "wc" in the .svn folder of your branch.

Open up the db file using any db manager (i used firefox's sqlite manager plugin) and navigate to WC_LOCK table. This table will have the entries for the acquired locks. Delete the records from the table and you're done :)

---

When i have this problem, i find running the cleanup command directly on the problem path generally seems to work. Then I'll run cleanup from the working root again, and it'll complain about some other directory. and i just repeat until it stops complaining.

---

If you're on a Windows machine, View the repository through a browser and you may well see two files with the same filename but using different cases. Subversion is case sensitive and Windows isn't so you can get a lock when Windows thinks it's pulling down the same file and Subversion doesn't. Delete the duplicate file names on the repository and try again.

---

I did it by just creating a new folder, checking out the project, copying the updated files to the new folder.

It was fixed with a fresh checkout.

---

Are you using TortoiseSVN and just upgraded? I've had that problem before when moving from 1.4 to 1.5 and not rebooting. (Try a reboot).

The reason you need to reboot is because the cache file gets all funky.

Otherwise, to just move on, export that working copy into a new folder (don't copy the .svn hidden folders), re-checkout the project, and move all your code back, then proceed with your commit.

---

just delete the .svn folders, then run a cleanup on the parent directory. Works perfectly!!

---

In Versions under Mac OS: Action -> Cleanup working copy locks at...

---

I often get such an issue. My pattern that causes cleanup problems.

1. I open image file in viewer.
2. I delete image file/folder.
3. I am trying to commit/update

Closing image viewer where deleted file is opened solves the problem. Maybe other software can block cleanup the same way.

In general. I believe restarting computer may help in such cases.

---

SVN normally updates its internal structure (.svn/prop-base) of the files in a folder before the actual files is fetched from repository. Once the files are fetched this will be cleared up. Frequently the error is thrown because the "update" failed or prematurely cancelled during the update progress.

1. Check any files are listed under .svn/prop-base directory
2. Remove any files which are not under the folder
3. Cleanup
4. Update

Now the update should work.

---

Had the same problem because I exported a folder under a version-controlled folder. Had to delete the folder from TortoiseSVN, then delete the folder from the filesystem (TortoiseSVN does not like unversioned subfolders ... why not???)

---

Do not delete your solution!

in the .svn folder you have a file called lock it is 0 bytes long

You can delete all these files from all the .svn folders in your solution and it will work

It worked in my case

---

In-place unversioning of the files, and a fresh checkout into the same location, has solved this problem for me.

In TortoiseSVN, to do an in-place unversioning, right-drag the root folder of the working copy from the file list onto itself in the directory tree, and choose "SVN Export versioned items here" from the pop-up menu. TortoiseSVN notices that the destination is the same as the source, and suggests unversioning the working copy.

After unversioning, do a fresh checkout into the same folder (which now contains an unversioned copy of all the files you had). TortoiseSVN will warn you that you are checking out into an existing folder, but you can go ahead.

After this, cleanups, updates and other operations worked without a hitch. Since both of the above steps preserve local modifications, there should not be any loss of information (but backing the working copy up before this may nevertheless be a good idea).

One warning: If the working copy contains mixed versions or uncommitted property changes, that information WILL be lost. For me, this is not a common occurrence, and given the choice of a corrupt working copy or losing uncommitted property changes, I tend to opt for the latter.

---

I had this problem where the "clean up" worked, but the "update" would continue to fail. The solution that worked was to delete the folder in question via Windows Explorer, not TortoiseSVN's delete (which marks the deletion as something to commit to the repository, and then I did a "checkout" to essentially "update" the folder from the respository.

More info on the difference between an O/S delete and an SVN delete here: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-rename.html

Notably:

When you TortoiseSVN → Delete a file, it is removed from your working copy immediately as well as being marked for deletion in the repository on next commit.

And:

If a file is deleted via the explorer instead of using the TortoiseSVN context menu, the commit dialog shows those files and lets you remove them from version control too before the commit. However, if you update your working copy, Subversion will spot the missing file and replace it with the latest version from the repository.

---

If you're on Linux, try this:

find "/the/path/to/your/directory" -name .svn -type d | xargs chmod 0777 -R

Then run the cleanup command on that directory, then try to update.

---

I did the following to fix my issue:

1. Renamed the offending folder by placing an "_" in front of the folder name.
2. Did a "Clean Up" of the parent folder.
3. Renamed the offending folder back to it original name.
4. Did a commit.

---

In solution explorer, right click on the project, in the opening sub-menu click on subversion and select clean-up. It will solve the problem, as it did for me. Hope it will work.

---

To do the clean up

1. Delete the .svn folder.

2. Do the svncheckout in the root folder.

3. Try performing the clean up operation.

This got my issue resolved.

---

For me, the problem was with completely full disk drive (linux inodes in my case), when i deleted some folders it started working again.

The error was the following (on any svn action):

$ svn cleanup
svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
svn: E155004: Working copy locked; try running 'svn cleanup' on the root of the working copy ('/my/directory') instead.
svn: E155004: Working copy '/my/directory' locked
svn: E200030: sqlite[S14]: unable to open database file
svn: E200030: Additional errors:
svn: E200030: sqlite[S14]: unable to open database file

---

I had this under TortoiseSVN and the error was related to a new directory I'd created under a new project. I had just created this project, so there was no way this directory had existed before. I looked in the repository browser and the new folder was indeed already in the repository, but TortoiseSVN didn't show it as committed.

In order to get around it, since I'd just created the folder anyway, I deleted it in the repository, and then did a commit. It worked fine.

Visual Studio 외부에서이 작업을 수행했기 때문에 모든 것을 다시 파악하려면 Visual Studio를 다시 시작해야했습니다.

참고 URL : https://stackoverflow.com/questions/127932/working-copy-xxx-locked-and-cleanup-failed-in-svn