Come si corregge "Conferma non riuscita. Il file xxx non è aggiornato. Percorso xxx non trovato."

Question

Recentemente mi sono imbattuto in un problema particolarmente problematico riguardante il commit del risultato di una fusione in sovversione. Il nostro server Subversion è @ 1.5.0 e il mio client TortoiseSVN è ora @ 1.6.1.

Sto cercando di unire un ramo di funzionalità nel mio bagagliaio. L'unione sembra funzionare bene; tuttavia, il commit non riesce con il seguente messaggio di errore.

Commit failed (details follow): 
File 
'flex/src/com/penbay/invision/portal/services/http/soap/ReportServices/GetAllBldgsParamsByRegionBySiteResultEvent.as' 
is out of date 
'/svn/ibis/!svn/wrk/531d459d-80fa-ea46-bfb4-940d79ee6d2e/visualization/trunk/source/flex/src/com/penbay/invision/portal/services/http/soap/ReportServices/GetAllBldgsParamsByRegionBySiteResultEvent.as' 
path not found 
You have to update your working copy first. 

Il mio baule di lavoro è aggiornato. Ne ho persino verificato uno nuovo in una cartella diversa per assicurarmi che non ci fosse alcun cruft locale a fare i conti con l'unione. Ho fatto qualche ricerca in più su questo e penso che parte del problema sia l'errore dell'utente. Penso che i nostri problemi siano:

1. Abbiamo avuto alcuni sviluppatori che hanno lavorato con un client di sovversione prima di 1.5 e alcuni dopo. Credo che questo abbia il potenziale per corrompere le informazioni di fusione.
2. In altri rami abbiamo eseguito unioni parziali. Cioè, non abbiamo sempre eseguito fusioni nella radice del ramo. Questo per facilitare l'aggiornamento degli sforzi di Flex e .NET all'interno dello stesso ramo.
3. Abbiamo eseguito fusioni cicliche (riflessive) sul nostro ramo. Questo è stato fatto perché avevamo più filiali parallele e volevamo aggiornare periodicamente il nostro ramo con l'ultimo codice nel trunk.

Tutte queste cose sono esplicitamente sconsigliate dal libro/squadra di Subversion. Abbiamo imparato la lezione e ora conosciamo le migliori pratiche. Tuttavia, per prima cosa dobbiamo unire e impegnare la nostra ultima filiale.

Qual è il modo migliore per correggere i problemi che stiamo incontrando?

Cancellare tutte le informazioni di unione nel bagagliaio e nel ramo sarebbe una soluzione praticabile? No. Ho fatto questo ma non risolve l'errore che sto ottenendo sopra.

Answer 1

Ho avuto lo stesso problema oggi e non ho fatto alcuna fusione intermedia così dal tuo post di apertura solo il # 1 potrebbe applicarsi - tuttavia ho fatto commit sia da un client SVN in Ubuntu che Tortoises in Windows . Fortunatamente nel mio caso non sono state apportate modifiche al bagagliaio in modo da poter solo sostituire il tronco con il ramo. Quindi versioni svn diverse? Questo è abbastanza preoccupante.

Se si utilizzano le funzioni svn move/copy/delete anche se nel mio caso non è stata persa alcuna cronologia, ho svn spostato il trunk e svn spostato il ramo in trunk.

Answer 2

Oh ragazzo! Questo sembra male! L'unica opzione che posso pensare è che la copia di lavoro è corrotta.

Provare a eliminare la copia di lavoro, eseguire una nuova verifica ed eseguire di nuovo l'unione.

Se ciò non funziona, quindi registrare un bug.

Answer 3

Non sono riuscito a trovare una soluzione soddisfacente a questo problema; tuttavia, ho trovato una soluzione insoddisfacente.

Ho cancellato tutti i file nel trunk e ho eseguito queste modifiche. Ho quindi esportato il mio codice filiale nel bagagliaio, aggiunto tutti i file e effettuato un grosso commit. Questo ha avuto l'influenza del mio baule che imitava il mio ramo 1: 1 (che è quello che volevo comunque).

