SVN come risolvere i nuovi conflitti albero quando si aggiunge il file su due rami

Question

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

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

Ho bisogno i cambiamenti da entrambi i rami, ma il conflitto albero non mi dà la solita .working, file .merge-destra-sinistra .merge e - il che è comprensibile a causa della natura del conflitto. Ci sono un bel po 'di questi conflitti, e quelli in cui un'operazione di eliminazione dello stesso file si è verificato su ogni ramo, ma sono semplici da risolvere.

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

Answer 1

Come è stato detto in una versione precedente (2009) del "Albero conflitti" disegno documento:

  

XFAIL conflitto dalla fusione di aggiungere oltre file versionato

     

Questo test fa una fusione che porta un file aggiunta senza storia su un   file versionato esistente .
  Questo dovrebbe essere un conflitto albero sul file della varietà 'local obstruction, incoming add upon merge'. aspettative fissi in r35341.

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

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

Se ancora stanno lavorando sul ramo di origine, lo scenario ideale sarebbe quello di eliminare tale file dal B1 ramo fonte, unire ritorno da B2 a B1 al fine di rendere il file visibile su B1 (sarà quindi lavorare sul stesso elemento).
Se una fusione posteriore non è possibile perché si fonde si verifica solo da B1 a B2, poi una fusione manuale sarà necessaria per ogni B1->B2 si fonde.

Answer 2

Ho trovato un messaggio che suggerisce una soluzione per che . Si tratta di eseguire:

svn resolve --accept working <YourPath>

che rivendicare i file versione locale come OK.
È possibile eseguire per singolo file o interi cataloghi di progetti.

Answer 3

  

Che cosa succede se i cambiamenti in arrivo sono quelli che si desidera? Sono in grado di eseguire svn risolvere --accept loro pieno

svn determinazione di base --accept

Answer 4

Ho appena riuscito a cuneo me abbastanza bene cercando di seguire il consiglio di user619330 sopra. La situazione è stata: (1): I aveva aggiunto alcuni file mentre si lavora sul mio ramo iniziale, Branch1; (2) Ho creato un nuovo ramo, Branch2 per un ulteriore sviluppo, ramificazione fuori dal tronco e poi la fusione nei miei cambia da Branch1 (3) Un collega aveva copiato le mie mods da Branch1 al suo ramo, ha aggiunto ulteriori mods, e poi fuse di nuovo al tronco; (4) Ora voluto unire le ultime modifiche dal tronco in mio attuale ramo di lavoro, Branch2. Questo è con svn 1.6.17.

La fusione ha avuto conflitti degli alberi con i nuovi file, e volevo la nuova versione dal tronco in cui differivano, in modo da una copia pulita di Branch2, ho fatto uno svn cancellare i file in conflitto, commesso questi cambiamenti Branch2 (quindi la creazione di una versione temporanea del Branch2 senza i file in questione), e poi ha fatto il mio merge dal tronco. L'ho fatto perché volevo la storia per corrispondere alla versione tronco in modo che non avrei più problemi in seguito quando si cerca di unire di nuovo a tronco. Merge è andato bene, ho ottenuto la versione tronco dei file, svn st mostra tutto ok, e poi mi ha colpito più conflitti albero durante il tentativo di commettere i cambiamenti, tra l'eliminazione che avevo fatto in precedenza e l'add dalla fusione. Ha fatto una determinazione svn dei conflitti a favore della mia copia di lavoro (che ora ha avuto la versione tronco dei file), e ottenuto per commettere. Tutti dovrebbero essere buono, giusto?

Be ', no. Un aggiornamento di un'altra copia del Branch2 ha portato alla vecchia versione dei file (pre-tronco unione). Così ora ho due diverse copie di lavoro dei Branch2, presumibilmente aggiornati alla stessa versione, con due diverse versioni dei file, ed entrambi insistendo sul fatto che essi sono completamente aggiornati! Il check-out di una copia pulita di Branch2 provocato la vecchia versione (pre-tronco) dei file. Aggiorno manualmente questi per la versione tronco e confermare le modifiche, tornare alla mia prima copia di lavoro (da cui ero presentato il tronco cambia in origine), cercare di aggiornarlo, e ora ottenere un errore di checksum sui file in questione. Suonate la directory in questione via, ottenere una nuova versione via l'aggiornamento, e, infine, ho quello che dovrebbe essere una buona versione di Branch2 con le modifiche del tronco. Io spero. sviluppatore Caveat.