2011-01-05 17 views
10

Ho letto i sottorepository e come estrarre una cartella esistente da un repository Mercurial in un sottorepo utilizzando l'estensione convert e una filemap. Posso farlo con successo. Se ho la seguente struttura di cartelle:Come convertire un repository Mercurial esistente per utilizzare i sottorepository e mantenere intatta la cronologia?

C:\Project 
---Project\root.txt 
---Project\SubFolder 
---Project\SubFolder\fileinsubfolder.txt 

posso fare una subrepository di sottocartella. Più o meno allo stesso modo posso estrarre tutto il resto da un repository separato (in questo esempio il secondo repository avrebbe solo il file root.txt). Successivamente, posso aggiungere il repository SubFolder come sottoreposizione al secondo repository. Ma sebbene entrambi i repository abbiano la cronologia completa, queste cronologie non sono collegate => l'aggiornamento del repository root in uno stato precedente non pone il sottoreport nello stato in cui dovrebbe trovarsi in quel punto. L'aggiornamento a una revisione più vecchia consistente (sia root che sottoreport aggiornati automaticamente) funzionerà solo quando si aggiorna a una revisione che già conosce il sottoregistro e ha il file .hgsubstate.

E in alternativa ho pensato di dimenticare i file in SubFolder nel repository corrente e di aprire un nuovo repository in SubFolder e allo stesso tempo aggiungere un file .hgsub. Quello che spero di ottenere qui è lavorare da questo punto in poi con un sotto -posto ma avere ancora un modo per aggiornare ad una revisione precedente (prima di separare il sottorepo) perché i file di Sottocartella sono ancora nella cronologia del repository corrente.

Questo non funziona però: quando ho dimenticato i file nella mercuriale, Inited un nuovo pronti contro termine e legato come un subrepo nel repository corrente e mi aggiorna ad una revisione più vecchia prima del subrepo esisteva ottengo questo errore:

C:\Project>hg update 1 
abort: path 'SubFolder\fileinsubfolder.txt' is inside repo 'SubFolder' 

il problema qui è che durante l'aggiornamento di una revisione più vecchia, che non era a conoscenza della subrepo, questo aggiornamento vuole mettere i file nella sottocartella. Ma questa sottocartella è ancora un altro repository (ha una directory .hg) e sebbene il repository principale non ne abbia memoria, l'aggiornamento non vuole mettere i file nella sottocartella in quanto è un repository.

Esiste comunque un modo per aggirare questo errore o esiste un metodo migliore per passare all'utilizzo di un sottorepo per una determinata cartella in un repository Mercurial esistente e mantenere intatta la cronologia (e entrambe le cronologie sono collegate)?

+0

Quindi, come hai gestito questo, in assenza della soluzione discussa con @ Martin? La soluzione "dimentica" funzionerebbe se il sottorepo fosse posizionato su un percorso diverso (rispetto ai file originali)? Nel mio caso, stavo programmando di spostare i file comunque ... pubblicherò come va. – harpo

risposta

4

No, temo che non ci siano strumenti che ti consentano di dividere un repository nel modo in cui lo chiedi.

Giusto per chiarire la tua domanda, allora immaginiamo di avere un archivio in cui il contenuto di root.txt e sub/file.txt evolvere come questo

root.txt sub/file.txt` 
0: root 0 file 0 
1: root 1 file 1 
2: root 2 file 2 

per i primi tre gruppi di modifiche. Quello che si chiede è un'opzione per hg convert che trasformare questo in due depositi (facile, possiamo farlo oggi) e dove l'estensione convert inietta .hgsub e .hgsubstate file in modo che i tre gruppi di modifiche contengono

root.txt .hgsub  .hgsubstate |  file.txt 
0: root 0 sub = sub <X> sub  | <X>: file 0 
1: root 1 sub = sub <Y> sub  | <Y>: file 1 
2: root 2 sub = sub <Z> sub  | <Z>: file 2 

dove la <X>, <Y> e <Z> gli hash sono quelli corrispondenti ai primi tre commit nel sottorepository.

Non esiste una tale opzione per hg convert oggi, ma in base a quanto sopra sembra possibile scriverne uno. Questo ti darebbe un ottimo modo per convertire avanti e indietro tra un repository combinato e uno split.

+0

Questo è esattamente ciò che vorrei e sarebbe perfetto per dividere un repository esistente. – Christophe

+2

Giusto, siamo contenti di essere d'accordo su quale sia il problema ... ora qualcuno ha bisogno di passare il tempo ad implementarlo :) –

+0

Martin, potresti sapere se è stato fatto? – devuxer

Problemi correlati