Garantire il successo delle fusioni in Subversion

4

Subversion Re-education in realtà mi ha convinto, ma per ora mi limiterò a svn - padroneggiare l'uso di uno strumento molto popolare puo ' essere cattivo.

Fino ad oggi non ho usato branching / merges nel codice di produzione, ora ho deciso di provarlo in un ambiente di piccola squadra.

Ho paura di soffrire lo stesso dolore descritto nell'articolo di Spolsky. Esiste un modo "giusto" per lavorare con le filiali in svn?

    
posta vemv 04.11.2011 - 20:55
fonte

2 risposte

5

La parte più importante del lavoro con i rami di Subversion è di unire dal tronco spesso . Ogni giorno al minimo, più se possibile. L'inverso è anche vero - unisci spesso a trunk - una volta che le funzioni possono andare al trunk, unirle.

Più rami divergono gli uni dagli altri, più la fusione diventa infernale.

Quanto più tempo intercorre tra le unioni, più file si dovranno unire, maggiori sono le probabilità di conflitti e maggiori sono le possibilità che le persone non richiamino i dettagli delle modifiche (il che significa che rendere la chiamata corretta a un conflitto può diventare molto difficile).

Dovrai anche decidere su branching strategia - questo non è qualcosa che tu dovrà adattarsi alla tua squadra e al tuo flusso di lavoro e probabilmente sarà necessario modificarli mentre procederai. Presentazione interessante qui (pdf).

    
risposta data 04.11.2011 - 21:01
fonte
1

La ramificazione inizia sempre con la paura che la fusione spezzerà le cose o lascerà a lungo gli errori inosservati.

Tuttavia, è l'elemento più essenziale per un prodotto o un progetto di dimensioni ragionevoli. Ecco le poche categorie distinte in cui i rami sono un must - sono:

1. Rilascio post filiale
Questo è fatto per mantenere le patch post rilascio. queste patch sono essenziali per supportare le versioni attuali sul mercato fino a quando le prossime versioni principali non sono ancora pronte.

2. Filiale per attività o componente Qui a pochi gruppi indipendenti viene assegnata la filiale che tengono il check-in mentre il resto del team (o altre filiali) non deve accettare alcun lavoro fino a quando l'intera nuova funzionalità o progetto non è completamente finito e unito al trunk.

3. Diramazione per assistenza clienti speciale Qui vengono creati alcuni rami per supportare solo uno specifico (insieme) di clienti.

Branching and merging inizia sempre con un po 'di paura, ma nella mia esperienza, quando le persone iniziano a inserire il codice disciplinato, diventa indispensabile per qualsiasi sviluppo di grandi dimensioni.

Vedi URL qui sotto per maggiori dettagli.

link

link

    
risposta data 04.11.2011 - 21:20
fonte

Leggi altre domande sui tag