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


Answers

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

svn resolve --accept working <YourPath>

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

Question

Quando uniamo un paio di rami (usando SVN 1.6.1) dove un file è stato aggiunto su entrambi i rami (e poi lavorato in quei rami separati) sto ottenendo uno dei nuovi conflitti tra gli alberi:

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

Ho bisogno dei cambiamenti 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 un'eliminazione dello stesso file su ciascun ramo, ma sono semplici da risolvere.

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




Sono semplicemente riuscito a incunearmi abbastanza accuratamente cercando di seguire i consigli di user619330 qui sopra. La situazione era: (1): avevo aggiunto alcuni file mentre lavoravo al mio ramo iniziale, branch1; (2) Ho creato un nuovo ramo, branch2 per ulteriori sviluppi, ramificandolo dal trunk e quindi unendomi alle mie modifiche da branch1 (3) Un collaboratore aveva copiato i miei mod da branch1 al proprio branch, aggiungendo ulteriori mods, e poi si unì di nuovo al tronco; (4) Ora volevo unire le ultime modifiche da trunk al mio attuale ramo di lavoro, branch2. Questo è con svn 1.6.17.

L'unione ha avuto conflitti di albero con i nuovi file, e volevo la nuova versione dal trunk in cui erano differenti, quindi da una copia pulita di branch2, ho fatto una cancellazione svn dei file in conflitto, ho commesso queste modifiche branch2 (creando così un temporaneo versione di branch2 senza i file in questione), quindi ha eseguito l'unione dal trunk. L'ho fatto perché volevo che la cronologia corrispondesse alla versione del trunk in modo da non avere più problemi in seguito quando tentavo di unirmi nuovamente al trunk. Unisci è andato bene, ho ottenuto la versione trunk dei file, svn st mostra tutto ok, e poi ho riscontrato più conflitti tra gli alberi mentre provavo a commettere le modifiche, tra l'eliminazione che avevo fatto in precedenza e l'aggiunta dall'unione. Ha risolto i conflitti in svn in favore della mia copia di lavoro (che ora aveva la versione trunk dei file) e l'ho fatta per commettere. Tutto dovrebbe essere buono, giusto?

Beh no. Un aggiornamento di un'altra copia di branch2 portava alla vecchia versione dei file (pre-trunk merge). Così ora ho due diverse copie di lavoro di branch2, che si suppone siano aggiornate alla stessa versione, con due diverse versioni dei file, ed entrambe insistono sul fatto che sono completamente aggiornate! Il controllo di una copia pulita di branch2 ha portato alla versione precedente (pre-trunk) dei file. Li aggiorno manualmente alla versione trunk e commetto le modifiche, ritorna alla mia prima copia di lavoro (da cui avevo originariamente inviato le modifiche al trunk), provo ad aggiornarlo e ora ottengo un errore di checksum sui file in questione. Soffiare via la directory in questione, ottenere una nuova versione tramite aggiornamento, e finalmente ho quella che dovrebbe essere una buona versione di branch2 con le modifiche del trunk. Io spero. Sviluppatore di caveat.