Tecniche di sovversione avanzate, cosa mi sto perdendo?


10

Ho iniziato a usare SVN circa 9 mesi fa ed è stato un cambio di gioco per non dire altro. Anche se, mi sento ancora un po 'perso. Sento che c'è molto di più di cui ho bisogno per sfruttare davvero il mio sviluppo delle applicazioni.

Per esempio

Vorrei essere in grado di mettere in quarantena eventuali cambiamenti volatili / importanti in una sorta di "sotto-repository" o qualcosa del genere. Sto scoprendo che i cambiamenti importanti impediscono correzioni minori che sono abbastanza urgenti. Come posso inviare un semplice aggiornamento senza spingere codice incompleto o rotto?


3
Potresti voler considerare l'uso di hg per le tue filiali locali (puoi usarlo con svn bene, controlla questo )
OneOfOne

Ha! Ti stai perdendo mercuriale.
DexterW

3
"Advanced Subversion" suona come un ossimoro. Usa Git o Mercurial, anche se solo localmente.
Macneil,

Risposte:


7

Per rispondere al tuo esempio, hai tre possibilità per farlo:

  1. È possibile eseguire il commit di singoli file. Se si utilizza un IDE per accedere al repository, è molto probabile che abbia una vista per selezionare o deselezionare singoli file prima di eseguire il commit. Sulla riga di comando digiti svn commit file1 path1/file2 path2per eseguire il commit di file1, path1 / file2 e ogni modifica in path2.
  2. È possibile effettuare diverse copie di lavoro. Lavori sulla tua grande funzionalità nella tua copia di lavoro standard e ottieni le informazioni sul bug urgente. È possibile effettuare il checkout del repository in una directory diversa e correggere il bug in questa seconda copia funzionante. È anche possibile estrarre solo una sottodirectory con il componente in cui si verifica il bug. Dopo aver corretto il bug, puoi eseguire il commit nella seconda copia di lavoro senza impegnare il tuo lavoro sulla funzionalità principale. EDIT: In questo modo è anche descritto nella risposta di Anna Lear.
  3. Crei un ramo per il lavoro sulla tua funzione. Per questo usi il comando copia. Se si utilizza lo standard di layout per il repository (directory con il ProjectName e sottodirectory con i nomi tronco, tag e rami, tronco contenente il progetto) è possibile utilizzare il copia-comando svn come segue per creare il ramo: svn copy svn://hostname/projectname/trunk svn://hostname/branches/branch-for-feature-X. Ora puoi cambiare la tua copia di lavoro nella nuova posizione: svn switch svn switch svn://hostname/projectname/branches/branch-for-feature-X. Se si passa alla modalità di correzione dei bug, si commettono le modifiche effettive, si riporta la copia di lavoro su trunk, si corregge l'errore e si esegue il commit e si ripristina la copia di lavoro sul ramo di funzionalità. Se sei pronto a sviluppare la funzionalità, puoi rimetterla nel trunk.

Per il semplice caso descritto di solito userete il n. 1 (che uso più spesso), a volte il n. 2. Lavorare con i rami (caso n. 3) è più complicato ( leggi di più ), ma consente più trucchi. Ma i rami corrispondono alla descrizione di un sottorepository.

Inoltre dal tuo esempio non posso dire molto. Ci sono molte cose su Subversion, ma non so cosa usi già e di cosa hai bisogno per il tuo progetto. Per saperne di più su SVN, SVN-Book è un'ottima risorsa: http://svnbook.red-bean.com/


3
Il problema con l'approccio n. 1 è che non si può sempre sapere in anticipo che la nuova funzionalità e la correzione di errori non finiranno per comportare modifiche agli stessi file. Per questo motivo, raccomando # 2 (copia di lavoro individuale per ogni funzione o correzione di bug) o # 3 (ramo individuale per ogni funzione o correzione di bug). Le succursali hanno il vantaggio di poter eseguire modifiche su una succursale prima che la funzionalità o la correzione di bug sia completa senza influire sui checkout dal trunk (con copie di lavoro separate, tutti i commit influiscono sul trunk).
Stephen C. Steel,

7

Puoi estrarre il codice in diversi sandbox invece di prendere una sola copia e apportare tutte le modifiche lì.

Quindi potresti avere una struttura di cartelle simile a questa:

D:\Dev\MajorFeature1
D:\Dev\Bug12345
D:\Dev\MajorFeature2

eccetera.

Tutti questi potrebbero essere estratti dalla stessa posizione nel tuo SVN, ad es http://mysvnrepo/trunk.

In questo modo è possibile eseguire il commit dalla sandbox di correzione dei bug senza influire su quelli relativi allo sviluppo delle funzionalità, sebbene sia necessario eseguire svn updateda altre sandbox per eseguire il commit delle modifiche per la correzione dei bug.


4

Hai mai guardato Subversion Branches ?

Una tecnica comune è quella di mantenere stabile il bagagliaio, applicando le correzioni critiche come richiesto. Quindi si crea un ramo per ogni nuovo lavoro significativo. Gli sviluppatori che lavorano su quel progetto controllano il ramo e si impegnano nel ramo. Non influisce sul trunk fino a quando non si decide di unire nuovamente il ramo al trunk principale come parte dell'integrazione finale.

Un altro approccio è quello di disporre di una diramazione per una particolare versione, per evitare che qualsiasi altro lavoro venga accidentalmente eseguito sul trunk causando problemi. È possibile correggere un bug nel 'Ramo di rilascio' come richiesto e quindi ripiegare tali correzioni nel trunk quando è pronto.

I tuoi sviluppatori possono avere più copie funzionanti estratte - il trunk e tutti i rami - o scambiare tra il trunk e un ramo particolare con il svn switchcomando.

Non consiglio di avere molte copie funzionanti di "sandbox" da tenere separatamente alla cassa poiché (a) questo impedisce la collaborazione con altri e (b) sarà troppo facile commettere accidentalmente modifiche non funzionanti, ma al tronco principale.


3

La dimensione corrente della mia copia di lavoro è di 10 GB, con oltre 50.000 file. Posso avere diverse copie per diversi rami, ma ci vuole un po 'solo per creare la nuova copia!

Quando arriva un bug urgente, di solito conservo tutte le mie modifiche in una patch, ripristino tutto, lavoro sul bug e commetto, quindi applico la patch che ho salvato ... Molto più facile e veloce rispetto a ottenere una nuova copia di lavoro. Se avessi bisogno di farlo spesso, avrei due copie funzionanti: una per le modifiche a lungo termine, l'altra per le correzioni di bug.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.