Perché ricevo conflitti albero in Subversion?

Question

Ho avuto un ramo di caratteristica del mio tronco e si fondevano cambiamenti dal mio baule nel mio ramo periodicamente e tutto funzionava bene. Oggi sono andato a fondere ramo dentro giù nel tronco e uno dei file che sono stati aggiunti al mio tronco dopo la creazione del mio ramo sono stati contrassegnati come "albero di conflitto". C'è un modo per evitare questo in futuro?

Non credo che questi siano adeguatamente contrassegnati.

Answer 1

Ho trovato la soluzione a leggere il link che Gary ha dato (e suggerisco di seguire in questo modo).

Riassumendo per risolvere il conflitto albero commettere directory di lavoro con SVN cliente 1.6.x è possibile utilizzare:

svn resolve --accept working -R .

dove . è la directory in conflitto.

ATTENZIONE : "Commettere directory di lavoro" significa che la struttura sandbox sarà quello che si sta commettendo, quindi, se, per esempio, si è eliminato alcuni file dal sandbox che sarà cancellato dal repository troppo. Questo vale solo per la directory in conflitto.

In questo modo, stiamo suggerendo SVN per risolvere il conflitto (--resolve), accettando la copia di lavoro all'interno della vostra sandbox (--accept working), in modo ricorsivo (-R), a partire dalla directory corrente (.).

In TortoiseSVN, selezionando "risolto" il tasto destro del mouse, in realtà risolve questo problema.

Answer 2

Subversion 1.6 aggiunto Albero conflitti in materia di conflitti a livello di directory. Un buon esempio potrebbe essere quando si elimina un file in locale quindi un aggiornamento cerca di portare un testo cambia giù su quel file. Un altro è quando si si ha un Rinomina sovvertimento di un file che si sta modificando in quanto tale è un Add / Cancella azione.

di CollabNet Subversion blog ha un grande articolo su Albero I conflitti .

Answer 3

Nella mia esperienza, SVN crea un conflitto albero ogni volta che elimina una cartella. Sembra che ci sia alcun motivo.

Sono l'unico a lavorare sul mio codice -> cancellare una directory -> commettere -!> Conflitto

Non vedo l'ora di passare a Git .

Vorrei chiarire - io uso Subclipse . Questo è probabilmente il problema! Anche in questo caso, non vedo l'ora di cambiare ...

Answer 4

Non so se questo sta accadendo a voi, ma a volte scelgo la directory sbagliata di fondere e ottengo questo errore anche se appaiono tutti i file completamente bene.

Esempio:

Unisci / svn / progetto / rami / qualche ramo / Fonti a / svn / progetto / trunk ---> conflitto Albero

Unisci / svn / progetto / rami / some-branch a / svn / progetto / trunk ---> OK

Questo potrebbe essere un errore stupido, ma non è sempre evidente, perché si pensa che è qualcosa di più complicato.

Answer 5

Quello che sta succedendo qui è la seguente: Si crea un nuovo file sul tronco, poi si uniscono nella tua filiale. Nella fusione commettere questo file verrà creato nella vostra filiale anche.

Quando si uniscono il vostro ramo di nuovo nel tronco, SVN cerca di fare di nuovo la stessa: Si vede che un file è stato creato nel ramo, e cerca di crearla nel bagagliaio nell'unione commesso, ma esiste già! Questo crea un conflitto albero.

Il modo per evitare questo, è quello di fare una fusione speciale, un reintegrazione . È possibile raggiungere questo obiettivo con l'interruttore --reintegrate.

Si può leggere su questo nella documentazione: http://svnbook.red -bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

  

Quando si uniscono il vostro ramo di nuovo al tronco, tuttavia, il sottostante   matematica sono molto diverse. Il vostro ramo di caratteristica è ora un miscuglio   di entrambe le modifiche del tronco duplicati e modifiche del ramo privato, quindi   non c'è semplice intervallo contiguo di revisioni a copiare. Di   specificando l'opzione --reintegrate, si sta chiedendo a Subversion   replicare accuratamente solo le modifiche uniche per il vostro ramo. (E in   Infatti, lo fa mettendo a confronto l'ultimo tronco d'albero con le ultime   ramo di albero: la differenza risultante è esattamente le vostre modifiche del ramo)

Dopo reintegrare un ramo è altamente consigliabile rimuoverlo, altrimenti si può mantenere sempre treeconflicts ogni volta che si uniscono nella direzione opposta: dal tronco al ramo. (Per esattamente la stessa ragione come descritto prima.)

C'è un modo per aggirare anche questo, ma non ho mai provato. Lo si può leggere in questo post: ramo Subversion reinserimento nel v1.6

Answer 6

Questo può essere causato da non utilizzando gli stessi clienti di versione in tutto.

Utilizzando un client versione 1.5 e un client versione 1.6 verso lo stesso repository in grado di creare questo tipo di problema. (Mi è stato solo me stesso morso.)

Answer 7

Se si verificano conflitti di alberi che non hanno senso perché non hai modificare / cancellare / arriva da nessuna parte vicino il file, c'è anche una buona probabilità che c'è stato un errore nel comando di unione.

Che cosa può accadere è che in precedenza già incorporato le un po 'di cambiamenti si sono compresi nella stampa corrente. Per esempio, nel tronco qualcuno modificato un file, e poi lo rinomina. Se nel tuo primo merge si include la modifica, e poi in un secondo merge includere sia la modifica e la rinomina (essenzialmente una rimozione), ma vi darà anche un conflitto albero. La ragione di questo è che la modifica in precedenza fusa appare allora come il proprio, e quindi la rimozione non verrà eseguita automaticamente.

