Come posso correggere “Commit Failed. Il file xxx non è aggiornato. percorso xxx non trovato. "

https://stackoverflow.com/questions/819896

03-07-2019
|

Domanda

Di recente mi sono imbattuto in un problema particolarmente critico per quanto riguarda 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 provando a fondere 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 anche verificato uno nuovo in una cartella diversa per assicurarmi che non ci fosse alcuna truffa locale che si confondesse 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:

Avevamo alcuni sviluppatori impegnati a lavorare con un client di sovversione prima dell'1.5 e alcuni dopo. Credo che questo abbia il potenziale per corrompere le informazioni di unione.
In altre filiali abbiamo eseguito fusioni parziali. Cioè, non abbiamo sempre eseguito fusioni alla radice del ramo. Questo per facilitare l'aggiornamento degli sforzi di Flex e .NET all'interno dello stesso ramo.
Abbiamo eseguito fusioni cicliche (riflessive) sul nostro ramo. Ciò è stato fatto perché avevamo più filiali parallele e volevamo aggiornare periodicamente la nostra filiale con l'ultimo codice nel trunk.

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

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

L'eliminazione di tutte le informazioni di unione nel trunk e nel ramo sarebbe una soluzione praticabile? No. L'ho fatto ma non risolve l'errore che sto riscontrando sopra.

Soluzione

Oggi ho avuto lo stesso problema e non ho fatto alcuna fusione intermedia, quindi dal tuo post di apertura potrebbe essere applicato solo il numero 1, tuttavia ho fatto commit sia da un client svn in Ubuntu sia da tartaruga in Windows. Fortunatamente nel mio caso non sono state apportate modifiche al bagagliaio in modo da poter semplicemente sostituire il bagagliaio con il ramo. Forse diverse versioni svn allora? È abbastanza preoccupante.

Se si utilizzano le funzioni di spostamento / copia / eliminazione di svn anche se nel mio caso non viene persa alcuna cronologia - i svn spostarono il trunk e quindi svn spostarono il ramo su trunk.

Altri suggerimenti

Ho appena avuto questo problema e la causa sembra essere che una directory sia stata contrassegnata come in conflitto. Per risolvere:

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

Lo stavo ottenendo sul server 1.6.2, tartaruga 1.6.8. 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 "sostituito". piuttosto che "normale". Sono state apportate ulteriori modifiche minori ad altri file all'interno della directory.

Il ripristino dei file contrassegnati come sostituiti ha risolto il problema.

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 ti possa aiutare :)

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" all'elenco ignora. Commit (dovrebbe avere successo). Quindi aggiungere nuovamente la stessa cartella a Subversion. Impegnare di nuovo.

Ho appena avuto un problema simile ma senza diramazioni o fusioni per causare il problema. La mia soluzione alternativa era:

svn esporta la mia cartella di lavoro (compresi i file non consultati) in una cartella temporanea.
rinomina la cartella di lavoro come backup.
svn verifica il bagagliaio.
copia tutte le cartelle dalla cartella di esportazione temporanea su una nuova cartella di lavoro.
svn commit.

Ora tutto sembra a posto.

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

Ho avuto lo stesso problema, non so quale sia la ragione dietro ma ho risolto digitando nel terminale

svn update

e poi mi impegno e boom ha funzionato!

Oh ragazzo! Questo sembra male! L'unica opzione a cui riesco a pensare è che la copia di lavoro sia corrotta.

Prova a eliminare la copia di lavoro, eseguendo un nuovo checkout ed eseguendo nuovamente l'unione.

Se non funziona, registra un bug.

Non sono stato in grado di trovare una soluzione soddisfacente a questo problema; tuttavia, ho trovato una soluzione insoddisfacente.

Ho eliminato tutti i file all'interno del trunk e ho eseguito il commit di queste modifiche. Ho quindi esportato il mio codice di filiale nel trunk, aggiunto tutti i file e fatto un commit di grandi dimensioni. Ciò ha avuto l'effetto del mio tronco che imita il mio ramo 1: 1 (che è quello che volevo comunque).

Sfortunatamente, questo crea un grande divario in quanto la storia di tutti i file è ora "persa". Ma a causa di vincoli di tempo non sembra esserci alcuna altra opzione.

