I commit e l'unione su sottodirectory SVN sono considerati dannosi?

Question

Nella sottostruttura principale del progetto SVN sono presenti numerosi sottoprogetti di grandi dimensioni.
Io commetto e unisco solo il mio sottoprogetto quando lavoro con i nostri rami di rilascio, principalmente perché è più veloce.

Tuttavia, un collega ha sottolineato questo reference to merging subdirectories in Version Control with Subversion (alias "The SVN Book"):

• Per rami di rilascio longevi (come descritto nel the section called “Common Branching Patterns”), effettuare fonde solo sulla radice del ramo, non su sottodirectory.

Sfortunatamente, questa è l'estensione dell'avviso. Anche la sezione collegata non fornisce una spiegazione.

Si stanno commettendo e unendo sottodirectory SVN dannose per i rami di rilascio?
E i rami delle funzionalità di breve durata?

Answer 1

Una possibile spiegazione è che è possibile dimenticare parti di un set di modifiche.

Se la modifica imposta l'unione di file di copertura esterni alla sottodirectory che è stata estratta, è sempre possibile che si dimentichi di unire tali file.

Ad esempio, se si dispone di un commit come questo sul tronco:

r5 | rich | 2009-04-16 22:22:46 +0200 (Thu, 16 Apr 2009) | 2 lines 
Changed paths: 
    M /trunk/subdir1/main.c 
    M /trunk/subdir2/main.c 

Change some stuff 

E poi hanno una cassa di subdir1 dal ramo "stabile", allora si potrebbe unire il cambiamento impostare R5 in questo modo:

$ svn co http://example.com/svn/branches/stable/subdir1 
$ cd subdir1 
$ svn merge -c 5 http://example.com/svn/trunk/subdir1 . 
--- Merging r5 into '.': 
U main.c 
$ svn ci -m"Merged r5 from trunk" 

Ma questo si fonderà solo la metà di revisione 5. Peggio ancora, se si va indietro e guardare il registro, sarà ora mostrare questo:

$ svn log -g http://example.com/svn/ 
... 
------------------------------------------------------------------------ 
r5 | rich | 2009-04-16 22:22:46 +0200 (Thu, 16 Apr 2009) | 2 lines 
Changed paths: 
    M /trunk/subdir1/main.c 
    M /trunk/subdir2/main.c 
Merged via: r6 

Change some stuff 

Quindi sembra che tu abbia unito l'intero commit, quando in realtà ne hai solo un po 'fuso. Ovviamente r6 mostra che solo un file è cambiato sul ramo stabile.

------------------------------------------------------------------------ 
r6 | rich | 2009-04-16 22:28:16 +0200 (Thu, 16 Apr 2009) | 1 line 
Changed paths: 
    M /branches/stable/subdir2 
    M /branches/stable/subdir2/main.c 

Merge revision 5 from trunk 

Qualcuno deve ricordare, o l'avviso, che solo una parte del set di cambiamento ottenuto fuse e il resto deve fare. Non utilizzare le unioni di sottodirectory evita questo problema.

Ci sono momenti in cui davvero non si vuole unire tutto il commit precedente e lo scenario sopra riportato è esattamente ciò che si intendeva fare. In tal caso, è probabilmente meglio aggiungere un buon messaggio di commit che descriva le tue intenzioni.

Answer 2

Il commit non dovrebbe avere un problema, ma in unione SVN tiene traccia di ciò che è e non è unito.

Pertanto, presumo che si desideri unire alla radice per semplificare le future unioni (rispetto alla dimensione del set di dati confrontata da SVN).

Answer 3

Per versioni di versioni precedenti precedenti alla 1.5, l'unione di sottodirectory effettuate in seguito unisce il resto dell'albero di directory davvero complicato. Se hai unito una directory, svn ha semplicemente applicato tutte le modifiche apportate in quella directory all'altro ramo.Se avevi già unito una sottodirectory e poi hai provato a unire la directory principale, tutte le modifiche nella sottodirectory erano già nel ramo di destinazione (dato che le hai unite prima). Svn ora non sapeva che questi cambiamenti provenivano da una precedente fusione, ha appena visto che c'erano delle cose "nel modo" quando cercava di unire la sottodirectory, causando molti conflitti.

Per evitare questo, avresti dovuto fare attenzione a unire solo le directory che non erano state unite prima, rendendo l'intero processo molto più complicato. Dovevi ricordare esattamente quali revisioni di quali sottodirectory hai già fuso e applicare solo le rimanenti modifiche delle restanti directory/revisioni. Questo può diventare confuso. Unire sempre l'intero ramo ha reso tutto molto più semplice. Le versioni correnti di sovversione tengono traccia delle precedenti fusioni internamente, in modo che questi problemi possano essere evitati.

La registrazione di sottodirectory non è un problema. Per svn questa è solo una normale revisione globale del repository. In quella revisione ci saranno solo modifiche in una sottodirectory, ma per svn è ancora una nuova versione dell'intero repository, proprio come qualsiasi altro commit.

Answer 4

Un altro motivo potrebbe essere che l'unione solo con la radice limita il numero di proprietà svn: mergeinfo che verranno impostate nelle cartelle/file nel repository.