Perché riscontro conflitti di alberi in Subversion?

Avevo un ramo caratteristica del mio baule e fondevo periodicamente le modifiche dal mio baule al mio ramo e tutto funzionava bene. Oggi sono andato a fondere nuovamente il ramo nel tronco e tutti i file che sono stati aggiunti al mio tronco dopo la creazione del mio ramo sono stati contrassegnati come "conflitto dell'albero". C'è un modo per evitarlo in futuro?

Non penso che questi siano correttamente segnalati.

Ho trovato la soluzione leggendo il link fornito da Gary (e suggerisco di seguire in questo modo).

Riassumendo per risolvere il conflitto dell'albero commettendo la tua directory di lavoro con il client SVN 1.6.x puoi usare:

svn resolve --accept working -R .

dove si .trova la directory in conflitto.

ATTENZIONE : "Commettere la tua directory di lavoro" significa che la struttura della tua sandbox sarà quella che stai eseguendo, quindi se, per esempio, hai eliminato alcuni file dalla tua sandbox, questi verranno eliminati anche dal repository. Questo vale solo per la directory in conflitto.

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

In TortoiseSVN, selezionando "Risolto" con il tasto destro, si risolve effettivamente questo problema.

Subversion 1.6 ha aggiunto Conflitti ad albero per coprire i conflitti a livello di directory. Un buon esempio potrebbe essere quando si elimina localmente un file, quindi un aggiornamento tenta di ridurre una modifica del testo su quel file. Un altro è quando hai una sovversione Rinomina di un file che stai modificando poiché si tratta di un'azione Aggiungi / Elimina.

Il blog Subversion di CollabNet contiene un ottimo articolo sui conflitti degli alberi .

Nella mia esperienza, SVN crea un conflitto tra alberi TUTTAVIA che elimino una cartella. Sembra non esserci motivo.

Sono l'unico che lavora sul mio codice -> elimina una directory -> commit -> conflitto!

Non vedo l'ora di passare a Git .

Dovrei chiarire: uso Subclipse . Questo è probabilmente il problema! Ancora una volta, non vedo l'ora di passare ...

Non so se questo ti sta succedendo, ma a volte scelgo la directory sbagliata da unire e ottengo questo errore anche se tutti i file sembrano completamente a posto.

Esempio:

Unisci / svn / Progetto / rami / qualche ramo / Fonti in / svn / Progetto / tronco ---> Conflitto dell'albero

Unisci / svn / Progetto / rami / qualche ramo in / svn / Progetto / tronco ---> OK

Questo potrebbe essere un errore stupido, ma non è sempre ovvio perché pensi che sia qualcosa di più complicato.

Quello che sta succedendo qui è il seguente: crei un nuovo file sul tuo trunk, quindi lo unisci nel tuo ramo. Nel commit di unione questo file verrà creato anche nel tuo ramo.

Quando unisci nuovamente il tuo ramo nel trunk, SVN tenta di fare di nuovo lo stesso: vede che un file è stato creato nel tuo ramo e tenta di crearlo nel tuo trunk nel commit di unione, ma esiste già! Questo crea un conflitto tra alberi.

Il modo per evitarlo è fare una fusione speciale, una reintegrazione . Puoi farlo con l' --reintegrateinterruttore.

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

Quando unisci il tuo ramo al tronco, tuttavia, la matematica sottostante è abbastanza diversa. Il ramo delle funzionalità ora è un miscuglio di modifiche al trunk duplicate e modifiche al ramo privato, quindi non esiste un semplice intervallo contiguo di revisioni da copiare. Specificando l'opzione --reintegrate, stai chiedendo a Subversion di replicare attentamente solo le modifiche univoche per il tuo ramo. (E in effetti, lo fa confrontando l'ultimo albero del tronco con l'ultimo albero del ramo: la differenza risultante è esattamente il tuo ramo cambia!)

Dopo aver reintegrato un ramo, è consigliabile rimuoverlo, altrimenti continuerai a ricevere conflitti di alberi ogni volta che ti unisci nella direzione opposta: dal tronco al ramo. (Per lo stesso motivo descritto in precedenza.)

C'è anche un modo per aggirare questo, ma non l'ho mai provato. Puoi leggerlo in questo post: Reintegrazione del ramo di Subversion in v1.6

Ciò può essere causato dal mancato utilizzo della stessa versione client dappertutto.

L'uso di un client versione 1.5 e un client versione 1.6 verso lo stesso repository può creare questo tipo di problema. (Mi sono appena morso.)

Se si incontrano conflitti tra alberi che non hanno senso perché non si è modificato / eliminato / avvicinato al file, è possibile che si sia verificato un errore nel comando di unione.

Ciò che può accadere è che in precedenza hai già unito un sacco di modifiche che stai includendo nella tua fusione attuale. Ad esempio, nel trunk qualcuno ha modificato un file e successivamente lo rinomina. Se nella prima unione includi la modifica, quindi in una seconda unione includi sia la modifica che la ridenominazione (essenzialmente una rimozione), ti darà anche un conflitto ad albero. La ragione di ciò è che la modifica precedentemente unita appare come la tua e quindi la rimozione non verrà eseguita automaticamente.