Sfortunatamente, questo crea una grande divisione poiché la cronologia di tutti i file ora è "persa". Ma a causa di limiti di tempo non sembra esserci alcuna altra opzione.

Sarò comunque interessato a tutte le risposte che altri potrebbero avere, poiché mi piacerebbe sapere qual è la causa principale e come evitarla in futuro.

Answer 4

Penso di aver visto qualcosa di simile quando le cartelle sono state spostate sul server ma le copie di lavoro erano ancora legate alla struttura delle cartelle SVN precedente.Non sono sicuro che qualcuno abbia spostato le cose nel bagagliaio prima che tu abbia avuto la possibilità di unire il ramo.

È una possibilità?

Answer 5

Ho avuto lo stesso problema durante il tentativo di eseguire il commit della mia copia di lavoro. Quello che ho fatto è stato aggiungere la cartella che Subversion riporta come "percorso non trovato" alla lista di ignora. Commit (dovrebbe avere successo). Quindi aggiungi nuovamente la stessa cartella a Subversion. Impegnati di nuovo.

Answer 6

Questo sembra un problema con la proprietà svn:mergeinfo di uscire da wack tra il ramo e il tronco.

che conduce alle seguenti domande (perdonate le mie istruzioni della riga di comando, come ho fatto uso di tartaruga molto):

1. State la fusione a livello di radice tronco o il livello di sottocartella? Nella mia esperienza è sempre meglio fare a livello di root, in questo modo l'intero trunk pensa che sia stato unito piuttosto che solo parte (questo sembra confondere svn grandemente in 1.5.0)

2. La mia prossima domanda è stavi usando il parametro --reintergrate? Non ricordo mai come arrivare a questo in tartaruga, ma quando torni al tronco da un ramo, dovresti usare questo parametro.

3. Hai unificato il tronco nel ramo prima di esserti reintegrato? Questo può aiutare a rimuovere i conflitti che potresti vedere quando ti unisci di nuovo?

4. Avete alcune proprietà svn:mergeinfo sul ramo che non si trovano al livello root? Questo che ho trovato causa sempre problemi. Puoi sempre trovarlo andando svn -R pg svn:mergeinfo. È quindi possibile registrare le posizioni e le revisioni che erano sotto la radice, se li trovate rilevanti poi passare alla radice da svn merge --record-only -r start:end <location> e poi eliminarli dalle posizioni radice sub con svn pd svn:mergeinfo <location> È quindi necessario impegnarsi questi cambiamenti

5. Una volta che hai finito, prova a unire di nuovo.

Answer 7

Ne dubito ma forse l'esecuzione di svn cleanup sulla directory di lavoro aiuterà.

Answer 8

Ho avuto lo stesso problema dopo aver unito un ramo con una tonnellata di modifiche nel mio bagagliaio. Le uniche due soluzioni che ho potuto vedere sono state la soluzione svn move offerta da Pacifika o l'unione manuale dei file con uno strumento diff. Ma ho trovato una soluzione alternativa ...

La macchina che non funzionava era in esecuzione client Subversion 1.6.5. Ho fatto esattamente la stessa cosa su una macchina con Subversion 1.5.4 e ha funzionato! Su entrambe le macchine ho fatto un 1) checkout pulito di trunk, 2) svn merge ..., e 3) svn commit. Il mio server è 1.5.x per quello che vale.

Spero che questo aiuti qualcuno.

Answer 9

Ho appena avuto un problema simile, ma senza alcuna ramificazione o la fusione per causare il problema. La mia soluzione alternativa era:

• svn esportare la mia cartella di lavoro (inclusi file senza versione) in una cartella temporanea.
• rinomina la cartella di lavoro come backup.
• svn checkout the trunk.
• copia tutta la cartella dalla cartella di esportazione temporanea sulla nuova cartella di lavoro.
• svn commit.

Ora sembra tutto a posto.

Answer 10

mi è stato sempre presente sul server di 1.6.2, 1.6.8 tartaruga. Tutto su Windows, nessuna fusione in questo ramo.

