Sequenza corretta di azioni per l'unione mediante SVN?

0

Sono totalmente nuovo a CVCS (SVN in particolare). Trovo che la maggior parte delle risorse si concentri molto sui comandi della riga di comando (irrilevante, utilizziamo Windows Explorer + TortoiseSVN) e sulla struttura (ad esempio, progetti all'interno del nostro TTB esterno, ecc.). Ecco una cosa sulla fusione di cui non sono sicuro:

In base al mio test sandbox, ho capito che l'unione dovrebbe essere fatta in ordine alfabetico? Ho pensato inizialmente che l'unione significasse passare dal ramo al tronco, ma ora mi sembra che dovrei effettivamente unire il tronco al mio ramo, risolvere i conflitti lì, e solo quindi commettere il mio ramo nel tronco?

Diciamo che sono responsabile della fusione di un ramo nella linea principale, e tutti hanno commesso le loro modifiche locali in quel ramo. Ora cambio la mia copia di lavoro nel ramo e unisco il bagagliaio nella mia copia di lavoro per risolvere eventuali conflitti localmente e sistemare le cose. Una volta completato, inserisco la mia copia di lavoro nel bagagliaio (non ci dovrebbero essere ne o quasi nessun conflitto in questo passaggio).
Questo è fondamentalmente anche ciò che si deve fare quando si commettono cambiamenti dalla propria copia di lavoro alla filiale.

A destra? Sbagliato? Mi mancano alcuni passaggi? Sembra complicato ma ha un senso.

Non discutiamo di come la fusione in SVN sia più difficile di quella in DVCS perché non è qualcosa che posso cambiare.
Inoltre, non sto chiedendo informazioni sulle azioni della riga di comando specifiche perché stiamo usando TortoiseSVN.

    
posta Torben Gundtofte-Bruun 08.08.2014 - 14:36
fonte

4 risposte

2

Sì, è una best practice per come SVN è progettato. Hai il tuo ramo, unisci il tronco al tuo ramo, perché ci sono sempre problemi da affrontare (è più facile se lo fai periodicamente mentre lavori sul ramo), e quando è buono lo rimetti nel tronco. A questo punto non ci dovrebbero essere conflitti a meno che qualcun altro non sia venuto e abbiate controllato gli aggiornamenti tra.

Sembra complicato ma dopo averlo fatto alcune volte diventa più facile.

    
risposta data 08.08.2014 - 15:12
fonte
1

Prima di chiedere informazioni sull'unione, dovresti chiedere se hai bisogno di uno sviluppo basato sulle filiali.

La risposta dipende esclusivamente dal tuo progetto e dalla tua squadra. Personalmente credo nelle filiali per lo sviluppo di "funzionalità" a livello di applicazione, ma mi sento a mio agio nel cambiare il tronco / master per i progetti di utilità e il nuovo sviluppo (le correzioni ai progetti rilasciati richiedono i rami, ma questo è un argomento separato, e è motivato da preoccupazioni diverse).

Se stai andando con uno stile di sviluppo basato su branch, diventa imperativo che i rami non divergano troppo dal tronco. Ciò porta a unire dolore ( anche con un DVCS ), ma più importante, significa che la tua funzione è sviluppata senza considerare ciò che sta accadendo altrove.

La soluzione è semplice: unione regolare del tronco in tutti i rami in sospeso. Mentre lo descrivo, "i cambiamenti vengono spinti a monte (dal ramo al tronco) ma tornano a valle (dal tronco ai rami)". Se nel team ci sono più persone che lavorano su caratteristiche diverse, credo che ogni sviluppatore dovrebbe unire il tronco nel suo ramo di funzionalità ogni volta che il trunk viene aggiornato (cioè, ogni volta che un'altra funzionalità è completa).

    
risposta data 08.08.2014 - 15:14
fonte
0

Quello che stai cercando è probabilmente un ramo di accumulazione.

Se hai solo due rami - il ramo di sviluppo e la linea principale, e la linea principale è cambiata da quando è stato creato il ramo di sviluppo e non è stata fatta la fusione dalla linea principale al ramo di sviluppo durante il processo:

+------.----.------dev-------------------------...
   /     /     /                                 
  /     /     /                                  
+------------------mainline--------------------+

Quindi è solo una questione 'semplice' di fare un'altra unione dalla linea principale a dev, risolvendo l'unione in dev, e quindi unendola alla mainline (che dovrebbe avere avuto cambiamenti minimi tra due si fondono) e chiudono il ramo.

+------.-----.-----dev---.-----.+
   /     /     /             /   \               
  /     /     /             /     \              
+------------------mainline--------------------+

La chiave qui è che dovresti davvero evitare di avere una build rotta da mainline. La linea principale è nella maggior parte dei luoghi un "questo è buono" e da ciò che la gente si dirige. Se invece hai fatto solo un 'unione con la linea principale e la correzione':

+-----.-----.------dev----+
   /     /     /           \         finally fixed            
  /     /     /             \        v            
+------------------mainline--.---.---.---------+

È possibile che qualcuno abbia potuto diramarsi dallo stato rotto in mainline prima di quelli pronti e stabili. Questo è spesso visto come una cosa negativa.

Uno dei bit con questo che può causare qualche problema è che dopo lo sviluppo viene fatto sul ramo dev, il suo ruolo / politica cambia. Lo sviluppo avviene in un ramo dev ... ma dopo lo sviluppo, stai facendo qualcos'altro nel ramo dev. Questo va contro alcuni schemi di ramificazione . Non puoi usare questo modello, ma è qualcosa di cui essere consapevole e in considerazione.

Il caso precedente era quello semplice: un ramo dev. Ma cosa succede se hai due rami dev che devono essere riconciliati?

Indico Advanced SCM Branching Strategies di Stephen Vance (una buona lettura quando si parla di ramificazione e sistemi di controllo della versione centrale (piuttosto che distribuiti - sebbene se lo leggete potete sicuramente trovare dei paralleli tra questo documento e cose come git flow ).

Vance identifica ruoli specifici che un ramo può essere. Hai linea principale, sviluppo, manutenzione, accumulo e imballaggio. In questo caso, abbiamo a che fare con mainline, dev e infine con l'accumulo.

Il problema con il lavoro con due rami e il tentativo di unire la linea principale è che può renderlo ancora più disordinato per un periodo di tempo più lungo.

La soluzione è di introdurre un ramo di accumulo.

Nell'esempio precedente, anche il ruolo di accumulo faceva parte del ramo principale (che ha anche il ruolo principale). Sembrava questo:

Tuttavia,quandolecosesicomplicanoconl'unione,avereiruoliprincipaliediaccumulosulramoprincipalepuòportareaproblemi.Quindi,invece,creaunramodiaccumuloacuiunisciiramidisviluppochepossonoquindiesserericonciliatiericollegatiallalineaprincipale.Questaparticolareimmaginemostraancheunramodiimballaggio,maquestononèindiscussionequi.

Un aspetto importante da notare qui è che tutto si dirama dalla linea principale (non da qualche altro ramo), ha un ciclo di vita, si ricongiunge alla linea principale, e quindi è chiuso. Non ci sono rami di lunga durata (diversi dalla linea principale). Ogni ramo ha un ruolo specifico da soddisfare e quando questo è completo il ramo viene rimosso.

    
risposta data 08.08.2014 - 17:20
fonte
0

Questo potrebbe essere perché mi sono tagliato i denti su SVN ma gestiamo grandi DCVS che si fondono allo stesso modo. Inoltre la maggior parte dei progetti open source che vedo ti incoraggiano a seguire uno schema simile con le richieste di pull - non inviarne uno finché non hai reso le tue patch funzionanti con le ultime e migliori.

Quindi non sono sicuro se questo è limitato a SVN ma sì, la pratica che descrivi nella tua domanda non si fonde all'indietro ed è davvero un approccio migliore quando ci sono più mani nel repository.

    
risposta data 08.08.2014 - 15:27
fonte