DougHughes.net

I’ve experienced a similar phenomenon, although it wasn’t quite as confusing because I couldn’t checkout either. So the troubleshooting led me to the URL casing sooner. My Subversion setup is also Apache on Windows, using virtual directories to define different groups of repositories. The URL case has to match the way I entered the virtual directory names in the config file, but the case after the virtual directory doesn’t have to match because Windows will allow it.

Interesting. Thx for sharing this problem.

LikeLike

Sweet ajax comment handling, btw…

LikeLike

Minor correction…virtual *hosts*, not directories. Duh.

LikeLike

why u deleted it? no funny u!!! where is my comment? u bad u.. u forbid me then delete me, why? shame on u.

LikeLike

haha, thanks a lot. you solved my headache s also

LikeLike

Same problem here…..only i don’t change case….ahhh on to another blog it is…

LikeLike

I had exactly the same problem. Your solution worked like a charm. Thanks a lot, saved my time.

LikeLike

Thanks! You saved the day!

LikeLike

I’m one of those upper/lower case disregarders spoiled by Windows.
I changed the case and – voil – it worked

Thomas
Germany

LikeLike

Saved the day for me too.

LikeLike

Thanks for posting this, found after many dead-ends through Google.

My case seemingly was URL-related as well, which was fixed by “relocating” the repository (using TortoiseSVN).

Things had been working perfectly fine until commits just started failing one morning – checkouts worked fine. Commits also worked fine for other developers in my team!

Commits started working again after changing the repository location from http://host:8080/svn/ProjName/trunk to http://Host.domain.org:8080/svn/ProjName/trunk – I used “Host.domain.org” exactly as specified case- and DNS-wise when installing VisualSVN Server.

Hope this helps someone…

LikeLike

Thanks for this solution ,I have been trying to find the same from google for 2 days.Your solution is just the perfect for this problem..

LikeLike

Thanks!!! Worked like a charm.

LikeLike

Thank you for posting this. This was driving me crazy!

LikeLike

Thanks!

LikeLike

Great!

I had the same problem, thanks for the post!

Thank you also, Vijayan, since I didn’t know the “relocate” of TortoiseSVN, it saved me a lot of time!

Cheers,
Cyril

LikeLike

hey, thanks a lot for this post, i was having the exact same problem and you really saved me a lot of trouble here!
and like Cyril said also, thanks Vijiayan for the tip on the ‘relocate’ command, i was about to do a fresh checkout, wich would have taken at least a couple of hours !

LikeLike

Thank you so much for this blog entry. I encounter the similar problem, and yes.. it’s caused by the wrong case as you described.

LikeLike

Hello all,
I’ve encountered the same problem. Changing the letter casing didn’t help. I’m not sure if this will help for sure, but I’ve solved te problem by relocating my project and downloading model via svn to directory with shorter browse path (for example C:model).
Try not to use long browse paths and just to be sure, aviod using diacritical points or spaces in directories names.
Hope this will work for you all.

LikeLike

This error is ridiculous. It makes no sense that you are able to checkout a project with the wrong case, but then are forced to use the right case to commit. I hope that CollabNet fixed this for version 1.5!

LikeLike

Thank you for posting this. This was driving me crazy! ))

LikeLike

for 403 Forbidden error i have a solution
Basically this is all about Permission deny to commit into Repository. This means you don;t have write permission.
Admin shoyld change his authorixation file to give your id rw perm. Auth file location can be found from httpd.conf file if appache is running in your system
directive in httpd.conf looks like
AuthzSVNAccessFile /path/to/authfile

be careful only admin can do it

LikeLike

>> Tony: “I hope that CollabNet fixed this for version 1.5!”

I’m running 1.5 and just received this error – so it’s not fixed yet…

LikeLike

Thanks a lot! It helps me. It shows me the way! 🙂 Casing is very important, especially at work with different operating systems.

Best regards,
Lark http://www.topnomer.ru

LikeLike

Thanks man this help me also!

LikeLike

I had the same problem with subversion only the case was off for my username. Subversion gives a completely different exception for invalid user/password, but gives the forbidden exception when the credientials are correct except for the case of the user.