Sarò comunque interessato a tutte le risposte che gli altri potrebbero avere dato che vorrei sapere quale fosse la causa principale e come evitarlo in futuro.

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

La macchina che non funzionava stava eseguendo il 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 del trunk, 2) svn merge ... e 3) svn commit. Il mio server è 1.5.x per quello che vale.

Spero che questo aiuti qualcuno.

Si è verificato un problema simile con SVN 1.6.5 su Mac 10.6.5, aggiornato a SVN 1.6.9 e il commit ha avuto esito positivo.

Ho avuto lo stesso problema quando ho provato a eseguire il commit di un pacchetto eliminato (che contiene varie classi java ma non era più necessario nulla dal pacchetto).

La mia soluzione / soluzione alternativa per risolvere il problema:

Ho ripristinato l'intero pacchetto
prima cancellato il contenuto
ha eseguito il commit del contenuto eliminato
finalmente ho eseguito nuovamente il commit del pacchetto eliminato (e nella maggior parte dei casi ha funzionato :-))

Tuttavia, di volta in volta non è stato possibile eseguire il commit di un pacchetto eliminato (che non contiene nulla)

Soluzione alternativa:

Ho creato una classe fittizia nel pacchetto
e successivamente ho ripetuto i passaggi sopra menzionati

Il mio ultimo suggerimento ...

Ma a volte è semplice sincronizzare ancora una volta il pacchetto / progetto e dopo tutto funziona di nuovo alla grande.

Informazioni sulla mia configurazione:

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

Forse potrei aiutare qualcuno con uno dei miei suggerimenti.

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

È una possibilità?

Questo sembra un problema con la proprietà svn: mergeinfo che esce dal pelo tra il ramo e il tronco.

Il che porta alle seguenti domande (perdona le istruzioni della mia riga di comando mentre ho usato molto la tartaruga):

Stai unendo a livello di radice trunk o sottocartella? Nella mia esperienza è sempre meglio fare a livello di root, in questo modo l'intero trunk pensa che sia stato unito a piuttosto che a una parte (questo sembra confondere notevolmente svn in 1.5.0)
La mia prossima domanda è se stavi usando il parametro --reintergrate ? Non riesco mai a ricordare come arrivare a questo in tartaruga, ma quando torni al tronco da un ramo, dovresti usare questo parametro.
Hai unito il trunk nel ramo prima di reintegrarlo? Questo può aiutare a rimuovere i conflitti che potresti vedere quando ti unisci di nuovo?
Hai delle proprietà svn: mergeinfo sul ramo che non sono a livello di root? Questo che ho trovato causa sempre problemi. Puoi sempre scoprirlo andando svn -R pg svn: mergeinfo . Puoi quindi registrare le posizioni e le revisioni che si trovavano sotto la radice, se le trovi pertinenti, spostale nella radice svn merge --record-only -r start: end < location > e quindi eliminali dalle posizioni della radice secondaria con svn pd svn: mergeinfo < location > devi quindi eseguire il commit di queste modifiche
Dopo aver fatto tutto ciò, prova a fondere di nuovo.

Ne dubito, ma forse eseguire svn cleanup sulla tua directory di lavoro ti aiuterà.

Ho riscontrato lo stesso problema, ho battuto la testa e ho scoperto che avevo cambiato la directory nel rappresentante da " / " a " / trunk " e ho dimenticato di fare il " Switch " comando, in TortoiseSVN!

Wow, questo mi ha richiesto un po 'di tempo per risolverlo, 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 chiuso) rinominare la directory del progetto e ricontrollare il progetto da SVN. Sono contento che funzioni correttamente ora!

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 andando indietro di 1 revisione. Ciò ha mostrato conflitti come questo: & Quot; < < < < < < < nome file mie modifiche

======= codice unito dal repository revisione "

mentre non ho fatto nulla di speciale (solo una volta ho annullato una revisione).

Ho sostituito il contenuto di questo file con il contenuto salvato, salvato e quindi selezionato tramite TortoiseSVN & # 8594; Risolto. Potrei quindi eseguire il commit delle modifiche al repository.

Grazie Jamie Bullock questo lavoro per me

Secondo Jamie Bullock,

Ho appena avuto questo problema e la causa sembra essere che una directory sia stata contrassegnata come in conflitto. Per risolvere:

svn update
svn risolto
svn commit

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow