je me fais cette erreur tout en essayant de s'engager dans un dépôt svn:svn: MKACTIVITY 403 Interdit
svn: MKACTIVITY of '/svn/Demo/!svn/act/e2e65cfa-...4165f': 403 Forbidden (http://svn....com:8088)
Toute idée pourquoi? J'ai beaucoup googlé, mais je ne trouve pas de solution qui fonctionne pour moi.
Vérifiez que vous avez fourni les informations d'identification correctes ou que vous avez suffisamment de droits pour accéder à ce rapport (en général, en regardant les fichiers authz, si vous pouvez gérer la configuration du serveur). Comme un commentateur a dit ci-dessus est un problème d'autorisation.
Vous avez le problème après avoir changé mon mot de passe Subersion, mais pas mis à jour le mot de passe enregistré TortoiseSVN. Message sur la façon de changer le mot de passe TortoiseSVN: http://stackoverflow.com/questions/4034026/how-to-change-password-using-tortoisesvn –
Cela n'a pas fonctionné pour moi. Dans mon cas, c'était un problème avec le cas d'URL comme décrit dans la réponse de Stiefel: http://stackoverflow.com/a/3289512/1385405 et dans cet article: http: //stackoverflow.com/a/57148/1385405 – gfrigon
@gfrigon qui a fonctionné –
Cela peut également se produire si l'utilisateur place un espace à la fin de son nom d'utilisateur. Notre configuration est svn via http in apache. Si un utilisateur place un espace à la fin si son nom d'utilisateur, il sera rogné et apache passera l'authentification cependant. Cependant svn ne parviendra pas à trouver le nom d'utilisateur et vous obtiendrez cette erreur plutôt cryptique.
Cela peut également se produire en raison d'un problème de cas d'URL étrange. Windows ne fait pas de différence dans le cas du système de fichiers, mais svn le fait (même lorsqu'il s'exécute sous Windows). Voir quelques informations sur ce here. Double vérification du boîtier dans le chemin du référentiel.
Je ne sais pas si cette réponse vous aide, mais dans mon cas cela avait quelque chose à voir avec les noms de domaine du serveur et la sensibilité à la casse.
L'URL que nous avons utilisé pour cette copie de travail était
https://bhm18a.serona.org:8443/svn/nebeam/eco/branches/apple2010
au lieu de l'URL correcte
https://bhm18a:8443/svn/NeBeam/eco/branches/apple2010
mystérieusement, la mauvaise URL travaillé pour "vérifier" et « mise à jour "et en parcourant le dépôt mais pas pour" copier "ou" commettre ".
L'extraction d'une nouvelle copie de travail en utilisant l'URL exacte a fait disparaître les problèmes.
(Subversion 1.6.12 avec le serveur de Visual SVN installé sur un serveur Microsoft Windows)
Cela devrait être la bonne réponse! –
C'est une bonne réponse! –
A travaillé pour moi, merci beaucoup! – attaboy182
L'erreur 403 Forbidden est arrivé après que je modifié le .htaccess pour limiter les méthodes de demande avec:
RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|POST|PROPFIND|OPTIONS|PUT)$ [NC]
RewriteRule .* - [F,NS,L]
Case dans le chemin du référentiel DOIT correspondre à l'affaire sur le serveur. J'ai passé de nombreuses heures à rechercher les raisons pour lesquelles certains utilisateurs pouvaient modifier le référentiel et d'autres pas. Il s'avère que la vérification initiale pour les utilisateurs "interdits" a été faite avec l'URL en minuscules "../svn/robotconfig" quand le nom du dépôt était en fait "../svn/RobotConfig". Après avoir effectué une nouvelle extraction avec le nom du référentiel correctement encapsulé, les utilisateurs ont pu valider les modifications.
Juste cela m'avait arriver en utilisant Eclipse avec le plugin Subversive. Effectuer une équipe> Nettoyage sur le projet l'a corrigé.
Le nom d'utilisateur sensibilité à la casse était le problème pour moi. L'administrateur m'a dit que mon nom d'utilisateur était ... "MyName" qui a fonctionné pour la caisse et la mise à jour mais sur commit, "myname" doit être utilisé en minuscules.
Dans mon cas, la "solution" était: L'administrateur stupide dans notre société a simplement tout changé de SVN à GIT sans communiquer cela aux développeurs. Sérieusement.
lol, vraiment? ça sonne pas très gentil;) – Tobias
Vous l'aviez à venir. –
je cours à travers cette question tout le temps et
rm -rf ~/.subversion/auth
travaille toujours pour moi.
Supprimez ce répertoire, puis réessayez de valider.
Je résolus cela, la question est de vieilles lettres de créance qui sont stockés dans les dossiers ci-dessous \Users\<Your user name>\AppData\Roaming\Subversion\auth\svn .Simple
Juste ramenaient d'fichiers de ce dossier et supprimer tout et essayer de commettre à nouveau, SVN ou Subclipse sera invite nom d'utilisateur et mot de passe et fournissez-le et fait, il s'engagera.
J'ai mis à jour mon éclipse et j'ai commencé à avoir ce même problème. J'ai fait toutes les ficelles, rien ne semble fonctionner. Mais l'ancienne éclipse fonctionne encore.
Alors, je me suis aperçu que quelqu'un dans l'équipe informatique a changé le nom de domaine le cas, donc mon userId changé de:
DOMAIN \ nom d'utilisateur au domaine \ nom d'utilisateur
Ainsi, après suppression \Users\<Your user name>\AppData\Roaming\Subversion, signe dans le dialogue montrer à nouveau et de nouveau sur la bonne voie.
J'ai rencontré exactement le même problème lors de la première validation d'une nouvelle branche svn, qui était due aux minuscules utilisées dans le chemin d'URL alors que cela aurait dû être en majuscule au moment du paiement. Dans le dossier .svn du répertoire racine de la caisse, recherchez le fichier wc.db, ouvrez-le dans un éditeur de texte, effectuez un remplacement global du chemin URL incorrect avec le chemin URL correct, enregistrez le fichier. Recommencez, vous n'aurez plus ce problème.
J'ai le même problème. J'utilise Intellij, et je résolu ce problème en procédant comme suit:
Il semble que ce problème est arrivé après que vous faites sur votre commande svn switch --relocate branche check-out.
Profitez-en!
merci pour l'indice, quelle version de intellij? – shareef
Version Intellij: 14. –
Dans mon cas, la racine du problème n'était pas dans le boîtier, mais dans le port svn changé.
fixe ce déplacement avec la copie de travail:
svn switch --relocate https://svn.company.com/svn/path/branches/java8 https://svn.company.com:465/svn/path/branches/java8
ressemble à un problème de permissiosn –
Oui, cette erreur peut se produire lorsque vous n'avez lu l'accès à un dépôt – PhilMY
@PhilMY Cest pas vrai. –