I'm developing on OSX, and one of my Subversion working copies just started returning the following error for all commands, however my other checkouts work fine. I get the same message with both my Brew installed SVN binaries as well as my Cornerstone client, but other working directories are fine.
> svn update
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: Working copy '/working_directory' is an old development version (format 12); to upgrade it, use a format 18 client, then use 'tools/dev/wc-ng/bump-to-19.py', then use the current client
> svn upgrade
svn: E155019: Can't upgrade '/working_directory' as it is not a pre-1.7 working copy directory
svn: E150000: Missing default entry
I don't have the bump-to-19.py script anywhere on my computer (according to find / -type f -name bump-to-19.py), however I think I was able to find it on the Apache repository. That said, I am not familiar with what it does, or how to use it. Ideally I can avoid checking out a new version of this working directory and manually merging in all of my (many) changes.
The only info I was able to find is related to Netbeans and javahl, and I'm using neither.
EDIT: After downloading the bump-to-19.py file and making it executable, I tried it against my working directory to no avail:
> ./bump-to-19.py working_directory/
error: format is 29 not 18: 'working_directory/'
Although I was not able to figure out why my working directory was corrupted, I was able to work around it using rsync - there is an option, C, that will ignore CVS/SVN files and directories when making a backup. I made a backup using this option, checked out the project again, and then copied the backup back over the new working directory. SVN is happy again.
> rsync -arC working_directory working_directory_no_svn
> rm -rf working_directory
> svn co https://svn.example.com/project/trunk working_directory
> rsync -ar working_directory_no_svn working_directory
I had the same issue and here is how I resolved:
Delete the .svn folder at the top level (rm -rf .svn)
Checkout software again from SVN (svn co ...)
Good to go!
I know this has been around a while, but I found a solution using the hints given by SVN... Basically use the upgrade command as it states. Using CMD, I went to my workspace folder where the troubled project was located. Lets call the project Project1. You call the command:
"svn upgrade project1"
this resolved my issue the proper way without involving some sort of hack or workaround.
I had a similar issue, my svn is version 1.7.10, however my Subversion plugin for Eclipse is slightly older, I'm assuming 1.6.something.
Using the "rsync -arC working_directory archive_no_svn" command was a breakthrough - at least now I had a copy of the hours of synchronisation I had just completed.
I tried using the "svn co" but it was the wrong version, so I simply ran an update using the Subversion plugin within Eclipse - this restored the working directory from the repository - pretty much what I was after, and it was the correct version.
Getting the rsync back to the correct location was a trick. rsync appears to drop the working folder into the archive location, creating archive_location/working_directory/the-files. So syncing the archived data back into the working_directory was achieved with:
rsync -ar archive_no_svn/working_directory .
Now I have to find out about upgrading my Subversion plugin for Eclipse to 1.7
Related
I have a very very large svn repo. When I try to use it (commit, update, etc.) it says there are locks.
When I run 'svn cleanup', it says that the working copy is too old and I need to upgrade it.
When I run 'svn upgrade', it runs, but doesn't say anything.
I also ran 'svnadmin upgrade' on the repo, just in case.
I have the latest TortoiseSVN installed.
Normally, if I had SVN weirdness, I'd move the files out, update, move the files back, but as I mentioned earlier, this is a very LARGE repo.
Any help would be appreciated.
Thanks!
Specific messages:
>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 a 1.7.X client and tried to run a cleanup. It complained that the repo wasn't a working copy, for some reason. I tried an update with the same 1.7.X client and got 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, this client things the repo is format 31. The tortoisesvn thinks it is format 29. Now I'm more confused.
Update 2:
Response to #David W
Is this about a working copy or the repository?
Working copy. Though I tried svnadmin upgrade on the repo as well. However, the svnadmin I used was the 1.8.1. I just tried to upgrade the repo with the TortoiseSVN one (1.8.10), but that didn't fix the issue.
is this about a file that's locked because someone locked it, or because your working directory is locked due to an incomplete
I'm the only one using the repo, so I know no one else locked it. Its probably due to an incomplete op.
I ran svn status with 1.8.10, and nothing had a 'K'. There were some files with an 'L', and one with a '?'. All items listed were directories, not files, with the exception of the one marked with a '?'.
If I ran an 'svn lock --force dirname', it would respond that that specific node "is not a file". When I ran it on the file marked with a '?', it responded that that node 'was not found'.
Then, there is a locked working directory because of an incomplete operation...
Yep, you called it. That is why all the things are marked with an 'L', I gather.
When I ran a cleanup (1.8.10) it gave me the same error I reported in my intiial question (format 29 too old for this format 31 client).
Remember that you can always delete a working directory and create a new one
Yep. If I delete any directory in the working copy and hit update, it complains that it is locked. I can't clear the lock, 'cause of the format mismatch. I can theoretically just re-checkout the entire repo, then copy things back, but the repo is 12GB (210,000 files).
Be careful about mixing up Subversion clients
So, I was unaware that I had two clients, but I only only only use TortoiseSVN (1.8.10). I only discovered today that I had two when I was trying to troubleshoot.
* UPDATE 3: RESOLUTION *
Using #David W's tips, here is how I fixed the problem:
1) Backed up my .svn folder
2) Downloaded an SQLite editor from https://github.com/sqlitebrowser/sqlitebrowser/releases
3) Opened up my wc.db file and browsed the WC_LOCK table. There was 1 entry in that table, which I removed.
4) Tried running a cleanup using TortoiseSVN (1.8.10), which previously complained about locks. It finally worked!
5) Tried running commands in my repo (update, commit, etc.), and everything was happy.
Thank you to everyone who helped, especially #David W for not giving up on me.
I have a very very large svn repo. When I try to use it (commit, update, etc.) it says there are locks.
Is this about a working copy or the repository? Two different things. Also, is this about a file that's locked because someone locked it, or because your working directory is locked due to an incomplete
You can have a lock on a file that prevents you from doing a commit. From the command line, you can do a svn status and see the K next to the locked file. You can then use svn lock --force to steal that lock, and check in your changes. (As long as there's no hook in the repository that prevents you from stealing locks).
Then, there is a locked working directory because of an incomplete operation. In this case, you'll see an L when you do a svn status. In that case, you can usually do a svn cleanup in the root directory of that working copy (Where the .svn folder is located.)
Remember that you can always delete a working directory and create a new one. Be careful about mixing up Subversion clients. At one time, it didn't seem to matter that much, but in Revision 1.6, 1.7, 1.8, and 1.9, the structure of the working copy has changed and may not be compatible with clients running other revisions.
Update 2
Yep. If I delete any directory in the working copy and hit update, it complains that it is locked. I can't clear the lock, 'cause of the format mismatch. I can theoretically just re-checkout the entire repo, then copy things back, but the repo is 12GB (210,000 files).
Deleting a directory and then doing a svn up doesn't clean up the lock issue. I meant to delete the entire working directory, and redoing a svn co. You don't have to checkout the entire repo. You only have to check out 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 out two working directories: One for foo and one for bar.
If you really, really want to checkout the entire trunk, use the --depth to sparsely checkout 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 am in theory checking out the entire trunk, but I'm only getting empty master project directories. I am only getting files from projectsfoo and bar. However, foo and bar share a working directory. Let's say I start a long update on foo, then I go to bar and try to commit. I'll get a warning that the working directory is locked. I can't do two separate Subversion commands on the same working directory even if they are in different sections of that working directory.
So, I was unaware that I had two clients, but I only only only use TortoiseSVN (1.8.10). I only 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 install. I highly recommend it! Don't use a command line client downloaded from elsewhere (like SlikSVN or CollabeNet. It's not that these clients are bad. It's that you should use the command line client that comes with your version of TortoiseSVN in order to guarantee some parity between the two Subversion clients.
Cleanup vs. Upgrade vs. Svnadmin
It's very easy to get these confused. You shouldn't be using svnadmin commands on your working directory. The svnadmin is for the server. The issue you have is strictly client.
As Subversion moved from 1.6 to 1.7 to 1.8 and now to 1.9, the upgrade will upgrade your working directory to the new format. Once done, you cannot go back to the older format. You upgrade to the 1.8 format, 1.7 and 1.6 clients will no longer work.
Cleanup is to help remove locks due to incomplete Subversion client commands.
I have just recently backed-up my XCode C++ project on my pendrive, using
rsync -avu
Since then, the version control for my project is grayed-out on every files, I can modify the files and not see the "M" nor the "A" sign. The only files still having version-control working "shared" files for which it works correctly. (Those shared files belong to a different project called "Shared").
I have tried git commit -m, git add . and even git init where the files were. Nothing worked.
Can you please help restoring version control for my project?
UPDATE:
Answers for the questions in commens (and answers):
my git repository is on my local hard drive.
I went to the Organiser-repository pane in XCode and I see my recent git commit -m "sth" as "sth" az a commit. I have a single branch: master.
Im not sure what command would be good to test git, as my commits work (theoretically).
I have a folder named .git in the project folder.
git log is working, showing the same as XCode Organiser-repository pane.
I think the XCode just can't synchronise with the git for some reason, and I don't know how to correct that.
First off, this is not an answer that will fix your problem, I just try to provide some help that might get you closer to a diagnosis.
Git stores its files in a folder named .git. Check if this folder is present in your project. If it's not then your Git repository is gone.
Next, try some basic command such as git log. For this to work, you must first cd to your project folder (or a subfolder thereof), because whenever you run a Git command it will look for the .git folder in the cwd or a parent folder. If git log does not work then your Git repository is broken in some way. Someone else will have to step in to further diagnose the problem, as I am no expert on this subject.
Finally, you should also check whether your rsync command has really sync'ed your project's .git folder with the backup's .git folder. Use this command:
diff -rq /path/to/project/.git /path/to/backup/.git
If there is no difference (as I would expect if rsync has worked correctly) then the problem with your Git repository is both in your project and in your backup. If there are differences then it might be worthwile to try your next steps on a copy of the backup (it should be fine to make the copy in the Finder).
Good luck.
my first post so hopefully I am clear enough with my problem.
I started a new project about a year ago in Xcode 3.x.y (iOS project), everything was going well, but I wanted to use some sort of source control. I had heard about SVN on a website so I gave it a shot and put the repositories on a USB external hard drive. Everything was going great, then I decided to switch to Perforce because other people on the project were used to it. After doing that I formatted the usb hard drive to use it for other purposes.
Fast forward to last week: I installed Xcode 4.x, and I am getting all kinds of warnings when I build. The 2 I am getting are:
game_name.app.dSYM
Obstructing
file://localhost/projects/game_name/build/Release-iphonesimulator/game_name.app.dSYM/:
warning: Obstructing: /projects/game_name/build/Release-iphonesimulator/game_name.app.dSYM is blocking item under version control
and
fx_swish_01.wav
Missing File
/projects/game_name/fx_swish_01.wav
file://localhost/projects/game_name/fx_swish_01.wav: warning: Missing file: /projects/game_name/fx_swish_01.wav is missing from working copy
Those are the 2 errors, but I have 113 total (about 10 of the obstructing, and 100 of the missing). I'm assuming this is because the project somehow still thinks I am using SVN for my SCM, when in fact I am using ONLY perforce from outside of Xcode.
Does anyone have a clue on what I need to do? I don't care if files get clobbered, ignored, deleted, whatever... I have everything in perforce that I think I need. Thanks in advance.
EDIT:
I got some of the 'missing from working copy' warnings by doing: svn delete --force. Is this going to bite me later down the line? I couldn't commit, but it did remove the warning. Here is a copy of what I did:
$ svn delete fx_swish_01.wav
svn: Use --force to override this restriction
svn: 'fx_swish_01.wav' has local modifications
$ svn delete fx_swish_01.wav --force
D fx_swish_01.wav
$ svn commit -m "deleted fx_swish_01.wav"
svn: Commit failed (details follow):
svn: Directory '/projects/game_name/build/Release-iphonesimulator/game_name.app.dSYM/.svn' containing working copy admin area is missing
$ svn delete fx_swish_02.wav
D fx_swish_02.wav
$ svn delete fx_swish_03.wav
D fx_swish_03.wav
$ svn delete fx_swish_04.wav
D fx_swish_04.wav
$ svn delete hey_what_a_crowd.mp3
D hey_what_a_crowd.mp3
$ cd build/Release-iphonesimulator/
$ ls
game_name.app game_name.app.dSYM game_name.app_old.dSYM
$ svn delete game_name.app.dSYM
svn: Directory 'game_name.app.dSYM/.svn' containing working copy admin area is missing
$ svn delete game_name.app.dSYM --force
D game_name.app.dSYM
svn: Directory 'game_name.app.dSYM/.svn' containing working copy admin area is missing
As you can see, I got the .wav files to remove and it seems to not give me those warnings anymore. The game_name.app.dSYM thin is still not working though... the admin area is missing? I'm sure if that file existed at one point, it sure don't anymore.
Since you switched away from svn, you can delete all the .svn folders that are probably left over from your previous version control efforts.
Checking out a fresh copy from Perforce should also work, provided you have not checked-in the .svn folders into p4, in which case you should delete them all from p4.
The answers provided in this post should help you solve the warnings you are seeing that pertain to missing files: Missing file warnings showing up after upgrade to XCode 4
I installed subversion on my Ubuntu server and I can use subclipse (1.6) in Eclipse Helios on Ubuntu and it works fine.
However when I try and use Subclipse (1.6) in Eclipse Helios on Windows, it doesn't work and I get errors.
In Windows when I use http://serverAddress/svn, I get an error saying folder doesn't exist and an error in the console saying:
Repository has been moved
svn: Repository moved permanently to 'http://serverAddress/svn/'; please relocate
When I use svn://serverAddress/svn, I get an issue as well.
Does anyone have any ideas?
This is not an Eclipse issue, but a SVN issue.
If you could see your repo in a web browser, the SVN FAQ mentions an httpd.conf error. But in your case:
either you haven't created a repository yet (see svnadmin create)
or you have a repo, but haven't create properly a directory in it, a bit like in this thread:
I then created a subdirectory "projectx" under ~/webapps/svn with subdirectories "trunk", "branches" etc and then ran:
$ svn import projectx file:///home/<user>/webapps/svn/projectx -m "first import".
projectx/trunk etc showed up fine on Trac, and https://svn.<user>.webfactional.com/projectx/ showed up fine in the browser, with proper authentication etc. All well and good.
However, when attempting to check out the project from trunk (using Tortoise SVN), I got this error:
Command: Checkout from https://svn.<user>.webfactional.com/projectx/trunk, revision HEAD, Fully recursive, Externals included
Error: Repository moved permanently to
Error: 'http://svn.<user>.webfactional.com/projectx/trunk/'; please relocate
With the solution being:
You've created directories on the filesystem below your repo, eg ~/webapps/svn/projectx. That's the wrong way.
You should instead use 'svn mkdir' to create the directories.
If this is not enough, see also this SO question, where it mentions that the repository address is usually http://servername/svn/repositoryname, not http://servername/svn.
Here's what I did, I have installed svnserve as a service and I started it with the net start svn service command. I typed svn ls svn://localhost to test the service but it returned the error as stated in the title of this post.
I entered svn --version and svnserve --version on my computer to find out the version numbers and the client and the server version is the same, version 1.5.6. I'm guessing the error appears due to different versions of the server and the client.
When I start the server using svnserve --daemon --root command in cmd, The error still appears.
Why does the error appear? Thanks
Which Subverson tool did you use to create the repository? TortoiseSVN? Your TortoiseSVN may be newer, a 1.6.x release, then your 1.5 command line client and svnserve, so svnserve 1.5.x cannot serve a 1.6.x repository.
In my fsfs repository created with svnadmin 1.6.1, the db/format file contains
$ cat repos/db/format
4
layout sharded 1000
I have the same problem but I had resolve it with a different approach
The issue mainly is the db/format file where it expects a "2" best way to check is to ope the file
$ vi db/format
If you get this
4
layout sharded 1000
Then you should change them to say
2
Its better to also check you current file
$ vi db/current
It you get only this (e.g. 0 meaning reviosion number 0)
0
Then you should change them to just say (e.g. 0 meaning revision number append "nx" and also "2" )
0 nx 2
Finally Check also if your directory structure for the revs and revprops is sharded or looks something like this
db/revs/0/0
change it to a non folder structure
db/revs/0
Note: the revision file (e.g. 0) is just inside the revs directory, no more other folder should be there
Same goes with revprops
change
db/revprops/0/0
to
db/revprops/0
I delete my old repository and create a new one using command line -> svnadmin create C:\SvnRepository
*old repository was created by right clicking on the folder and click "Create Repository here"
I installed (the Collabnet install of) SVN 1.5.5 and it was running fine with TortoiseSVN 1.6.1. After upgrading SVN to 1.6.2 I'm getting the same error (Expected fs format between ‘1’ and ‘3’; found format ‘4’) when I try to access it through Trac. This lends credibility to Blair's answer. I'll let you know how I get it running again.
Update: Blair's answer worked for me, too: the message says that an old version of SVN is trying to access the repository, so find it and delete it. The specifics for me were that the error only occurred when I used Trac, so I re-installed Trac on Windows (http://trac.edgewall.org/wiki/TracOnWindows) with the latest installer I could find (svn-python-1.6.1.win32-py2.5.exe) and deleted old eggs from the Python site-packages folder. After a reboot and resync, I was up and running again.
The latest version of Zend Studio (8.x) has an SVN tool which gives the same error about finding format 4, but expecting format 1-3. I had created my repository using CollabNet SVN (about a year ago) and was unable to open the repository from within Zend Studio.
I think the best solution (at least for my case where I want to work with Zend Studio and not fight with it) is to recreate your repository with the old version of SVN. The URL for SVN 1.3 for Windows is:
http://subversion.tigris.org/files/documents/15/32856/svn-1.3.2-setup.exe
After installing this, make sure you are executing the svnadmin.exe and svn.exe in the newly installed version 1.3 directory in case you have already installed CollabNet SVN (which has a default install directory of c:/csvn).
Make sure you are using the correct svnadmin. For example, if you installed VisualSVN, you will need to use the svnadmin located in the bin folder of the installation directory. I had installed the command line version of SVN...and when I used this version of the svnadmin tool, I got the same error.
Thanks, Joe. I had both CollabNet SVN server and VisualSVN installed and was getting errors until I made sure I was using the version of svnadmin that came with VisualSVN (which I had used to create the repositories).
I was able to fix this by updating Subversion on the server. I also made the adjustment on the db file. Then I pushed everything backup onto the server as an overwrite. I actually (on windows) did a checkout locally, then the files that were generated in creating that repo, I edited the db, then grabbed all files and pushed them up to SVN on the server.
That seemed to have done the trick.
well i have also faced the same problem.
just open your svn remote folder you have made.
in your db folder you have format file.
just replace the no. with 1.
if it does not work try 2, and 3.
If you are using VisualSVN server, Make sure your command looks similar as below
Sample Command:
C:\Program Files\VisualSVN Server\bin>svnadmin dump c:\repo > c:\backup\svnbacku
p.dump