Failed to update working copy of SVN

I have a very big svn repo. When I try to use it (commit, update, etc.), it says there are locks.

When I run 'svn cleanup', it says the working copy is too old and I need to update it.

When I run 'svn upgrade', it starts but says nothing.

I also performed the 'svnadmin upgrade' on the repo, just in case.

I have the latest TortoiseSVN installed.

Usually, if I had the SVN weirdness, I would move the files, update, move the files back, but as I mentioned earlier, this is a very BIG repo.

Any help would be appreciated.

Thanks!

Specific Posts:

>svn update svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) svn: E155004: Working copy '*****' locked. svn: E155004: '*****' is already locked. >svn cleanup svn: E155036: Please see the 'svn upgrade' command svn: E155036: The working copy at '*****' is too old (format 29) to work with client version '1.8.1 (r1503906)' (expects format 31). You need to upgrade the working copy first. >svn upgrade > 

Update 1 : I installed the 1.7.X client and tried to start the cleanup. He complained that the repo was for some reason not a working copy. I tried updating with the same 1.7.X client and received the following message:

 >"c:\Program Files\SlikSvn\bin\svn.exe" update svn: E155021: This client is too old to work with the working copy at '*****' (format 31). You need to get a newer Subversion client. For more details, see http://subversion.apache.org/faq.html#working-copy-format-change 

So these are client things, the repo is format 31. The turtle thinks it's format 29. Now I'm more confused.

Update 2 : Reply to @David W

 Is this about a working copy or the repository? 

Working copy. Although I also tried updating svnadmin on the repo. However, svnadmin I used 1.8.1. I just tried updating the repo using TortoiseSVN (1.8.10), but this did not solve the problem.

 is this about a file that locked because someone locked it, or because your working directory is locked due to an incomplete 

I am the only one who uses repo, so I know that no one else has blocked it. This is probably due to an incomplete operation.

I started svn status from 1.8.10 and there was nothing β€œK”. There were some files with "L" and one with "?" . All of the items listed are directories, not files, with the exception of those marked with a "?" .

If I ran "svn lock --force dirname", it would reply that this particular node "is not a file." When I ran it in the file marked with "?" He replied that the node is "not found."

 Then, there is a locked working directory because of an incomplete operation... 

Yes, you called it. That is why all things are marked with "L", I am going to.

When I started the cleanup (1.8.10), he gave me the same error that I reported in my intuitive question (format 29 is too old for this format 31 client).

 Remember that you can always delete a working directory and create a new one 

Yeah. If I delete any directory in the working copy and delete the update, it complains that it is locked. I cannot remove the lock due to format mismatch. I can theoretically just re-check all the repos and then copy things back, but the repo is 12 GB (210,000 files).

 Be careful about mixing up Subversion clients 

So, I did not know that I have two clients, but I use only TortoiseSVN (1.8.10). I just discovered today that I had two when I was trying to troubleshoot.

* UPDATE 3: RESOLUTION * Using @David W's tips, here's how I fixed the problem: 1) Backed up my .svn folder 2) Download the SQLite editor from https://github.com/sqlitebrowser/sqlitebrowser/releases 3) Opened mine wc.db file and scanned the WC_LOCK table. There was 1 entry in this table that I deleted. 4) I tried cleaning with TortoiseSVN (1.8.10), which previously complained about blocking. It finally worked! 5) I tried running commands in my repo (update, commit, etc.), and everything was happy.

Thanks to everyone who helped, especially @David W for not giving up on me.

+4
source share
1 answer

I have a very big svn repo. When I try to use it (commit, update, etc.), it says there are locks.

Is this about a working copy or repository ? Two different things. Also, this is about a file that is locked because someone has locked it, or because your working directory is locked due to incomplete

You can lock the file, which prevents you from committing. From the command line, you can make svn status and see K next to the locked file. Then you can use svn lock --force to steal this lock and check your changes. (As long as there is no hook in the repository that prevents theft of locks).

Then there is a locked working directory due to incomplete operation. In this case, you will see L when you execute svn status . In this case, you can usually do svn cleanup in the root directory of this working copy (where the .svn folder is .svn .)

Remember that you can always delete the working directory and create a new one. Be careful when mixing Subversion clients. At one time, this did not seem to matter much, but in versions 1.6, 1.7, 1.8, and 1.9, the structure of the working copy has changed and may not be compatible with clients performing other revisions.


Update 2

Yeah. If I delete any directory in the working copy and delete the update, it complains that it is locked. I cannot remove the lock due to format mismatch. I can theoretically just re-check all the repos and then copy things back, but the repo is 12 GB (210,000 files).

Removing the directory and then running svn up does not fix the lock problem. I wanted to delete the entire working directory and redo svn co . You do not need to check all repos. You only need to check what you need. Do you need all 210 thousand files? I doubt it:

 $ svn co http://server/repo # NOOOO! $ svn co http://server/repo/trunk # A bit better, but do you need all # the projects under Trunk? $ svn co http://server/repo/trunk/foo # Now, I'm just checking out foo $ svn co http://server/repo/trunk/bar # Now, I'm just checking out bar 

This checks two working directories: One for foo and one for bar .

If you really want to check the entire trunk, use --depth to insignificantly check what you need:

 # Checking out trunk, but only getting the project directories $ svn co http://server/repo/trunk --depth=immediates $ svn up --set-depth=infinity foo $ svn up --set-depth=infinity bar 

Here I theoretically check the entire trunk, but I get only empty catalogs of the main projects. I only get files from foo and bar projects. However, foo and bar share a working directory. Let's say I start a long update on foo , then go to bar and try to commit. I will get a warning that the working directory is locked. I cannot make two separate Subversion commands in the same working directory, even if they are in different sections of this working directory.

So, I did not know that I have two clients, but I use only TortoiseSVN (1.8.10). I just discovered today that I had two when I was trying to troubleshoot.

If you install Tortoise, you can also install the Subversion command-line client, which is an optional installation. I highly recommend it! Do not use the command line client downloaded from another location (for example, SlikSVN or CollabeNet. This does not mean that these clients are bad. This means that you must use the command line client that comes with your version of TortoiseSVN to guarantee some parity between the two Subversion Clients

Clean Up vs. Upgrade or Svnadmin

It is very easy to get these confusions. You should not use the svnadmin in your working directory. svnadmin is for the server. You have a problem with the client.

Since Subversion has moved from 1.6 to 1.7 to 1.8 and now to 1.9, upgrade upgrade your working directory to the new format. After that, you will not be able to return to the older format. You are upgrading to 1.8, clients 1.7 and 1.6 will no longer work.

Cleaning is the removal of locks due to incomplete Subversion client commands.

+5
source

Source: https://habr.com/ru/post/1257902/


All Articles