tags:

views:

1902

answers:

7

I'm trying to commit to my local SVN which has been working just fine, but today its giving this error:

Unable to open repository 
'file:///C:/wamp/www/svns/[myproject]/[dir]/[subdir]'

What could be the problem?

Edit: full error:

Commit failed (details follow):
Unable to open an ra_local session to URL
Unable to open repository 
'file:///C:/wamp/www/svns/[myproject]/[dir]/[subdir]'

Second Edit:

Here is the TortoiseSVN and SVN client info:

TortoiseSVN 1.5.7, Build 15182 - 32 Bit , 2009/01/24 22:44:13
Subversion 1.5.5, 
apr 1.2.12
apr-utils 1.2.12
berkeley db 4.4.20
neon 0.28.3
OpenSSL 0.9.8i 15 Sep 2008
zlib 1.2.3
A: 

First three things I'd check:

  1. That a local path is what you intended
  2. That the directory still exists
  3. Permissions on all of the folders in that path.
DannySmurf
I checked the directory and its not 'read only', what other permissions do i need to check on Win Xp? I always use the same method, i.e right clicking the dir and selecting SVN commit (using tortoise SVN) and it works, so pretty sure the local path etc is what it wants
Click Upvote
Okay, well, you need to look into whether the local path is what you intended, since it's your repository. Permissions you need to check are the access control lists on the folders.
DannySmurf
Yes, the local URL is what I intended and yet its not working..
Click Upvote
I'm an admin user and the only account on the computer, so I think I should have enough permissions.. and also nothing has changed between my last commit and today (I think)
Click Upvote
+1  A: 

We also had a problem here with svn in the last couple of days, involving permissions on C:/windows/temp.

Possibly an MS fix has broken how svn accesses its temporary files?

This could be entirely unrelated to what your experiencing, but it seems similar to what we had.

Mark Pim
I'm not using the Temp directory though so I don't think this is the issue. Are you using Tortoise SVN?
Click Upvote
+4  A: 

Don't forget to run

svnadmin verify path\to\repository
Stefan
+6  A: 

Have you upgraded one or more of your subversion clients recently?

All your clients should be at the same level (All 1.4., all 1.5., or soon all 1.6.*) if they access your repository directly.

Technically you can get away with some other combinations, but as you need them to be the same version for your workingcopies too, you should just make them compatible... (Before 1.5.X releases your repository was automatically upgraded to the latest version when you access them with a later version).

Another thing to look out for is that not all clients support the same repository formats. Most support fsfs, but not all support BDB. And to make things worse there are multiple incompatible BDB versions....

TortoiseSVN, AnkhSVN and Slik Subversion have exactly the same BDB versions at the same 1.X.Y level.. For other clients you should read their documentation

Small update: TortoiseSVN 1.6.x will drop support for file:// access to BDB repositories. (You will then need a svnserve or apache server to access these repositories)

Bert Huijben
I dont believe this has anything to do with the 1.6.x update as all the other repositries also hosted in the same directory and file system are working correctly..
Click Upvote
+1  A: 

I think it is likely to be due to one of the following:

  1. BDB 4.4 incompatibility with your svn clients. Check out this link for more information (it is not for Windows but is hopefully still useful) - i.e. upgrade BDB to > 4.4 or migrate to fsfs.
  2. File permission problem. The "Practical Subversion" book has a section on repository permissions that specifically mentions the error you are getting. See link for a preview - generally you will need to double check all permissions. Also: as someone else suggested it may be worthwhile double checking windows temp folder permission as svn may be using this behind the scenes.

It may also be a good idea to migrate to fsfs repository storage.

If this does not help: do you get any further error lines after the

Unable to open repository
'file:///C:/wamp/www/svns/[myproject]/[dir]/[subdir]'
luapyad
+1  A: 

The usage of the file:// URL scheme to access repositories might result in repository corruption since the file:// protocol is stateless by nature, and is often not used when there are multiple users for a repository.

Therefore you might want to use the svn:// URL scheme to verify if the repository has indeed been corrupted. This is because of the manner in which Subversion handles different URL schemes - it uses the repository access layer to handle the URL schemes. Different modules in the RA layer handle the appropriate protocols like file://, svn://, http:// etc. In your case the ra_local module was reporting the error since it handles the file:// URL scheme.

The svn:// URL scheme can be utilized if you are utilizing the svnserve daemon. I'm being a bit presumptuous here, but assuming that you have the svnserve daemon configured to run as a Window Service. The root directory for svnserve is important here - the path in the URL is relative to the root.

Assuming that C:/wamp/www/svns/[myproject] is your repository and the root directory for svnserve is set to C:/wamp/www/svns, you can attempt to access the project using svn://hostname/[myproject].

On a different note, since you are using BDB instead of FSFS, do take a look at the following FAQ entries on the Subversion site:

  1. Recovering the BDB repository Do remember Stefan's advice on running svnadmin verify first before attempting to do a recovery.
  2. Setting repository permissions correctly

PS: Backups are helpful.

Vineet Reynolds
I tried to browse using svn:/[name] but i got the error unknown hostname 'name'. (I didnt put in square brackets of course. Thoughts?)
Click Upvote
Thanks for your url, the svnadmin recover thing fixed it
Click Upvote
The svn url scheme should have been svn://<host>/path . My bad...
Vineet Reynolds
My bad again. Had put a section of the URL in angular brackets. Added the reference on why file:// usage should be avoided.
Vineet Reynolds
A: 

In my case, it must have been a bug in the permission settings of SVN-Tortoise. I had not changed anything but could not import or commit all of a sudden. It was solved only when I reinstalled SVN-Tortoise and created a new repository.

Arjan de Bruijn