svn: sostituisce il tronco con il ramo

Qual è il modo migliore per trasformare uno dei rami di un repository di sovversione nel nuovo trunk?

C'è stata un'importante riscrittura per l'intero sistema: le cose sono state spostate, riscritte, sostituite, rimosse, rinominate ecc. Il codice riscritto è stato testato ed è pronto per sostituire il vecchio trunk.

Fondamentalmente, la vecchia linea principale (Trunk 5) è taggata e finirà qui. Il ramo riscritto (Branch 6) sta per diventare la nuova linea principale (Trunk 7):

Trunk (1) -> Trunk (2) -> Trunk (5) -> × + -> new Trunk (7)
  \ \ |
  forcella si fondono ???
    \ \ |
     + -> Branch (3) -> Branch (4) -> Branch (6) - +

Tutte le modifiche in corso dal vecchio "Trunk" sono già incorporate nel "Ramo riscritto"

Come posso fare questo?

Utilizzare svn move per spostare il contenuto del vecchio trunk da qualche altra parte e in seguito rinominare il ramo in trunk.

Nota che copiare e spostare in svn funziona come le operazioni sui file. Puoi usarli per spostare / copiare oggetti nel tuo repository e anche queste modifiche sono sottoposte a versione. Pensa a "sposta" come "copia + cancella".

[EDIT] Nilbus mi ha appena informato che otterrai conflitti di unione quando lo usi svn move.

Penso ancora che questo sia l'approccio corretto. Provocherà conflitti ma se ti unisci attentamente, è probabile che non perderai alcun dato. Se questo ti disturba, usa un VCS migliore come Mercurial o Git .

Sono d'accordo con l'utilizzo del comando mossa svn per raggiungere questo obiettivo.

So che altri qui pensano che sia insolito, ma mi piace farlo in questo modo. Quando ho un ramo di funzionalità e sono pronto a unirlo con un trunk che è stato anche modificato in modo significativo, lo unirò a un nuovo ramo, di solito denominato <FeatureBranchName>-Merged. Quindi risolvo i conflitti e testare il codice unito. Una volta completato, sposto il trunk nella cartella dei tag in modo da non perdere nulla. Infine sposto il mio <FeatureBranchName>-Mergednel bagagliaio.

Inoltre preferisco evitare la copia di lavoro quando si eseguono le mosse, ecco alcuni esempi dei comandi:

svn move https://SVNUrl/svn/Repo/trunk https://SVNUrl/svn/Repo/tags/AnyName

svn move https://SVNUrl/svn/Repo/branches/BranchName-Merged https://SVNUrl/svn/Repo/trunk

Nota: utilizzo 1.5

Recentemente stavo solo esaminando questo problema e la soluzione di cui ero molto contento era la prestazione

svn merge --ignore-ancestry trunk-url branch-url

sulla copia funzionante del mio baule.

Questo non tenta di applicare le modifiche in modo storico (mantenendo le modifiche nel trunk). Semplicemente "applica il diff" tra il tronco e il ramo. Ciò non creerà alcun conflitto per i tuoi utenti nei file che non sono stati modificati. Perderai comunque le tue informazioni storiche dal ramo, ma ciò accade quando esegui comunque un'unione.

Consiglia di apportare queste modifiche tramite lo strumento browser del repository.

Tentare grandi operazioni di eliminazione + spostamento tramite la copia di lavoro è un ottimo modo per uccidere la copia di lavoro. Se si è costretti a utilizzare la copia di lavoro, eseguire i commit incrementali dopo ogni operazione di eliminazione o spostamento e AGGIORNARE la propria copia di lavoro dopo ogni commit.

Se si desidera rendere il ramo il nuovo trunk (ovvero) eliminare tutte le modifiche nel trunk apportate dalla creazione del ramo, è possibile 1. Creare un ramo del trunk (a fini di backup) 2. "Ripristina modifiche "sul trunk (selezionare tutte le revisioni dopo la creazione del ramo 3. Unire nuovamente il ramo al trunk.

La storia dovrebbe rimanere così.

Saluti, Roger

Le soluzioni @Aaron Digulla e @kementeus sono realizzabili. Per i repository Subversion 1.4, le operazioni di copia / spostamento possono rendere difficile la migrazione futura a una diversa struttura di repository o la suddivisione dei repository.

Credo che i miglioramenti di 1.5 includano una migliore risoluzione della cronologia di spostamento / copia, quindi probabilmente non sarebbe un problema per un repository 1.5.

Per un repository 1.4, consiglierei di usare svnadmin dumped svndumpfiltereseguire il movimento del trunk esistente altrove, quindi di spostare il ramo sul trunk con lo stesso meccanismo. Caricare i due file di dump in un repository di prova, verificare, quindi spostarlo in produzione.

Naturalmente, esegui il backup del repository esistente prima di iniziare.

Ciò preserva la cronologia senza registrare esplicitamente lo spostamento / copia e semplifica la riorganizzazione futura, preservando la cronologia.

Modifica: come richiesto, la documentazione del comportamento 1.4, dal libro 1.4 Red-Bean, Filtering Repository History

Inoltre, i percorsi copiati possono causare problemi. Subversion supporta le operazioni di copia nel repository, in cui viene creato un nuovo percorso copiando un percorso già esistente. È possibile che ad un certo punto della durata del repository, sia possibile che sia stato copiato un file o una directory da una posizione chesvndumpfilter esclusa, in una posizione che include. Al fine di rendere i dati di dump autosufficienti,svndumpfilterdeve ancora mostrare l'aggiunta del nuovo percorso, inclusi i contenuti di tutti i file creati dalla copia, e non rappresentare quell'aggiunta come una copia da un'origine che non esisterà nel flusso di dati di dump filtrato. Ma poiché il formato di dump del repository Subversion mostra solo ciò che è stato modificato in ogni revisione, il contenuto dell'origine della copia potrebbe non essere prontamente disponibile. Se sospetti di avere copie di questo tipo nel tuo repository, potresti voler ripensare il tuo set di percorsi inclusi / esclusi, magari includendo anche i percorsi che sono serviti come fonti delle tue fastidiose operazioni di copia.

Questo vale per le migrazioni / riorganizzazioni che utilizzano svndumpfilter. Ci sono momenti in cui un po 'di lavoro extra ora può risparmiare un sacco di lavoro extra in seguito, e mantenendo un facile utilizzo di svndumpfilterdisponibili per future migrazioni / riorganizzazioni mitiga il rischio a un costo relativamente basso.

Mentre le risposte sopra funzioneranno, non sono le migliori pratiche. L'ultima traccia svn server e client si fonde per te. Quindi svn sa quali revisioni hai unito in un ramo e da dove. Questo aiuta molto quando si tiene aggiornato un ramo e poi si fonde di nuovo nel tronco.

Indipendentemente dalla versione di Subversion in uso, tuttavia, esiste un metodo di best practice per riportare le modifiche in un ramo nel trunk. È delineato nel manuale di Subversion: Controllo versione con Subversion, Capitolo 4. Branching and Merging, Keeping a Branch in Sync .

È una configurazione davvero strana / insolita in SVN, anche se penso che sia tutt'altro che una "buona pratica", comunque, suppongo che potresti fare qualcosa del tipo:

• Guarda tutto il sourcetree (svn co therootsourcetree)
• Rimuovere il trunk (trunk svn rm)
• Copia il ramo nel trunk (svn cp branch / thebranch / trunk)
• Rimuovi il ramo (svn rm rami / thebranch)
• Conferma le modifiche

In bocca al lupo