Tecniche avanzate di sovversione, cosa mi manca?

Per affrontare il 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 una vista, per selezionare o deselezionare singoli file prima di impegnarsi. Sulla riga di comando si digita svn commit file1 path1/file2 path2 per salvare file1, percorso1 / file2 e ogni modifica sotto percorso2.
2. Puoi fare diverse copie di lavoro. Lavori sulla tua ampia funzionalità nella tua copia di lavoro standard e ottieni le informazioni sul bug urgente. Puoi eseguire il checkout del tuo repository in una directory diversa e correggere il bug in questa seconda copia di lavoro. È anche possibile controllare solo una sottodirectory con il componente in cui si verifica il bug. Dopo la correzione di bug è possibile eseguire il commit della seconda copia di lavoro senza impegnare il lavoro sulla funzionalità principale. EDIT: Questo modo è anche descritto nella risposta di Anna Lear.
3. Crei un ramo per il lavoro sulla tua funzione. Per quello usi il comando copia. Se si utilizza il layout standard per il proprio repository (directory con il nome del progetto e sottodirectory con i nomi trunk, tag e rami, trunk contenente il progetto) è possibile utilizzare il comando svn-copy-command 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 attiva la modalità di bugfix, si commettono le modifiche effettive, si ripristina la copia di lavoro su trunk, si corregge il bug e si esegue il commit e si riporta la copia di lavoro al ramo di funzionalità. Se sei pronto a sviluppare la funzione, puoi unirla al tronco.

Per il caso semplice descritto userai solitamente # 1 (uso più spesso), a volte # 2. Lavorare con le filiali (caso # 3) è più complicato ( leggi altro ), ma consente per più trucchi. Ma i rami corrispondono alla tua descrizione di un sotto -posto.

Oltre al tuo esempio non posso dire molto. Ci sono molte cose su Subversion, ma non so cosa tu usi già e cosa ti serve per il tuo progetto. Per saperne di più su SVN, SVN-Book è una grande risorsa: link

Puoi estrarre il codice in diverse sandbox invece di prendere solo una 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

ecc.

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

In questo modo puoi eseguire il commit dalla tua sandbox di correzioni di bug senza influire su quelle di sviluppo delle funzionalità, anche se dovrai eseguire svn update da altre sandbox per ottenere il commit delle modifiche per la correzione dei bug.

Hai guardato Subversion Branches ?

Una tecnica comune è mantenere stabile il tronco, applicando le correzioni critiche necessarie. Quindi crei un ramo per ogni nuovo significativo lavoro. Gli sviluppatori che lavorano su quel progetto controllano il ramo e si impegnano nel ramo. Non ha effetto sul Trunk fino a quando non decidi di unire il ramo al trunk principale come parte della tua integrazione finale.

Un altro approccio è quello di avere un ramo per una particolare versione, per evitare che altri lavori vengano fatti accidentalmente sul tronco causando problemi. Puoi correggere gli errori del 'Release Branch' come richiesto e poi ripiegare le correzioni al trunk quando sei pronto.

I tuoi sviluppatori possono avere estratto più copie di lavoro, il tronco e le eventuali diramazioni, oppure possono scambiare tra il tronco e un ramo particolare con il comando svn switch .

Non raccomando di avere molte copie di lavoro "sandbox" che controlli separatamente (a) questo proibisce la collaborazione con altri e (b) sarà troppo facile per accidentalmente commettere modifiche non funzionanti, tuttavia le modifiche principali tronco.

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

Quando arriva un errore urgente, di solito salverò tutte le mie modifiche in una patch, ripristinerò tutto, lavoro sul bug e commit, quindi applicherò la patch che ho salvato ... Molto più facile e più veloce di ottenere una nuova copia di lavoro. Se dovessi farlo spesso, avrei due copie funzionanti: una per le modifiche a lungo termine, l'altra per le correzioni dei bug.