Come si risolve un errore di conflitto SVN 409

Question

Ho usato SVN 1.4 su OS X Leopard e tutto andava bene. Un paio di settimane fa ho installato una nuova copia di OS X 10.6. La versione di SVN fornita con Snow Leopard è 1.6.5. Sono andato avanti e ho creato la mia copia con 1.6.6. Sto usando il server Apache integrato e sto solo ospitando i repository localmente.

Tutto sembrava funzionare bene fino a quando ho effettivamente provato a commettere qualcosa. Ogni volta che provo a commettere un cambiamento, ottengo il seguente messaggio:

Transmitting file data .svn: Commit failed (details follow): 
svn: MERGE of '/svn/svn2': 409 Conflict (http://localhost) 

Questo succede con i miei vecchi repository, così ho creato un paio di quelli nuovi. Stesso affare. Ho anche provato ad usare la versione 1.6.5 che viene fornita con il sistema ... lo stesso. Infine, ho provato ad aggiornare l'ultimo SVN stabile (1.6.9) e ho ancora lo stesso problema.

L'errore Apache registra quanto segue per ogni fallito commettere:

[Mon Mar 29 19:53:10 2010] [error] [client ::1] Could not MERGE resource "/svn/svn2/!svn/act/d399326f-c20f-424f-bb68-3bb40503b5b1" into "/svn/svn2". [409, #0] 
[Mon Mar 29 19:53:10 2010] [error] [client ::1] An error occurred while committing the transaction. [409, #2] 
[Mon Mar 29 19:53:10 2010] [error] [client ::1] Can't open directory '/usr/local/svn/svn2/db/transactions/5-6.txn/\xeb\xa9\x0f\x1f': No such file or directory [409, #2] 
[Mon Mar 29 19:53:11 2010] [error] [client ::1] Could not DELETE /svn/svn2/!svn/act/d399326f-c20f-424f-bb68-3bb40503b5b1. [500, #0] 
[Mon Mar 29 19:53:11 2010] [error] [client ::1] could not open transaction. [500, #2] 
[Mon Mar 29 19:53:11 2010] [error] [client ::1] Can't open file '/usr/local/svn/svn2/db/transactions/5-6.txn/props': No such file or directory [500, #2] 

E dal log di accesso:

::1 - - [30/Mar/2010:13:02:20 -0400] "OPTIONS /svn/svn2 HTTP/1.1" 401 401 
::1 - user [30/Mar/2010:13:02:20 -0400] "OPTIONS /svn/svn2 HTTP/1.1" 200 188 
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2 HTTP/1.1" 207 647 
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2 HTTP/1.1" 207 647 
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2/!svn/vcc/default HTTP/1.1" 207 398 
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2/!svn/bln/6 HTTP/1.1" 207 449 
::1 - user [30/Mar/2010:13:02:20 -0400] "REPORT /svn/svn2/!svn/vcc/default HTTP/1.1" 200 1172 

Curiosamente, il commit realtà non applicare le modifiche, ma la copia di lavoro doesn lo capisco e tutto diventa matto.

Ho provato a Google tutte le varianti a cui posso pensare per questo problema, ma i risultati della ricerca sono praticamente inutili. Non sto usando TortoiseSVN o qualcosa di speciale e commetto errori su un nuovo repository, quindi so che non è un problema con i miei vecchi repository.

Qualsiasi aiuto sarebbe molto apprezzato.

Aggiornamento
Ho provato ad aggiungere autoversionamento al mio file svn.conf. Ecco cosa dice il mio file:

LoadModule dav_svn_module /usr/libexec/apache2/mod_dav_svn.so 
<Location /svn> 
    DAV svn 
    SVNParentPath /usr/local/svn 
    SVNAutoversioning on 

    # how to authenticate a user 
    AuthType Basic 
    AuthName "Subversion repository" 
    AuthUserFile /usr/local/etc/svn-auth-file 

    # only authenticated users may access the repository 
    Require valid-user 
</Location>  

Update (soluzione)

Volevo solo aggiornare questo con la soluzione reale nel caso in cui nessun altro sta avendo lo stesso problema con i messaggi di errore del tutto inutili. Il problema era con le parti apr e apr-util (come suggeriva scherand). Stavo costruendo una copia di entrambi usando il pacchetto delle dipendenze subversion. OS X 10.6 ha anche la sua versione. Entrambe le versioni erano 1.3.8. A quanto pare, avevo bisogno di usare le versioni che stava usando l'installazione di default di apache.

Così, ho eliminato le cartelle apr e apr-util dal mio build di subversion, per assicurarmi che non stavo ricostruendo di nuovo la mia copia di questi. Ho costruito svn dalla sorgente di nuovo, questa volta utilizzando la seguente configurazione:

./configure --with-apr=/usr/bin/ --with-apr-util=/usr/bin/ --with-ssl 

Dopo la costruzione di nuovo, ho riavviato apache e generato un nuovo repo svn. Sono stato in grado di verificarlo, apportare modifiche e commit senza problemi. Ho quindi provato i miei vecchi repository e anche quelli hanno funzionato.

Grazie a tutti per l'aiuto!

Answer 1

Sono sul ghiaccio molto sottile qui (409 non essendo molto specifico), ma sono in grado di formulare due domande:

1. ci sono eventuali pre- o post-commit ganci a posto?
2. È abilitato "Autoversioning"?

Se ci sono dei ganci, sei sicuro che non contengano errori? Potresti disabilitarli per un test? Se l'Autoversione non è abilitata, potresti provare ad abilitarlo per un test? Questo dovrebbe funzionare sulla falsariga di

<Location /repos> 
    DAV svn 
    SVNPath /var/svn/repository 
    SVNAutoversioning on 
</Location> 

quando si utilizza mod_dav_svn (vedi link a autoversionamento sopra).

Forse questo potrebbe aiutare a far luce sul problema e noi (e/o Google :)) potremmo prenderlo da lì.

Btw: i registri che hai postato non provengono dallo stesso commit, giusto? La differenza di tempo sarebbe enorme?!?

Edit: Ci scusiamo se avete trovato che molto tempo fa, ma io darò un colpo: Could not MERGE resource on COMMIT (Apache 2.0.55) è qualcosa che Google ha trovato per me :)

L'OP ci scrive che "Apache detta la versione di APR usare". Ciò significa che è necessario fare riferimento alla versione APR corretta durante la compilazione di SVN. Ho installato SVN (v1.6.9) tramite MacPorts sul mio sistema (OS X 10.6). Non utilizzo WebDAV o Apache localmente ma ho installato APR 1.3.12_1 (solo per riferimento). L'OP suggerisce di usare --with-apxs=/path/to/bin/apxs durante la compilazione di SVN anche se non sono sicuro che questo si applichi alla tua situazione (ho iniziato a indovinare molto tempo fa, potresti notare :)).

Qualsiasi possibilità che tu possa controllare l'APR-versione di Apache si aspetta rispetto a quello utilizzato per costruire SVN (ad esempio, si potrebbe usare sudo port installed apr per vedere che cosa APR-versioni dal vivo sul vostro sistema se si utilizza MacPorts)?

Solo per riferimento un estratto da Building Apache the Way You Want It:

apxs è un'utility stand-alone per moduli di compilazione in modo dinamico, senza la necessità di utilizzare il configure sceneggiatura o avere il codice sorgente di Apache disponibili. Sono comunque necessari i file di intestazione Apache , che vengono copiati nella posizione definita da --includedir quando viene installato Apache. Tuttavia, è importante utilizzare uno creato con le stesse opzioni di configurazione come Apache; altrimenti, si otterranno errate ipotesi su dove sono ubicati i vari punti di installazione di Apache .

Answer 2

Hai provato Versions il client SVN per OSX? Non è una soluzione al tuo problema ma forse è un'alternativa. Io e il mio team abbiamo avuto alcuni problemi nel far sì che SVN e OSX parlassero tra loro in modo corretto, quindi siamo andati alla ricerca di client alternativi e le versioni funzionavano alla perfezione per noi.

Answer 3

Ho due idee su dove il problema potrebbe nascondersi, che sono ovviamente ipotesi selvagge, quindi state attenti.

Da un lato può essere solo un problema di autorizzazioni di file.Lo so, sembra sciocco, ma forse c'è qualche file di configurazione, o un hook come suggerito da scherand, o anche qualche cartella all'interno della struttura del repository che è stata lasciata illeggibile dall'aggiornamento a 10.6 o quando si stava costruendo la nuova versione di svn, quindi io controllalo bene.

La seconda idea è di verificare la compatibilità delle versioni di svn che funzionano con copia-client-server-repository. I ragazzi della sovversione giurano che sia 1.5 che 1.6 non rompono la compatibilità a livello di repository con 1,4 (benché lo facciano su copie funzionanti). Ma non sarebbe male controllare che il formato dell'intero stack sia coerente. E mentre ci sei, assicurati che le librerie di apache che hai creato siano compatibili con l'apache 2.2.11 che viene fornito con 10.6 (di nuovo, dovrebbero, ma non si sa mai)

Infine, buona fortuna.

Answer 4

Stabilire innanzitutto una linea di base. Su un'installazione di scorta di Snow Leopard (10.6.3) ecco esattamente quello che ho fatto.

Creato "/etc/apache2/other/svn.conf" con i contenuti:

LoadModule dav_svn_module /usr/libexec/apache2/mod_dav_svn.so 
<Location /svn> 
    DAV svn 
    SVNParentPath /usr/local/svn 
    AuthType Basic 
    AuthName "Subversion repository" 
    AuthUserFile /usr/local/svn/htpasswd 
    Require valid-user 
</Location> 

creata la cartella sovversione e repository "test":

sudo mkdir /usr/local/svn 
sudo svnadmin create /usr/local/svn/test 
sudo chown -R _www:_www /usr/local/svn 
sudo htpasswd -cb /usr/local/svn/htpasswd testuser testpass 

Da utente normale, home directory:

macmini:~ jclark$ mkdir Checkout && cd Checkout 
macmini:Checkout jclark$ svn --username testuser checkout http://localhost/svn/test 
Authentication realm: <http://localhost:80> Subversion repository 
Password for 'testuser': 
Checked out revision 0. 
macmini:Checkout jclark$ cd test && touch test.txt && svn add test.txt && svn commit -m 'test' test.txt 
A   test.txt 
Adding   test.txt 
Transmitting file data . 
Commited revision 1. 
macmini:test jclark$ 

Ora, se tutto questo ha funzionato come dovrebbe, allora avete un lavoro stock 1.6.5 sovversione reposito servito da apache. Se così non fosse, allora probabilmente stai mixando i file bnn/libs forniti da apple con i tuoi (macports, ecc.) o, ci sono problemi di permessi. Crea sicuro stai utilizzando i binari forniti da Apple. Apple modifica leggermente la sorgente e ho riscontrato problemi di compatibilità nel mixare "porte" con "stock" nel passato. Per quanto riguarda le autorizzazioni, apache viene eseguito come utente _www, gruppo _www. Assicurati che tutti i file e le directory siano di proprietà e non dimenticarti di aggiornarli ogni volta che usi svnadmin o qualcos'altro per manipolare direttamente il repository svn.

Dato che funziona, spostare il repository 'svn2' in/usr/local/svn (se non lo si è già fatto), eseguire un checkout pulito da qualche parte e provare un commit di test.

Se si verificano ancora problemi, provare ad aggiornare il repository.

sudo svnadmin upgrade /usr/local/svn/svn2 
sudo chown -R _www:_www /usr/local/svn/svn2 

Ripetere il checkout/test di commit.

Come ultima risorsa, scaricare e caricare nuovamente il repository.

sudo svnadmin dump /usr/local/svn/svn2 > /tmp/svn2.dump 
sudo svnadmin create /usr/local/svn/svn3 
sudo svnadmin load /usr/local/svn/svn3 < /tmp/svn2.dump 
sudo chown -R _www:_www /usr/local/svn/svn3 

Ripetere il checkout/commit test, questa volta con/svn/svn3.

Godetevi il repository fisso ... speriamo :)

aggiornamento

Ci può essere un bug nel client a riga di comando subversion.Dopo averlo fatto:

mkdir \!vcc && touch \!vcc/default 
svn add \!vcc && svn commit -m 'test' 
svn log 

Si noti che l'output di svn log (almeno per me) non è nulla. Svn log from tortoise va bene, il che indica che il server (come impostazione sopra) funziona correttamente.

Un'altra cosa da provare è accedere al repository tramite "file" anziché "http". Copia l'intero repository nella tua home directory o da qualche parte il tuo utente è il proprietario, quindi controlla (svn checkout/Users/Shared/svn/svn2) e prova a commettere.

Answer 5

chown -R apache:apache svn 

chmod -R 770 svn 

Answer 6

Questo risolto il conflitto a me: ho fatto un backup dei miei file locali, quindi tirato tutto dal server. Quindi, quando ho inserito e inserito i miei file di backup, l'errore di conflitto 409 non è stato più visualizzato.

saluti, Kevin