svn: MKACTIVITY 403 Interdit

Vérifiez si vous avez fourni les informations d’identification correctes ou si vous avez suffisamment de droits pour accéder à ce repository (en consultant généralement les fichiers authz, si vous pouvez gérer la configuration du serveur). Comme l’a dit un commentateur ci-dessus, il s’agit d’un problème de permission.

Je ne sais pas si cette réponse vous aide, mais dans mon cas, cela a quelque chose à voir avec les noms de domaine du serveur et la sensibilité à la casse.

L’URL utilisée pour cette copie de travail était

https://bhm18a.serona.org:8443/svn/nebeam/eco/twigs/apple2010

au lieu de l’URL correcte

https: // bhm18a: 8443 / svn / NeBeam / eco / twigs / apple2010

Honnêtement, la mauvaise URL a fonctionné pour “vérifier” et “mettre à jour” et parcourir le référentiel, mais pas pour “copier” ou “valider”.

L’extraction d’une nouvelle copie de travail à l’aide de l’URL exacte a fait disparaître les problèmes.

(Utilisation de subversion 1.6.12 avec Visual SVN Server installé sur un serveur Microsoft Windows)

Vérifiez la casse dans le chemin du référentiel.

Je traverse cette question tout le temps et

 rm -rf ~/.subversion/auth 

travaille toujours pour moi.

Supprimez ce répertoire et essayez à nouveau de vous engager.

La casse dans le chemin du référentiel DOIT correspondre à la casse sur le serveur. J’ai passé de nombreuses heures à déterminer pourquoi certains utilisateurs pouvaient commettre des modifications sur 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 minuscule “../svn/robotconfig” lorsque le nom du référentiel était en fait “../svn/RobotConfig”. Après avoir effectué une nouvelle extraction avec le nom de référentiel correctement placé, les utilisateurs ont pu valider les modifications.

Dans mon cas, la «solution» était la suivante: L’administrateur stupide de notre société a simplement tout changé, de SVN à GIT, sans en informer les développeurs. Sérieusement.

J’ai le même problème. J’utilise Intellij et j’ai résolu ce problème en procédant comme suit:

1. Fichier -> Paramètres
2. Sous “Version Control”, sélectionnez “Subversion”.
3. Dans l’onglet Général, trouvez & cliquez sur “Clear Auth Cache”.
4. Hit Ok.
5. Essayez d’enregistrer des modifications et l’Intellij vous interrogera sur vos informations d’identification.

Il semble que ce problème se soit produit après que vous svn switch --relocate commande svn switch --relocate sur votre twig svn switch --relocate .

Prendre plaisir!

Cela peut également se produire si l’utilisateur place un espace à la fin de son nom d’utilisateur. Notre configuration est svn via http dans apache. Si un utilisateur place des espaces à la fin de son nom d’utilisateur, celui-ci sera réduit et apache réussira l’authentification. 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 dossier d’URL impair. Windows ne fait aucune différence dans le cas du système de fichiers, mais svn le fait (même lorsqu’il est exécuté sur Windows). Voir quelques informations à ce sujet ici .

Identité à la casse était le problème pour moi. L’administrateur m’a dit que mon nom d’utilisateur était … “MyName”, qui fonctionnait pour la vérification et la mise à jour, mais sur commit, il fallait utiliser “myname” en minuscules.

L’erreur 403 Forbidden s’est produite après avoir modifié le fichier .htaccess pour limiter les méthodes de requête avec:

 RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|POST|PROPFIND|OPTIONS|PUT)$ [NC] RewriteRule .* - [F,NS,L] 

Cela m’a été fait en utilisant Eclipse avec le plugin Subversive. Effectuer une équipe> Le nettoyage du projet a résolu le problème.

J’ai résolu ce problème, le problème est lié aux anciennes informations d’identification stockées dans les dossiers ci-dessous \Users\\AppData\Roaming\Subversion\auth\svn .Simple

Il suffit de sauvegarder les fichiers de ce dossier et de tout supprimer et d’essayer à nouveau de les commettre, SVN ou Subclipse vous Subclipse le nom d’utilisateur et le mot de passe et à le faire, il le fera.

J’ai mis à jour mon éclipse et commencé à avoir le même problème.

J’ai fait tous les trucs, rien ne semble fonctionner. Mais la vieille éclipse fonctionne toujours.

Donc, j’ai réalisé que quelqu’un dans l’équipe informatique avait changé la casse du nom de domaine, donc mon userId est passé de:

DOMAIN \ nom d’utilisateur au domaine \ nom d’utilisateur

Ainsi, après la suppression de \Users\\AppData\Roaming\Subversion , la boîte de dialog de connexion réapparaîtra et reviendra sur la piste.

Dans mon cas, la racine du problème n’était pas dans le cas mais dans le port svn modifié.

Corrigé ceci avec la relocalisation de la copie de travail:

 svn switch --relocate https://svn.company.com/svn/path/twigs/java8 https://svn.company.com:465/svn/path/twigs/java8 

J’avais exactement le même problème lorsque je m’engageais pour la première fois pour une nouvelle twig svn, en raison de l’utilisation de minuscules dans le chemin de l’URL alors qu’il aurait dû être en majuscule à la fin de la transaction. Dans le dossier .svn du répertoire d’extraction racine, recherchez le fichier wc.db, ouvrez-le dans un éditeur de texte, remplacez le chemin d’URL incorrect par le chemin correct de l’URL, puis enregistrez le fichier. Ne recommencez pas, vous n’aurez plus ce problème.