Questa situazione può verificarsi su 1,4 repository, almeno, io non sono sicuro se il mergetracking introdotto in 1.5 aiuta qui.

Answer 8

Mi sono imbattuto in questo problema anche oggi, anche se il mio problema particolare, probabilmente non è correlato alla tua. Dopo aver ispezionato l'elenco dei file, ho capito quello che avevo fatto - mi era stato temporaneamente utilizzando un file in un unico assembly da un altro assieme. Ho fatto un sacco di modifiche ad esso e non volevo orfani storia SVN, così nel mio ramo avevo spostato il file dalla cartella sopra di l'altro gruppo. Questo non è monitorato da SVN, quindi sembra proprio come il file viene eliminato e poi ri-aggiunto. Questo finisce per provocare un conflitto albero.

Ho risolto il problema spostando il file indietro, commettendo, e poi la fusione mio ramo. Poi ho spostato il file indietro dopo. :) Che sembrava fare il trucco.

Answer 9

Ho avuto un problema simile. L'unica cosa che in realtà ha funzionato per me è stato quello di eliminare le sottodirectory in conflitto con:

svn delete --force ./SUB_DIR_NAME

Poi copiarli di nuovo da un'altra directory principale nella copia di lavoro che li ha con:

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

Quindi fare

svn cleanup

e

svn add *

Si potrebbe ottenere avvisi con l'ultimo, ma semplicemente li ignorano e infine

svn ci .

Answer 10

Ho avuto questo stesso problema e risolto è da ri-fare l'unione utilizzando queste istruzioni . In sostanza, si usa "merge 2-URL" di SVN per aggiornare trunk allo stato attuale del ramo, senza preoccuparsi tanto di storia e di alberi conflitti. mi ha salvato da fissare manualmente 114 conflitti d'albero.

Non sono sicuro se si conserva la storia così come si vorrebbe, ma ne valeva la pena nel mio caso.

Answer 11

Uno scenario che a volte mi imbatto in:

Si supponga di avere un tronco, da cui è stato creato un ramo di release. Dopo alcune modifiche sul tronco (in particolare la creazione di "un po-dir" directory), si crea una funzione / fix ramo il quale si desidera successivamente unire in ramo di release e (perché i cambiamenti sono stati abbastanza piccola e la funzione / fix è importante per il rilascio) .

trunk -- ... -- create "some-dir" -- ...
     \                                  \-feature/fix branch
      \- release branch

Se quindi si tenta di unire la funzione / fix ramo direttamente nel ramo di release si otterrà un conflitto albero (anche se la directory non esistesse anche in funzione / fix ramo):

svn status
!     C some-dir
      >   local missing or deleted or moved away, incoming file edit upon merge

Quindi, è necessario unire in modo esplicito i commit che sono stati fatti sul tronco prima di creare funzione / fix ramo che ha creato il "alcuni-dir" directory prima di fondersi al ramo della funzione / fix.

Spesso mi dimentico che, come che non è necessario in git.

Answer 12

Fino ad oggi, per almeno dal 3 mesi fa, ho incontrato regolarmente centinaia di conflitti d'albero quando si tenta di unire un ramo di nuovo nel tronco (con TortoiseSVN 1.11 ). Sia ricalcolato o no, BTW. Sto usando TortoiseSVN fin dalla sua v1, nel 2004, e ho usato per reintegrare i rami per tutto il tempo. Dev'essere successo qualcosa di recente suppongo?

Così oggi ho eseguito questo semplice esperimento, e ho trovato ciò che è stato la creazione di questi conflitti folli:

1. I apriva a ventaglio il tronco @ 393;
2. ho modificato decine di file in maniera casuale, così come la creazione di nuovi;
3. ho commesso. Ora @ 395 (un collega biforcuta scendere a 394 per eseguire la propria roba).
4. Poi ho cercato di reintegrare il ramo di nuovo nel tronco, prova unica; seguente raccomandazione di TortoiseSVN nella procedura guidata: "per unire tutte le revisioni (reintegrazione), lasciare quella scatola vuota". Per raggiungere questo obiettivo, mi fa click destro sulla cartella tronco, e ha scelto "TortoiseSVN> Merge, da / path / to / ramo", e I lasciato la serie di giro vuoto , come consigliato nella finestra di dialogo.

Discussione: (vedi allegato)

tutte le revisioni ... di che cosa? Non sapevo che il cliente deve essere stato riferiva al " tutte le revisioni di bersaglio! (tronco)", come, nel processo di reintegrazione quel ramo, ho visto la dicitura "Unione di revisioni 1-TESTA"! OH MIO DIO. Povero Diavolo, stai cadendo per la tua morte qui. Quel ramo è nato @ 393, non si può leggere il suo certificato di nascita, per l'amor di Dio?

Risoluzione:

1. Contrariamente a quanto è consigliato dal mago, non specificare un intervallo, che copre tutte le revisioni di ... vita del ramo! pertanto, 394-HEAD ;
2. ora eseguire questo test si fondono ancora una volta, e ottenere un sigaro. ( ).

Morale: Non riesco a comprendere il motivo per cui ancora non hanno fissato il bug, perché è uno, mi dispiace. Dovrei prendere il tempo per segnalare questa con loro.