Posso trasferire le modifiche a più sottorepos di mercurial in un nuovo ramo denominato?

Question

Ho un repository mercurial con più repository secondari al suo interno. Il repository ha una soluzione di studio visivo contenente progetti nel repository e nel sottorepo.

Supponiamo di voler implementare una nuova funzionalità che richiederà modifiche al progetto principale nel repository e le modifiche a uno dei suoi progetti di dipendenza nella soluzione (poniamo, aggiungendo una nuova interfaccia condivisa nella dipendenza e un'implementazione dell'interfaccia nel progetto principale).

Quindi voglio confermare le modifiche, ma a un nuovo ramo con nome in quanto non è terminato e verrà unito in seguito. Usando tortoiseHg I commetto le modifiche nel repository, specificando un nuovo ramo da creare. Il commit a sua volta commette le modifiche del sub-repository, ma nei miei test non crea un nuovo ramo nel suo repository, ma aggiunge semplicemente il changeset al ramo corrente.

Posso eseguire il commit sul sub-repository in modo esplicito e specificare il nome del ramo in quel momento, ma speravo in un modo per trasferire l'intero set di modifiche tra repository ai nuovi rami in ogni repository in una volta, quindi il mio flusso di lavoro è più pulito. È possibile?

Answer 1

Prima commettere il sub-repo e creare un ramo denominato lì.

Successivamente il commit principale deve continuare a eseguire il commit in tale sub-reposlo nello stesso ramo di prima.

Innanzitutto dovresti pensare ai due repository come separati, completamente separati. In altre parole, fai qualcosa in un repository e lo commetti. Quindi fai qualcosa nell'altro repository e lo impegni.

La relazione dei due repository è che il repository principale memorizza un file, il file .hgsubstate, che contiene l'hash del genitore della cartella di lavoro di ciascun sotto-repository.

In altre parole, il sotto-repository non ha alcuna conoscenza di per sé che faccia parte di un quadro più ampio. Tuttavia, il repository principale conosce la revisione corrente ritirata in quel sotto-repository. Questa conoscenza è impegnata nel repository come parte dei normali commit.

Ciò significa che se si esegue qualcosa nel repository secondario, commit this, il sub-repository è ora in una nuova revisione. Quando successivamente si esegue il commit nel repository principale, l'hash della nuova revisione nel repository secondario viene aggiornato nel file .hgsubstate e quindi eseguito il commit.

Lo scopo alla base di questo è ovviamente che se si aggiorna a una revisione precedente nel repository principale, una vecchia copia del file .hgsubstate viene inserita anche nella cartella di lavoro e quindi il repository secondario viene aggiornato a quella revisione, che ha l'effetto di tornare indietro nel tempo al modo in cui il sotto-repository sembrava quando quelle revisioni erano in gioco.

Inoltre, i comandi sul repository principale a volte funzionano anche sui repository secondari. Se si esegue il push nel repository principale, vengono inoltrati anche i sub-repository, per garantire che altri utenti che clonano il proprio repository principale possano fare affidamento sulla possibilità di clonare il contenuto appropriato per il repository secondario.

Quindi per rispondere alla tua domanda nei commenti.

Se si crea un ramo nel repository secondario, denominato o altrimenti, si continuerà a inviare nuovi changeset su tale ramo. A un certo punto è necessario unire e è necessario unire nel repository secondario e nel repository principale.

Per prima cosa è necessario unire il sotto-repository. Questo termina con un commit, il che significa che il sotto-repository è ora nel changeset che ha eseguito il commit. Quindi si fondono nel repository principale e si esegue il commit, che memorizza tale conoscenza, quale changeset nel sub-repository che è in uso al momento.

Quindi sì, è necessario unire entrambi, in un secondo momento.