svn merge reintegrare gamme mancanti ma niente di fondere

Question

Ecco l'enigma:

C:\code\trunk> svn merge --reintegrate http://svn.e.com/repos/branches/lih --accept postpone --dry-run 
svn: E195016: Reintegrate can only be used if revisions 11430 through 12384 were previously merged from http://svn.e.com/repos/trunk to the reintegrate source, but this is not the case: 
    branches/lih 
    Missing ranges: /trunk:11902 

Ma poi se vado nella directory del ramo e tenta di unire tale intervallo, non c'è niente di unire!

C:\code\branches\branch> svn merge -r 11901:11902 http://svn.e.com/repos/trunk --accept postpone --dry-run 
C:\code\branches\branch> 

Anche svn merge -r 11898:11903 non mostra nulla da unire.

Ora non riesco a reintegrare il mio ramo nel bagagliaio! Per favore aiuto!

P.S. Il ramo lih non è stato creato fino al 11906. Era ramificato dal ramo hd, che era ramificato dal trunk (e l'hd è già stato riunito nel trunk).

Answer 1

Questo sembrava funzionare per me, ma non posso pretendere di capirlo o garantire che è il modo migliore per risolvere il mio problema.

In primo luogo, è importante che il ramo contenga tutti gli ultimi commit sul trunk. Quindi sincronizzalo (fai unire da un tronco all'altro).

Quindi è possibile forzare un reintegro essenzialmente nella directory di linea: svn merge http://svn.e.com/repos/trunk/@REV http://svn.e.com/repos/branches/lih/ . --dry-run (ma sostituire REV con l'ultimo numero di revisione).

Answer 2

Mi sono imbattuto in qualcosa di simile, in cui il problema era che il tronco aveva avuto due revisioni di annullamento (ad es., Rev 20865 su tronco undid rev 20857). Quindi, quando mi sono unito per la prima volta da un tronco all'altro, non aveva nulla da unire per questa coppia di revisioni, ma non li includeva in mergeinfo per i file in questione. Poi, quando ho provato a unirmi di nuovo da un ramo all'altro, ha obiettato che mancavano queste due revisioni.

La mia soluzione (dopo aver verificato manualmente che le revisioni annullate per i file in questione) consisteva nel fondere ciascuna delle due revisioni in diramazione esplicita (tramite svn unione +/trunk -c 20857 e svn unione ^/trunk -c 20865), eseguire il commit e quindi unire nuovamente il ramo al trunk. La seconda volta, è andato liscio. Questo era con Subversion 1.8.0 (r1490375).

Sono stato in grado di aggirare un problema simile in precedenza utilizzando l'unione con --record-only per contrassegnare le modifiche come correttamente unite sul ramo, ma è probabilmente più sicuro unire i file effettivi (nel caso ci sia una modifica che non cancella completamente).

Sembra un bug nel modo in cui Subversion 1.8 gestisce mergeinfo per l'annullamento delle modifiche.