Come si fa a risolvere un conflitto SVN 409 Errore

Question

Ho usato per usare SVN 1.4 su OS X Leopard e tutto è andato bene. Un paio di settimane fa ho installato una nuova copia di OS X 10.6. La versione di SVN che viene fornito con Snow Leopard è 1.6.5. Sono andato avanti e costruito la mia propria copia con 1.6.6. Sto utilizzando il costruito nel server Apache e solo di hosting repository a livello locale.

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 nuovi. Stessa cosa. Ho anche provato ad utilizzare la versione 1.6.5 che viene fornito con il sistema ... stesso. Infine, ho provato l'aggiornamento alla più recente SVN stabile (1.6.9) e ancora avuto lo stesso problema.

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

[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 non vede che e tutto diventa irregolare.

Ho cercato di Google ogni variazione che posso pensare per questo problema, ma i risultati della ricerca vengono praticamente inutile. Non sto usando TortoiseSVN o qualcosa di speciale e commette fallire su un nuovo repository, quindi so che non è un problema con i miei vecchi pronti contro termine.

Qualsiasi aiuto sarebbe molto apprezzato.

Aggiorna
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 scherand suggerito). Stavo costruendo una copia di entrambi utilizzando il pacchetto di dipendenze sovversione. OS X 10.6 ha anche un proprio versione. Entrambe le versioni sono state 1.3.8. A quanto pare, però, avevo bisogno di usare le versioni che l'apache installazione di default stava usando.

Quindi, ho cancellato il TAEG e cartelle apr-util dal mio eversione accumulo, per assicurarsi che non stavo costruendo una copia di questi ancora una volta. Ho costruito svn dalla fonte di nuovo, questa volta utilizzando la seguente configurazione:

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

Dopo aver costruito ancora una volta, ho riavviato apache, e ha creato un nuovo repo svn. Sono stato in grado di check it out, apportare le modifiche, e impegnarsi senza problemi. Allora ho provato le mie vecchie pronti contro termine e di quelli lavorato pure.

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 delle pre- o post-commit ganci a posto?
2. È " autoversionamento " abilitato?

Se ci sono ganci, sei sicuro che non contengano errori? Si potrebbe disattivarli per un test? Se autoversionamento non è abilitato, si potrebbe provare ad abilitare 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 aiuterebbe a far luce sul problema e ci (e / o Google :)) potrebbe prendere da lì.

A proposito: I registri hai postato non sono dalla stessa commit, giusto? La differenza di tempo sarebbe enorme?!?

Modifica Ci scusiamo se si hanno scoperto che molto tempo fa, ma io dare un colpo: Could non unire risorsa su COMMIT (Apache 2.0.55) è qualcosa che Google ha trovato per me:)

Il PO ci scrive che "Apache detta la versione di aprile da usare". Questo significa che si deve fare riferimento al corretto APR-versione durante la compilazione SVN. Ho installato SVN (v1.6.9) attraverso MacPorts sul mio sistema (OS X 10.6). Non utilizzare WebDAV o Apache a livello locale, ma devo aprile 1.3.12_1 installata (solo per riferimento). Il PO suggerisce di utilizzare --with-apxs=/path/to/bin/apxs durante la compilazione SVN anche se non sono sicuro se questo si applica alla vostra situazione (ho iniziato a indovinare molto tempo fa, si può notare:)).

C'è qualche possibilità che si potrebbe verificare 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 di Costruire Apache the Way You Want It :

  

apxs è un'utility stand-alone per   compilazione moduli dinamicamente senza   la necessità di utilizzare lo script configure   o avere il codice sorgente di Apache   a disposizione. Essa ha bisogno di Apache   file di intestazione, però, che vengono copiati   nella posizione definita dalla   --includedir quando è installato Apache. Tuttavia, è importante utilizzare un apxs   che è stato costruito con la stessa   le opzioni di configurazione come Apache ;   in caso contrario, farà erronea   ipotesi su dove Apache   varie posizioni di installazione sono.

Answer 2

Ho due idee di dove il problema può essere nascosto, che sono naturalmente congetture selvagge, quindi fate attenzione.

Da un lato si può essere solo un problema di permessi dei file. Lo so, che può sembrare stupido, ma forse c'è qualche file di configurazione, o un gancio come scherand suggerito, o anche qualche cartella all'interno della struttura di deposito che è stato lasciato illeggibile sia per l'aggiornamento a 10.6 o quando si costruisce la nuova versione svn, così ho 'd doppio verificare che.

La seconda idea è quella di verificare la compatibilità del svn lavorare versioni copia-client-server-repository. I ragazzi di sovversione giurano che sia 1.5 e 1,6 non rompere la compatibilità a livello di repository con 1.4 (anche se lo fanno su copie di lavoro ). Ma non sarebbe male per verificare che il formato del intero stack è coerente. E mentre ci sei, assicurarsi che le librerie Apache che avete costruito sono compatibili con l'Apache 2.2.11 che viene fornito con 10.6 (ancora una volta, si deve, ma non si sa mai)

E, infine, buona fortuna.

Answer 3

In primo luogo stabilire una linea di base. Su uno stock di installazione di Snow Leopard (10.6.3) qui è 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>

cartella di sovversione creato 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 hai dello stock 1.6.5 repository subversion di lavoro servito da apache. Se non lo fa, allora è più probabile sia la miscelazione di mele in dotazione binari svn / librerie con i propri (macports, ecc) o non ci sono problemi di autorizzazioni. Fai la che si utilizza l'Apple ha fornito i binari. Apple fa modificare leggermente la sorgente e ho incontrato problemi di compatibilità durante la miscelazione 'porte' con 'magazzino' in passato. Per quanto riguarda i permessi, apache viene eseguito come _www utente, gruppo _www. Assicurarsi che tutti i file e le directory sono di proprietà in quanto tali, e non dimenticate di aggiornarli ogni volta che si utilizza svnadmin o qualcos'altro di manipolare direttamente il repository svn.

Dato che sta lavorando, spostare il repository 'svn2' indietro nel / / local / svn usr (se non l'hai già fatto), fare un checkout pulito da qualche parte, e provare un test di commit.

Se si sta ancora incorrere in problemi, provare ad aggiornare il repository.

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

Ripetere la cassa / commit di prova.

Come ultima risorsa, il dump e caricare di nuovo 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 la cassa / commit di prova, questa volta con / svn / svn3.

Godetevi il vostro repository fisso ... si spera:)

Aggiorna

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

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

Si noti l'output di svn log (almeno per me) è nulla. svn log da tartaruga è bene, che indica al server (come l'installazione sopra) funziona correttamente.

Un'altra cosa da provare è l'accesso al repository via 'file' invece di 'http'. Copiare l'intera repository alla vostra home directory o da qualche parte l'utente è il proprietario, quindi il check-out (cioè. Svn checkout / Users / Shared / svn / svn2) e cercare di commettere.

Answer 4

Hai provato versioni il client SVN per OSX? La sua non è una soluzione al vostro problema, ma forse davvero un'alternativa. Io e la mia squadra ha avuto alcuni problemi di ottenere SVN e OSX a parlare tra di loro correttamente quindi siamo andati alla ricerca di clienti alternative e versioni lavorato molto per noi.

Answer 5

chown -R apache:apache svn

chmod -R 770 svn

Answer 6

Questa risolto il conflitto a me: ho fatto un backup dei miei file locali, quindi tirato tutto dal server. Poi, quando ho inserito e spinto il mio file di backup, l'errore 409 di conflitto non appariva di nuovo.

Saluti, Kevin