Questo può avvenire almeno sui repository 1.4, non sono sicuro che il raggruppamento introdotto in 1.5 sia di aiuto.

Fino ad oggi, per almeno 3 mesi fa, ho incontrato regolarmente centinaia di conflitti tra alberi nel tentativo di fondere un ramo nel tronco (usando TortoiseSVN 1.11 ). Rinnovato o no, BTW. Uso TortoiseSVN dalla sua v1, nel 2004, e reintegravo continuamente i rami. Qualcosa deve essere successo di recente, suppongo?

Quindi oggi ho eseguito questo semplice esperimento e ho scoperto cosa stava creando questi pazzi conflitti:

1. Ho biforcato dal bagagliaio @ 393;
2. Ho modificato decine di file in modo casuale, oltre a crearne di nuovi;
3. Mi sono impegnato. Ora @ 395 (un collega ha rinunciato a 394 per eseguire le proprie cose).
4. Quindi ho provato a reintegrare il ramo nel tronco, solo test; seguendo la raccomandazione di TortoiseSVN nella procedura guidata: "per unire tutte le revisioni (reintegrare), lasciare quella casella vuota". Per raggiungere questo obiettivo, ho fatto clic con il tasto destro sulla cartella trunk e ho scelto "TortoiseSVN> Unisci, da / percorso / a / ramo", e ho lasciato vuoto l'intervallo di giri , come consigliato nella finestra di dialogo.

Discussione: (vedi allegato)

tutte le revisioni ... di cosa? Non sapevo che il cliente si sarebbe dovuto riferire a " tutte le revisioni del target! (Trunk)", poiché, nel processo di reintegrazione di quel ramo, ho visto la menzione "Unire le revisioni 1-HEAD"! OH MIO DIO. Povero diavolo, stai cadendo qui per morire. Quel ramo è nato al 393, non riesci a leggere il suo certificato di nascita, per l'amor di Dio?

Risoluzione:

1. Contrariamente a quanto consigliato dal mago, specifica un intervallo che copra TUTTE le revisioni della ... vita del ramo! pertanto, 394-HEAD ;
2. ora esegui di nuovo quel test di fusione e prendi un sigaro. ( ).

Morale: Non riesco a capire perché non hanno ancora risolto quel bug, perché è uno, mi dispiace. Dovrei dedicare del tempo a segnalarlo con loro.

Oggi ho riscontrato questo problema, anche se il mio problema particolare probabilmente non è correlato al tuo. Dopo aver ispezionato l'elenco dei file, mi sono reso conto di ciò che avevo fatto: avevo temporaneamente utilizzato un file in un assembly da un altro assembly. Ho apportato molte modifiche e non volevo rendere orfana la cronologia SVN, quindi nel mio ramo avevo spostato il file dalla cartella dell'altro assembly. Questo non viene monitorato da SVN, quindi sembra solo che il file venga eliminato e quindi aggiunto di nuovo. Questo finisce per causare un conflitto tra alberi.

Ho risolto il problema spostando indietro il file, eseguendo il commit e quindi unendo il mio ramo. Quindi ho spostato il file in seguito. :) Sembrava fare il trucco.

Ho avuto un problema simile. L'unica cosa che effettivamente ha funzionato per me è stata eliminare le sottodirectory in conflitto con:

svn delete --force ./SUB_DIR_NAME

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

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

Quindi fa

svn cleanup

e

svn add *

Potresti ricevere avvisi con l'ultimo, ma ignorali e infine

svn ci .

Ho avuto lo stesso problema e l'ho risolto ripetendo l'unione usando queste istruzioni . Fondamentalmente, utilizza "2-URL merge" di SVN per aggiornare trunkallo stato attuale del tuo ramo, senza preoccuparti così tanto della storia e dei conflitti dell'albero. Mi ha salvato dalla risoluzione manuale di 114 conflitti tra alberi.

Non sono sicuro che conservi la storia come vorrebbe, ma ne è valsa la pena nel mio caso.

Uno scenario in cui mi imbatto a volte:

Supponiamo di avere un trunk, da cui è stato creato un ramo di rilascio. Dopo alcune modifiche al trunk (in particolare creando la directory "some-dir"), si crea un ramo feature / fix che si desidera successivamente unire anche nel ramo release (poiché le modifiche erano abbastanza piccole e la funzione / fix è importante per il rilascio) .

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

Se poi provi a unire il ramo feature / fix direttamente nel ramo di rilascio, otterrai un conflitto ad albero (anche se la directory non esisteva nemmeno nel ramo feature / fix):

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 eseguiti sul trunk prima di creare il ramo feature / fix che ha creato la directory "some-dir" prima di unire il ramo feature / fix.

Lo dimentico spesso perché non è necessario in Git.