SVN come risolvere i nuovi conflitti dell'albero quando il file viene aggiunto su due rami

Quando si uniscono un paio di rami (usando SVN 1.6.1) in cui è stato aggiunto un file su entrambi i rami (e poi lavorato in quei rami separati) ottengo uno dei nuovi conflitti dell'albero:

      C foo.txt
  >   local obstruction, incoming add upon merge

Ho bisogno delle modifiche da entrambi i rami, ma il conflitto dell'albero non mi dà i soliti file .working, .merge-left e .merge-right, il che è comprensibile a causa della natura del conflitto. Ci sono alcuni di questi conflitti e quelli in cui si è verificata l'eliminazione dello stesso file su ogni ramo, ma sono semplici da risolvere.

Come posso risolvere questo problema? Il libro Redbean SVN (per 1.6) non copre questa situazione.

Come menzionato in una versione precedente (2009) del documento di progettazione "Tree Conflict" :

Conflitto XFAIL da unione di file con versione aggiunta su

Questo test esegue un'unione che porta un'aggiunta di file senza cronologia su un file con versione esistente .
Questo dovrebbe essere un conflitto ad albero sul file della local obstruction, incoming add upon mergevarietà " ". Aspettative fisse in r35341.

(Questo è anche chiamato "gemelli cattivi" in ClearCase tra l'altro):
un file viene creato due volte (qui "aggiunto" due volte) in due rami diversi, creando due storie diverse per due elementi diversi, ma con lo stesso nome.

La soluzione teorica è unire manualmente quei file (con uno strumento diff esterno) nel ramo di destinazione ' B2'.

Se stai ancora lavorando sul ramo di origine, lo scenario ideale sarebbe quello di rimuovere quel file dal ramo di origine B1, unire di nuovo da B2a B1per rendere quel file visibile su B1(lavorerai quindi sullo stesso elemento).
Se una fusione a ritroso non è possibile perché le unioni avvengono solo da B1a B2, sarà necessaria un'unione manuale per ciascuna B1->B2unione.

Ho trovato un post che suggerisce una soluzione per questo . Sta per funzionare:

svn resolve --accept working <YourPath>

che rivendicherà i file della versione locale come OK.
Puoi eseguirlo per un singolo file o interi cataloghi di progetto.

E se le modifiche in arrivo fossero quelle che desideri? Non riesco a eseguire svn resolution --accettare il loro pieno

svn risoluzione --accept base

Sono appena riuscito a incunearmi abbastanza a fondo cercando di seguire il consiglio di user619330 sopra. La situazione era: (1): avevo aggiunto alcuni file mentre lavoravo sul mio ramo iniziale, ramo1; (2) Ho creato un nuovo ramo, ramo2 per un ulteriore sviluppo, diramandolo dal tronco e quindi unendo le mie modifiche da ramo1 (3) Un collega aveva copiato le mie mod da ramo1 al suo ramo, ha aggiunto ulteriori mod, e poi si è fusa di nuovo nel tronco; (4) Ora volevo unire le ultime modifiche da trunk al mio ramo di lavoro corrente, branch2. Questo è con svn 1.6.17.

L'unione presentava conflitti di albero con i nuovi file e volevo la nuova versione dal tronco in cui differivano, quindi da una copia pulita di branch2, ho eseguito un'eliminazione svn dei file in conflitto, ho eseguito il commit di queste modifiche di branch2 (creando così un versione di branch2 senza i file in questione), e poi ho fatto la mia fusione dal tronco. L'ho fatto perché volevo che la cronologia corrispondesse alla versione del trunk in modo da non avere più problemi in seguito quando ho provato a unire di nuovo al trunk. L'unione è andata bene, ho ottenuto la versione trunk dei file, svn st mostra tutto ok, e poi ho colpito più conflitti dell'albero mentre cercavo di eseguire il commit delle modifiche, tra l'eliminazione che avevo fatto in precedenza e l'aggiunta dall'unione. Un svn ha risolto i conflitti a favore della mia copia di lavoro (che ora aveva la versione trunk dei file) e l'ha fatto eseguire il commit.

Beh no. Un aggiornamento di un'altra copia di branch2 ha portato alla vecchia versione dei file (unione pre-trunk). Quindi ora ho due diverse copie funzionanti di branch2, presumibilmente aggiornate alla stessa versione, con due diverse versioni dei file, ed entrambe insistono sul fatto che siano completamente aggiornate! Il controllo di una copia pulita di branch2 ha prodotto la vecchia versione (pre-trunk) dei file. Li aggiorno manualmente alla versione trunk e applico le modifiche, torno alla mia prima copia di lavoro (da cui avevo inviato originariamente le modifiche al trunk), provo ad aggiornarlo e ora ottengo un errore di checksum sui file in questione. Spazza via la directory in questione, ottieni una nuova versione tramite aggiornamento e finalmente ho quella che dovrebbe essere una buona versione di branch2 con le modifiche al trunk. Io spero. Sviluppatore avvertimento.