Ho rinominato una directory e in qualche modo (probabilmente a causa di AnkhSVN) due dei file all'interno della directory venivano contrassegnati come "sostituiti" anziché "normali". Ci sono state alcune modifiche secondarie aggiuntive ad altri file all'interno della directory.

Ripristino i file contrassegnati come sostituito risolto il problema.

Answer 11

Ho appena avuto questo problema, e la causa sembrava essere che una directory era stata contrassegnata come in conflitto. Per risolvere il problema:

svn update 
svn resolved <the directory in conflict> 
svn commit 

Answer 12

ho incontrato lo stesso problema, ha battuto la testa e ha scoperto che avevo cambiato la directory nella represotory da "/" a "/ trunk" e si è dimenticato di fare il comando "Switch", in TortoiseSVN!

Answer 13

Aveva un problema simile con SVN 1.6.5 su Mac 10.6.5, aggiornato a SVN 1.6.9 e il commit è riuscito.

Answer 14

So che questo è un vecchio post, ma questo problema si verifica ancora abbastanza di frequente. Il modo più semplice che ho trovato per risolverlo è rinominare/eliminare il file .svn/all-wcprops nella cartella interessata, quindi eseguire un aggiornamento e commit.

Answer 15

Wow, questo mi ha portato un po 'a risolvere, poiché stavo usando SVN tramite Eclipse. Alla fine, l'unica cosa che ha funzionato per me è stato il commit di tutti i file non interessati, quindi (con Eclipse closed) rinominare la directory del progetto e ricontrollare il progetto da SVN. Sono contento che funzioni correttamente ora!

Answer 16

Apparentemente SVN non è un programma molto affidabile. Ho avuto lo stesso problema (usando SVN con Turtoise) e l'ho risolto salvando il contenuto del file .cs e poi tornando indietro di 1 revisione. Questo ha dimostrato conflitti come questo: "< < < < < < < filename miei cambiamenti

======= codice fusa dal repository revisione"

, mentre io non ho fatto niente di speciale (solo una volta risistemato una revisione).

Ho sostituito il contenuto di questo file con il contenuto salvato, salvato e quindi selezionato tramite TortoiseSVN → Risolto. Potrei quindi confermare le modifiche al repository.

Answer 17

Ho anche avuto lo stesso problema e ho risolto lo stesso con il seguente metodo

svn resolve --accept=working <FILE/FOLDER NAME> 
svn cleanup 
svn update <FILE/FOLDER NAME> 
svn commit <FILE/FOLDER NAME> -m "Comment" 

Spero che questo vi aiuterà a :)

Answer 18

Ho avuto lo stesso problema quando ho cercato di commettere un pacchetto eliminato (che contiene varie classi java ma nulla dal pacchetto era più necessario).

La mia soluzione/soluzione al fine di risolvere il problema:

• mi tornò tutto il pacchetto
• cancellato il contenuto prima
• commesso il contenuto eliminato
• finalmente ho commesso di nuovo il pacchetto cancellato (e ha funzionato nella maggior parte dei casi :-))

Tuttavia, di tanto in tanto non è stato possibile eseguire il commit di un pacchetto cancellato (che h contiene niente)

mia soluzione:

• Ho creato una classe fittizia nel pacchetto
• e dopo che ho ripetuto la procedura di cui sopra

Il mio ultimo suggerimento ...

Ma a volte aiuta a sincronizzare ancora una volta il pacchetto/progetto e dopo tutto funziona di nuovo bene.

Circa la mia configurazione:

• Eclipse Neon
• SVN Interfaccia: JavaHL (JNI) 1.8.13 (r1667537)
• VisualSVN Server Manager, Versione: 3.3.1

Forse potrei aiutare qualcuno con uno dei miei suggerimenti.

Answer 19

Ho avuto lo stesso problema, non so qual è la ragione dietro di esso, ma ho riparato digitando terminale

svn update 

e poi mi impegno e boma ha funzionato!