2009-06-23 23 views
48

sto ottenendo questo errore durante il tentativo di impegnarsi per un repository svn:svn: MKACTIVITY 403 Forbidden

svn: MKACTIVITY of '/svn/Demo/!svn/act/e2e65cfa-...4165f': 403 Forbidden (http://svn....com:8088) 

Qualsiasi idea del perché? Ho cercato spesso su Google, ma non riesco a trovare una soluzione che funzioni per me.

+3

si presenta come un problema permissiosn –

+1

Sì, questo errore può verificarsi quando hai solo accesso in lettura a un repository – PhilMY

+0

@PhilMY Quello non è vero. –

risposta

22

Verificare se sono state fornite le credenziali corrette o se si dispone dei diritti sufficienti per raggiungere il repository (in genere si guardano i file authz, se è possibile gestire la configurazione del server). Come detto sopra un commentatore è un problema di autorizzazione.

+2

Trovato il problema dopo aver cambiato la mia password di Subersion ma non aggiornata la password salvata di TortoiseSVN. Pubblicare come modificare la password TortoiseSVN: http://stackoverflow.com/questions/4034026/how-to-change-password-using-tortoisesvn –

+2

Questo non ha funzionato per me. Nel mio caso, è stato un problema con il caso dell'URL come descritto nella risposta di Stiefel: http://stackoverflow.com/a/3289512/1385405 e in questo post: http: //stackoverflow.com/a/57148/1385405 – gfrigon

+0

@gfrigon che ha funzionato –

2

Ciò può verificarsi anche se l'utente inserisce uno spazio alla fine del proprio nome utente. La nostra configurazione è svn tramite http in apache. Se un utente posiziona spazi bianchi alla fine se il loro nome utente, verrà tagliato e Apache passerà l'autenticazione. Tuttavia svn non riuscirà a trovare il nome utente e otterrete questo errore piuttosto criptico.

Può anche accadere a causa di un caso di url dispari. Windows non fa la differenza nel caso del filesystem, ma svn lo fa (anche quando gira su Windows). Vedi alcune informazioni su questo here.

7

Cassa doppia nel percorso del repository.

34

Non so se questa risposta ti aiuta, ma nel mio caso ha qualcosa a che fare con i nomi di dominio del server e la distinzione tra maiuscole e minuscole.

L'URL abbiamo utilizzato per questa copia di lavoro è stato

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

invece che l'URL corretto

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

misteriosamente, l'URL sbagliato ha lavorato per "check out" e "aggiornamento "e navigando nel repository ma non per" copia "o" commit ".

Il controllo di una nuova copia di lavoro utilizzando l'URL esatto ha fatto scomparire i problemi.

(usando Subversion 1.6.12 con Visual SVN Server installato su un server Microsoft Windows)

+2

Questa dovrebbe essere la risposta corretta! –

+0

Questa è una risposta corretta! –

+0

Ha funzionato per me, grazie mille! – attaboy182

0

L'errore 403 Forbidden successo dopo che ho modificato il file .htaccess per limitare metodi di richiesta con:

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

Caso nel percorso del repository DEVE corrispondere al caso sul server. Ho passato molte ore a rintracciare il motivo per cui alcuni utenti potevano commettere modifiche al repository e altri no. Si scopre che il checkout iniziale per gli utenti "vietati" è stato fatto con l'URL in tutte le lettere minuscole "../svn/robotconfig" quando il nome del repository era effettivamente "../svn/RobotConfig". Dopo aver effettuato un nuovo checkout con il nome del repository correttamente inserito, gli utenti sono stati in grado di eseguire il commit delle modifiche.

0

Mi è appena capitato di utilizzare Eclipse con il plug-in Subversive. Esecuzione di un team> La pulizia del progetto lo ha risolto.

2

Nome utente La sensibilità alle maiuscole era il problema per me. L'amministratore mi ha detto che il mio nome utente era ... "MyName" che funzionava per il checkout e l'aggiornamento ma su commit, doveva essere usato "myname" in minuscolo.

5

Nel mio caso la "soluzione" era: lo stupido amministratore nella nostra azienda semplicemente cambiava tutto da SVN a GIT senza comunicarlo agli sviluppatori. Sul serio.

+3

lol, davvero? suoni non molto gentili;) – Tobias

+0

L'hai fatto arrivare. –

6

corro in questo problema tutto il tempo e

rm -rf ~/.subversion/auth 

funziona sempre per me.

Eliminare questa directory e riprovare a eseguire il commit.

0

ho risolto questo, il problema è con le vecchie credenziali che vengono memorizzati nelle cartelle sotto \Users\<Your user name>\AppData\Roaming\Subversion\auth\svn .Simple

appena preso il backup dei file da questa cartella e cancellare tutti e cercare di commettere di nuovo, SVN o Subclipse volontà prompt nome utente e password e fornire e fatto, si impegnerà.

0

Ho aggiornato la mia eclissi e ho iniziato a ottenere lo stesso problema.

Ho fatto tutti i trucchi, niente sembra funzionare. Ma la vecchia eclissi funziona ancora.

Così, mi sono reso conto che qualcuno in squadra aveva cambiato il caso nome di dominio, quindi il mio userId cambiato da:

DOMINIO \ nome utente per dominio \ nomeutente

Così, dopo eliminare \Users\<Your user name>\AppData\Roaming\Subversion, segno in finestra mostrare di nuovo e di nuovo in pista.

-1

Ho avuto lo stesso identico problema quando stavo commettendo per la prima volta un nuovo ramo svn, che era dovuto alla minuscola utilizzata nel percorso dell'URL quando avrebbe dovuto essere in maiuscolo al momento del checkout. Nella cartella .svn della directory di checkout principale, trova il file wc.db, aprilo in un editor di testo, esegui una sostituzione globale del percorso URL errato con il percorso URL corretto, salva il file. Ricomincia, non avrai più quel problema.

4

Ho lo stesso problema. Sto utilizzando Intellij, e ho risolto questo problema nel modo seguente: File

  1. -> Impostazioni
  2. In "Version Control" Lista selezionare "sovversione".
  3. Nella scheda Generale, trovare & Fare clic su "Cancella cache di autenticazione".
  4. OK.
  5. Prova ad effettuare il check-in delle modifiche e Intellij ti chiederà quali sono le tue credenziali.

enter image description here

Sembra che questo problema è accaduto dopo che fate svn switch --relocate dei comandi sul ramo controllato-out.

Divertiti!

+0

grazie per il suggerimento, quale versione di intellij? – shareef

+0

Versione intellij: 14. –

0

Nel mio caso la radice del problema non era nella custodia ma nella porta svn modificata.

risolto questo con la delocalizzazione di copia di lavoro:

svn switch --relocate https://svn.company.com/svn/path/branches/java8 https://svn.company.com:465/svn/path/branches/java8 
Problemi correlati