[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Commit problem

From: Philip de Vries <philipd_at_novacatv.com>
Date: 2006-04-20 20:33:58 CEST

Hi Russell,
 
I've seen that solution too but my understanding was that it was a problem
associated with BDB.
 
What was the cause of the problem you encountered?
 
 
Thanks,
Philip

  _____

From: RUSSELL.D.JOHNSON@saic.com [mailto:RUSSELL.D.JOHNSON@saic.com]
Sent: April 20, 2006 2:22 PM
To: Philip de Vries; users@subversion.tigris.org
Subject: RE: Commit problem

Philip,
I ran into the same problem as well, with the same setup except we're using
the BDB.
The solution in our case was to downgrade the Subversion server to 1.2.3.

  _____

From: users-return-48083-russell.d.johnson=saic.com@subversion.tigris.org
[mailto:users-return-48083-russell.d.johnson=saic.com@subversion.tigris.org]
On Behalf Of Philip de Vries
Sent: Thursday, April 20, 2006 11:14 AM
To: users@subversion.tigris.org
Subject: Commit problem

Hello,
 
We're having a problem with committing to a repository. The error that
TortoiseSVN gives is:
 
"MKACTIVITY of '/svn/<repository>/!svn/act/<seemingly random formatted
string>': 403 Forbidden"
 
Apache2's access.log gives the same error with the usual user/time/ipaddress
stamping. The error.log gives an "Access denied: '<username>' MKACTIVITY
<repository name>" line.
 
This commit error is showing up with two users and it started with both at
the same time. Checking-out and updating are still working with those
users. It started out as being limited to those two users' computers but
further testing on other computers led to the same problem propagating to
those other "test" computers. The test computers were using the same
username/password as the original two. Other usernames and passwords work
fine.
 
The repository was working fine for a few months and just started the
problem a couple of days ago. Checking the mailing list archives, we found
a message that suggested the problem might be a repository name case problem
but we've tried the most obvious permutations of the case (all the ones in
any configuration and folder) and the error persisted. We've also tried to
reset the users' password and remove the user altogether and nothing.
Completely removing TortoiseSVN (including manually removing all left over
folders in %APPDATA% and related folders) and reinstalling allowed two
commits and then the error came back.
 
The Subversion server is 1.3.0 on Windows Server 2003 with Apache 2.0.55
with the mod_authz_svn and mod_dav_svn modules and the format is FSFS. SSL
is not used. There are no extra scripts added to the server either. The
clients are all Windows XP SP2 with TortoiseSVN 1.3.2 or 1.3.3. The latest
version was tried with the hope that this was a bug and the later version
would correct it--it didn't.
 
Internet searches have revealed lots of instances and variations on this
problem but the repository name case solution was the only actual fix that I
saw. There was another about a user switching to SSL as a solution but that
was because the user was trying to log into a server without SSL when he
should have been using SSL.
 
Any ideas?
 
 
Thanks,
Philip
Received on Thu Apr 20 20:36:07 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.