L'unione tra i rami in Subversion non aggiunge tutti i nuovi file. Perchè no?

Question

Ho un albero del codice sorgente in sovversione con diversi rami. Ho appena terminato una sessione di debug abbastanza intensa in un ramo altrimenti attivo e ora devo unire le modifiche al nuovo ramo. Il nuovo ramo è stato rimosso dal trunk (che rappresenta il codice rilasciato) di recente, dopo tutto lo sviluppo nel vecchio ramo (ovviamente), ma prima ho commesso tutto il mio debug. Tentativo di svn merge, tuttavia, non è unione tra tutti i file che sono stati aggiunti. Aggiunge alcuni, ma non tutti.

Ecco la linea di tempo:

• Branch off tronco per creare ramo dev1.
• Codice in dev1, modifica di file e aggiunta di file.
• Separare il trunk per creare il ramo dev2.
• Correzione di bug in dev1, modifica dei file ma non aggiunta di file.
• Unisci tutte le modifiche in dev1 a dev2.

Come previsto, ci sono molti cambiamenti, inclusi i nuovi file, ma non tutti. È perché la gamma di versioni che sto unendo include la versione che ha reso il ramo dev2? O dovrei fondermi con trunk e poi down in dev2?

Modifica: Tutto il codice è completamente impegnato in Subversion. Ma penso che ciò che potrebbe accadere è che le aggiunte di file non si propagano attraverso le unioni. Cioè, una unione precedente a dev1 ha aggiunto alcuni file, ma un'unione da dev1 che comprende il commit dall'unione precedente non include include i file aggiunti.

Ma sto ancora controllando.

Answer 1

La seguente affermazione non è vera:

I file che sono stati aggiunti a un ramo e poi cambiato sul ramo non si aggiunge quando si effettua un'unione attraverso il numero di revisioni

Ciò implicherebbe la fusione completamente interrotta.

Quando si esegue l'unione, è necessario assicurarsi di unire la revisione che ha creato il file, altrimenti si otterranno tali avvisi su nessun obiettivo.

L'altra cosa a cui prestare attenzione è se si fonde in una copia funzionante, quindi si decide che non si è soddisfatti e si ripristina tutto, i file appena aggiunti saranno ancora nella copia di lavoro, quindi se si Unisci di nuovo, i file non verificati impediranno l'unione di nuovi file lì, quindi ti mancheranno. Quindi eseguire "svn status" e rimuovere file non verificati assicurerà che l'unione funzioni correttamente.

Il commento sull'aggiunta di un file vuoto non deve essere eseguito, in quanto il nuovo file non ha una cronologia di provenienza. In altre parole, non è una copia, quindi "svn log" non mostrerà la sua cronologia. E infine, se il file fosse una foto gigabyte, non si vorrebbe fondere in un nuovo file, perché quindi il repository avrebbe due copie dello stesso identico contesto. L'unione e la copia con la cronologia salvano l'archiviazione del repository (almeno fino a quando non viene inserita la ripubblicazione).

Answer 2

I file che sono stati aggiunti a un ramo e quindi modificati sul ramo non vengono aggiunti quando si esegue un'unione attraverso un numero di revisioni poiché subversion sta tentando di applicare un diff di contesto a un file che non esiste nel directory di lavoro (il nuovo file). Verrà visualizzato un avviso da svn affermando qualcosa come "Salta file mancante blah.c ..."

Ci sono due modi di base per affrontare questo. Configura il tuo ramo (questa è sempre una buona idea dato che l'unione può rovinare le cose a volte ed è molto più semplice essere semplicemente in grado di ripristinare), quindi unire ogni revisione specifica che aggiunge file (uno alla volta) per assicurare che i file effettivamente aggiunto alla tua directory di lavoro.

L'altra opzione è creare file vuoti (ad esempio, utilizzando il comando unix touch) per tutti i file che sono stati aggiunti alle revisioni (è possibile ottenere un elenco di questi file semplicemente facendo l'unione con il - -disattore run-run e prendendo nota di tutti gli avvertimenti "Saltare i file mancanti"), quindi eseguire l'unione con l'intero elenco di revisioni (come -r 1023: 1040).Che unire le modifiche nei nuovi file vuoti e tutto dovrebbe essere peachy :)

Answer 3

Ho sempre saputo che gli avvertimenti svn sono l'indicazione di sovversione che hai rovinato in qualche modo. Poi mi sono imbattuto nel caso precedente, dove stavo ottenendo un sacco di file saltati in una fusione da un ramo, ma sapevo di avere i percorsi corretti per l'unione. I file saltati erano tutti i file che sono stati aggiunti e le modifiche sul ramo ma non ancora presenti sul trunk.

Poi ho realizzato che tutti questi file esistevano già, anche se non controllati, sulla mia copia di lavoro del bagagliaio - Avevo eseguito un test di fusione (non a secco) una settimana prima e ripristinato, ma i file non erano mai fisicamente rimosso dal mio client SVN. Non appena li ho cancellati fisicamente dalla mia copia funzionante del bagagliaio il problema è andato via!

Answer 4

(Poiché questo sembra essere il primo post durante la ricerca di questo problema, commenterò un'altra possibile causa dello stesso comportamento).

Nel mio caso, alcuni dei cambiamenti nella revisione che stavo cercando di fondere erano già fusa manualmente da un altro sviluppatore e impegnata in una precedente revisione. SVN notava che le modifiche erano già unite e non elencava i file nell'unione.

In questo caso, è sufficiente verificare che i file siano effettivamente uniti correttamente e continuino normalmente.