Best practice per il controllo della versione con più progetti

Question

Ho diversi progetti con un code-base molto ampio e sovrapponibile. Di recente abbiamo iniziato a utilizzare SVN, quindi sto cercando di capire come utilizzarlo.

Il problema è che mentre sto completando un'attività su un progetto, sto iniziando un compito su un altro, con qualche sovrapposizione. Spesso c'è anche un sacco di sviluppo guidato dagli interrupt. Quindi, il mio codice non è mai in uno stato completamente stabile che mi fa sentire a mio agio.

Il risultato è che non stiamo realmente utilizzando il sistema VC, che è una cosa MOLTO male, lo sappiamo tutti ... quindi, suggerimenti?

Answer 1

Controlla un ramo personale del codice e unisci le modifiche. Almeno avrai qualche controllo di versione per le tue modifiche, nel caso tu debba effettuare il rollback. Una volta che hai dimestichezza con lo stato in cui si trova il tuo ramo, unisci quel ramo nel tronco.

È anche possibile controllare un ramo per ogni attività, anziché uno per ogni individuo. È inoltre possibile unire le modifiche al ramo dal trunk se qualcuno modifica il trunk e si desidera che il ramo rifletta le modifiche.

Questo è un modo comune di utilizzare SVN, anche se esistono altri flussi di lavoro. Ho lavorato su progetti in cui avevo paura di commettere (potrei interrompere la creazione probabilmente) perché non abbiamo usato efficacemente la ramificazione.

La ramificazione è davvero potente nell'aiutare il flusso di lavoro, usarlo finché non si ha familiarità con l'idea della fusione.

Modifica: "Estrarre un ramo" si riferisce alla creazione di un ramo nella cartella dei rami e quindi al controllo di quel ramo. La struttura del repository svn standard è costituita dal trunk, tag e rami delle cartelle nella radice.

Answer 2

In TFS, è possibile creare "Set di scaffali" (non sono sicuro di ciò che verrebbero chiamati in altri fornitori di controllo del codice sorgente). Quando si accantona del codice, lo si salva nel repository, ma non lo si controlla.

Il motivo per cui questo è importante è che se si sta lavorando su Bug XXXX e si risolve metà del codice, ma non lo è stabile e non "controllabile", ma vieni assegnato a Nuova funzionalità YYYY, NON DEVI continuare a lavorare con lo stesso codice base. Dovresti "riporre" il tuo codice Bug XXXX, quindi restituire la base di codice locale all'ultimo codice di accesso e implementare la nuova funzionalità YYYY.

In questo modo si mantengono i check-in atomici. Non devi preoccuparti di perdere il tuo lavoro, perché è ancora detenuto dal repository (quindi se il tuo computer irrompe in fiamme, non devi scoppiare a piangere), e non stai mescolando le tue correzioni per XXXX con il tuo nuovo codice per YYYY. Quindi, una volta che ti viene chiesto di tornare indietro a XXXX (supponendo che tu abbia fatto il check-in YYYY) puoi semplicemente sgomberare il tuo "set di scaffali" e tornare direttamente al punto in cui eri rimasto.

Answer 3

O accettare che il codice in SVN non sia in uno stato completamente stabile e controllarlo in ogni caso (e riservare il tempo per la stabilizzazione e il refactoring ogni X giorni/settimane in modo che il codice non si degradi troppo).

Oppure costringere la tua squadra a lavorare in modo più strutturato con uno sviluppo basato su interruzioni minime in modo da poter controllare un buon codice.

La prima opzione non è l'ideale (ma è meglio non controllare la sorgente), il secondo è probabilmente impossibile - non c'è una terza opzione.

Se non si ha il tempo di riportare il codice a uno stato stabile, non si ha il tempo di ramificarsi e unirsi in modo permanente.

Answer 4

Quindi, il mio codice non è mai realmente in uno stato completamente stabile che mi sento a mio agio il check-in.

Perché?
Se il tuo ramo è appropriato per il tuo lavoro (con una buona convenzione di denominazione per esempio), tutti sapranno che il suo HEAD non è sempre stabile.
In questo tipo di ramo "funzionante", basta mettere qualche tag lungo la strada per indicare alcuni "punti di codice stabili" (che possono essere interrogati da qualsiasi tester da distribuire).
Qualsiasi altra versione su quel ramo di lavoro viene creata per registrare le modifiche, anche se lo stato corrente non è stabile.

Quindi successivamente si uniscono tutti su un ramo che si suppone rappresenti uno stato stabile.

Answer 5

Nei sistemi di controllo di output distribuiti come GIT, si esegue il commit nel repository locale. Solo quando si preme il codice, è "impegnato" nel repository remoto.

In questo modo, è molto più facile "mettere in sicurezza" il tuo lavoro nel mezzo.