LikeLike

Thanx a lot, I had the 403 forbidden and to add path to SVN authorization file in httpd.conf worked

LikeLike

Well, actually the clue in the error-message is the “HTTP” part, as

http://www.apache.org/dev/committers.html#commit-403

complains commits are only allowed on HTTPS links !!

svn: MKACTIVITY of ‘/foobar/!svn/act/1f177b34-1601-0010-84ad-c180bd3a7ab5’: 403 Forbidden (http://svn.foobar.com)
^^^^
Use the svn switch –relocate command to correct this like:

svn switch –relocate http://svn.apache.org/repos/asf/project/module https://svn.apache.org/repos/asf/project/module

Gr,

Jan

LikeLike

Here is how I fixed the “mkactivity 403 forbidden” error on Windows. We’re using domain authentication in our svn authz file. I was using domainuser in my svn “User Name” field in the Edit Connection window. I could browse the repository but couldn’t commit. When I got rid of the “domain” in the “User Name” field and just used my Windows user name, I could both browse the repository and commit. Oh, I’m on Win XP, TortoiseSVN 1.5.2, and Oracle JDeveloper 10.1.3.

LikeLike

Thanks so much. You helped me get to the root of our issue quickly and saved me from getting a similar headache. 🙂

LikeLike

Thanks for sharing this solution – I had the exact same problem.

LikeLike

note to self: When we go live with the subversion server, make sure everyone uses only lower case in their paths.

Also, I was having this problem with our test server and for the life of me I couldn’t figure it out since all my paths were in exactly the same casing.

In the end I stripped all the old gobbledy gook permissions from my permission file (vestigial permissions as it were) and it worked.

LikeLike

Oh and I also removed the reference to [/] but I don’t know if that was what did it.

nifty submission form BTW

LikeLike

We are using LDAP authentication and the “mkactivity 403 forbidden” occurs when users (Windowsuser :-() log in with mixed case usernames. LDAP seems not to check case, apache does.

LikeLike

Thanks a lot!!!!

LikeLike

thanks

LikeLike

Actually there are two reasons why this can happen. The first being what the blog entry says: differenc case in repository name in URL and on disk. Second being what one of the comments says: checking out with http: and trying to commit, where only https: works (because theres a redirect from http -> https) the latter bit us.

So if you see the case not being the problem, cross-check http/https.

LikeLike

You saved my week. I wa starting to lose my hope.
I had the same problem but the repository name on disk was the same as the URL dir in the server, the case was wrong on the URL used on the client to chechout.
I used TortoiseSVN from 1.5.0 to 1.5.3 on Windows XP 32 and Vista 64.

thanks a lot
Oscar.

LikeLike

Thanks a lot!!!! I’ve got exactly the same problem. Spent 2 desperate hours trying to solve it and finally find your article with solution.

Thanks once more!

LikeLike

Thanks for this! By the way, this was the number one search result in google for “mkactivity 403 forbidden”. 😉

LikeLike

I got same problem today…

Thanks!

LikeLike

Man! You are a life saver.

LikeLike

I had the same error, but my error was that i tried to do the commit with one user that only had read permisions. I add the write permisions and works fine.

LikeLike

You saved my Sunday!

LikeLike

Helal Olsun, (in Turkish it means you are great)

LikeLike

So it took me nearly a week to bang out my 403 Forbidden error. I had right casing and right slashes.

It ended up being that I needed to enable a few more modules that aren’t mentioned anywhere:

specifically, make sure the auth_basic and digest, dav_* modules and the ones that got me: proxy_*.

LikeLike

Thanks for this article
We had a similar problem with our repository.
The matter was effectively a problem on the url case

LikeLike

AS everyone here I had same problem. I’m also thinking in translate this to portuguese to help other people — with credits to you, of course 🙂

LikeLike

commenting to see sweet ajax moves

LikeLike

Thanks for this article. My casing problem was in the authz file.

LikeLike

The error did not leave me too….. Thanks a lot i saved my valuable time.

cheers….
Sunil Ganta

LikeLike

I’d lost few hairs because of this. thanks X2

LikeLike

Saved me a bunch of time. Thanks, man!

LikeLike

Many thanks!
this was getting us crazy, even because only the commit was not working, the update was ok.

LikeLike

Thanks for the blog. However, this did not work for me. Providing Read/Write permission to the Root Repository structure resolved this issue. Hope this helps

LikeLike

OMG! This helped… Why case-sensitive URI:s?… Oh well… The more you know.. 😀

LikeLike

thanks, saved me some time too!

LikeLike

dfsdfsdfsdf

LikeLike

Thanks!

LikeLike

Thanks a lot! If only i found this entry sooner… xD

LikeLike

Thanks! This has been driving us crazy for weeks…finally did some research and came across your page…fixed our problem…very helpful !

LikeLike

We’re using domain authentication
?Using “username” in svn “User Name” field => Fail
?change to “domainusername” in svn “User Name” field => Fail
?got rid of the “domain” in the “User Name” field => Success

I don’t know why??but it works ^^

LikeLike

THANK YOU! What a ridiculous error. What a horrible error message. The SVN boys should be ashamed of themselves.

LikeLike

Could also happen when the svn server is in read only mode. Seen with Google code hosting.

LikeLike

Solved my problem – many thanks!

LikeLike

Thanks a lot! All good noW! 😉

LikeLike

In my case, only the repository name itself was in wrong cases. relocating and done.

thanks a lot!

LikeLike

Great post, BTW the modifying the Authz file to change the casing works, BUT only for one version at a time. Rather have your clients relocate their working copies to the correctly cased URL.

LikeLike

Thank you very much!

I’ve done almoust everything before find your post.

LikeLike

Thank you thank you thank you!

LikeLike

In my case, there was a problem with case-sensitivity.

Our system: VisualSVN server on WS2003, TortoiseSVN clients (various versions)

All of a sudden, commit stopped working on random repositories. After careful inspection of repositories names we solved the problem.

We used TortoiseSVN command ‘relocate’ and changed repo name from ‘nsurname’ to ‘NSurname’ (as on server).

The reason is still unknown.

Thank you for the idea.

LikeLike

Thanku so much!! its just a great idea!

LikeLike

The case wasn’t the issue with mine. Same MKACTIVITY error though. I cleared the TortoiseSVN authentication cache and it started working again….

LikeLike

Thanks for posting! Saved us a bunch of time.

LikeLike

Thanks!

LikeLike

Merci!

LikeLike

Thanks a lot 🙂

LikeLike

Great!!! tried every thing before checking out this place…. Thanks a lot…. 🙂

LikeLike

This still didn’t work for me until I looked at the users/permissions of my subversion repository. I did NOT have read/write permission for the main user of the system… Me. Once I added myself with read/write permission (machinename/myUserName) I was able to successfully add a VS 2008 solution to the svn repository.

LikeLike

Thanks a lot. 🙂

LikeLike

Thank you very much indeed, this just worked fine, I tried a bunch of things but no one solved the problem. I own you one.

LikeLike

Thank you for saving the day. “http://svn.example.com:8080/…” hated me, but “http://svn:8080/…” let me commit. Who knew?

LikeLike

THANK YOU! This has happened to me a few times now and I never figured it out. You really saved me.

LikeLike

Just thank you

LikeLike

Awesome catch. This tip saved my butt today.

LikeLike

Hey fiends, In my case, I think that was a problem with ssl certificates.

Im able to checkout but no commit. Im resolve the problem committing passing the –username option and yeah all my local working copies use the new resoved ssl certificates.

LikeLike

HI guys,
i tried all the above mentioned suggestion but stil facing the same 403 forbidden problem?
can some body tell me wat should i do to get rid of this hell??

Thanks in advance….

LikeLike

Thank you very much! You saved me and my programmers team a lot of time!

Dennis

LikeLike

This can also happen if you are using http ldap auth, and a user places a space at the end of their name. Apache will auth the user, but subversion will not find it in the authz file. Thus you get this error instead of a more typical user not found error.

LikeLike

Thanks… Googling the exact error didn’t give much help.
Your post saved me bro…
Thanks.

LikeLike

Works like a charm. Thanks!

LikeLike

I bookmarked this already dude great work

Regards

LikeLike

Thanks, This saved my day.

LikeLike

thanks! 😀 just read your solution and it works! 😀

LikeLike

Thanks a lot…
it works.. i am having the similar problem and this saved me a lot of time.
THanks again

LikeLike

Thanks a lot…

LikeLike

Finally found the right answer. Thanks for the post.

LikeLike

Finally found the right answer too!!!

Thank you very much!!!!

LikeLike

One more grateful visitor. Thanks for sharing this very useful solution…

LikeLike

Thanks a lot for the solution. I thought i could never solve this.

LikeLike

Thanks! Still helping folks out with your post years later!!!

LikeLike

Thanks a lot!

LikeLike

+1
Thanks for tip !

LikeLike

It is amazing that … if it is considered a bug.. it did not get corrected even after 3 years. Thanks for a good explanation including all other futile efforts.

LikeLike

Heh. @#$% comments formatting! That was supposed to read:

…error trying to do:

svn cp first-url-here 2nd-url-here -F svn-commit.tmp

The casing is exactly…

LikeLike

wonderful post, I met the same problem and so luck to find your solution. Save me lot of time. Thanks.

LikeLike

Thanks a lot!

LikeLike

Amazing how this isnt more spread. Had this for two months and my it dept closed the ticket without a solution. Thanks!

LikeLike

Not only URLs are case-sensitive, the usernames are also case-sensitive!!!

It took me two days of try-and-errors, until I found your blog which lead me in the right direction.

Thanks a lot!

LikeLike

Great, thanks for your help!

LikeLike

Thanks worked for me too .

LikeLike

In case this helps anyone else out, wanted to drop a line. I was getting a forbidden error for a repository I know I’ve saved to successfully for years. The error was

svn: Commit failed (details follow):
svn: access to ‘https://foo.com/svn/beta/trunk/data’ forbidden

[I’ve replaced specifics with ‘foo’ to protect the innocent]

It wasn’t bad case or permissions or anything else I tried. What I eventually realized was that I had added another repository to the same machine and subversion didn’t know how to use the correct username for the repository. If I had repo alpha and beta and the usernames to access the repositories remotely via https were alpha_user and beta_user respectively, only the first authentication information was saved to my account on the new server. I’m sure there’s a more graceful solution, but the quick fix was to add beta_user to the svn-authz file that the server uses to authenticate to the repository. Hope this helps.

LikeLike

Thanks, saved my day.
SVN URLs are indeed case-sensitive when you want to commit changes!!!

LikeLike

Thank You!!!

LikeLike

Muchas gracias, fue de mucha ayuda.

LikeLike

Thanks a lot! Worked perfectly for me too!

LikeLike

Had been hunting for several days for this solution till i chanced upon your blog. Problem solved in a jiffy. Thanks a lot.

LikeLike

i appreciate your information. thanks a lot~^^

LikeLike

Thanks man, I thought something really was wrong there for a moment. Used the scary “relocate” command over here. One might think that it would be easier to remove the case sensitivity one commits though. plz tell if you know how

best regards tompa

LikeLike

Thank you. This helped me out after updating to FB 4.5.

LikeLike

Thank very much. I use the ubuntu, and rapidsvn. I counter the same problem and try to change permission and could not work out until I saw your blog wrote in four years before.

LikeLike

This worked for me as well – after relocating, the casing of the path changed… Thanks for posting this – even if it was four years ago!

LikeLike

Great..Fixed. Thanks a lot

LikeLike

Thank you, it really helped !!

LikeLike

Really this is great fix. I solved my problem in 10 minutes just getting this fix.
Thanks buddy for your post.

LikeLike

Many thanks for this tip!
This problem caused me days of headaches…

LikeLike

Thanks. I don’t know how I would have solved this problem without your post.

LikeLike

Only to add: this also happened to me, but not because wrong casing in URL, but in user id. Lowercase user failed at commit (although checkout worked); uppercase user was needed. Thanks

LikeLike

Thanks buddy .. Saved a lot of time .. deepest gratitude ..

LikeLike

Thank you! This saved me a lot of headache.

LikeLike