SVN: lavorare con le filiali usando la stessa copia di lavoro

No

Non è un modo sano per lavorare con le filiali. Se si hanno modifiche non eseguite sul ramo e quindi si passa alla directory di lavoro nel trunk, tali modifiche saranno comunque presenti. Se quegli stessi file sono stati patchati sul tronco, si avranno conflitti di fusione. Non passerà molto tempo prima che tu commetta una modifica al trunk che era destinato al ramo.

Lo spazio su disco costa circa dieci centesimi per Gigabyte. Controlla separatamente il tronco e il ramo.

A volte uso svn switch come segue:

• verifica rilascio tag per riprodurre il problema
• crea un ramo di patch
• svn switch per patch ramo. Lo spazio di lavoro non dovrebbe cambiare.
• correzione commit
• crea un nuovo tag

Costruisco anche sistemi di produzione da casse SVN. Lì uso svn switch per aggiornare ad una nuova versione, piuttosto che ottenere un nuovo checkout. Non ho mai commutato un singolo spazio di lavoro tra due rami separati.

Puoi lavorare in questo modo abbastanza felicemente - lo faccio oggigiorno ed è il modo di lavorare con i rami delle funzionalità. Ci sono 2 trappole di cui devi essere consapevole.

1. Qualsiasi lavoro con cui non hai eseguito il commit rimarrà nella tua copia di lavoro e quando lo cambierai verrà unito. questo può significare che potresti impegnarti a lavorare per l'altro ramo. In definitiva è un problema personale - devi essere organizzato.

2. Occasionalmente lavorerò su un ramo e realizzo, d'oh, stavo usando il ramo sbagliato. È facile passare a quello giusto, mantenendo il tuo lavoro (dato che viene unito quando si cambia). Tuttavia, devi essere organizzato.

Ho usato il checkout di un nuovo WC per ogni filiale, che era un buon flusso di lavoro per l'organizzazione che avevamo nella società precedente. Con le casse di riserva questo è facile e veloce. Ora uso i rami di funzionalità, tutti gli sviluppatori per eventuali errori vengono eseguiti su un singolo ramo e uniti al tronco dopo vari controlli di qualità. Funziona bene anche se non si esegue una correzione di bug che non viene unita al trunk per un po 'di tempo (per motivi di "progetto" in genere). Posso lavorare su 4 o 5 filiali al giorno con questo flusso di lavoro.

No, non è sano.

Per prima cosa, i tuoi ragazzi dovrebbero lavorare davvero a livello locale. Se è troppo difficile ricreare un ambiente per eseguire l'app, dovresti affrontarlo.

In secondo luogo, in scenari in cui stavo facendo cose in più rami di lunga data usando SVN, il modo migliore / più pulito per gestirli è stato quello di mantenere più directory di lavoro. Hai bisogno di lavorare sul bagagliaio? Ottimo, lavora nella cartella trunk. Hai bisogno di lavorare sul ramo di rilascio? Ottimo, basta cambiare cartella. Il problema principale era che a volte a SVN non piacerebbe cambiare e uno in genere finiva per spianare e ricontrollare. Questo problema tendeva a manifestarsi quando si lavorava spesso in entrambi i rami. È stato molto più semplice passare semplicemente alle cartelle.

Poi siamo passati a hg e non abbiamo questi problemi. . .

Questa non è una caduta da buca, ma un chiaro avvertimento se stai iniziando a schierare un nuovo.

I just don't want to be sorry three months down the road when its time to integrate the branch back to the trunk.

Quando il lavoro del ramo è completo - vuoi unire, devi attentamente non introdurre la diff in entrambi i modi che diventano incompatibili. Se succede - idealmente dovresti prendere tutte le modifiche da un ramo all'altro prima di salire.

Inoltre, assicurati di ricordare l'avvio del ramo SVN e l'ultima fusione. Se si prendono le stesse revisioni e si tenta di unire quella diff due volte, i risultati saranno problematici.

La ramificazione è un must per tutti i progetti praticamente di grandi dimensioni.