Utilizzo del repository Mercurial all'interno di Git: fattibile? Sane?

3

Sto pensando di creare un repository Mercurial sotto un repository Git. per es.

..../git-repository/directory/hg-repo/

I 2 repository

È possibile gestire (mantenendo la sanità mentale)? Com'è facile per questo ?

Sono uno studente di informatica all'Università. Gestisco il mio lavoro in Git, principalmente come meccanismo di distribuzione (dopo aver capito che rsync fallisce quando si verificano cambiamenti in più di un posto) tra il mio desktop e l'unità USB. Cerco di usare Git come VCS mentre lavoro.

Ho finito un semestre in cui ho fatto un piccolo progetto di gruppo per preparare un progetto di gruppo più ampio il prossimo anno. Abbiamo dovuto usare Subversion e provato le gioie di un VCS centralizzato (inclusi i tempi di inattività).

Ho cercato di mantenere separato il repository di subversion nel mio repository Git per il soggetto **, tuttavia era fastidioso che fosse separato (non nel luogo in cui memorizzo i compiti). Mi sono quindi spostato su un repository Subversion all'interno del mio repository Git.

Come penso in anticipo (forse sto pensando troppo avanti) mi rendo conto che dovrò cercare di convincere le persone a usare un DVCS e Mercurial sarà probabilmente quello preferito (supporto per Windows e Mac GUI, più vicino a Subversion).

Avendo fatto qualche ricerca nell'intero dibattito Git vs Mercurial (comunque non usato Mercurial) preferisco ancora Git.

Posso avere un repository Mercurial all'interno di un Git senza impazzire (o rovinando qualcosa)? O è qualcosa che non dovrei considerare affatto?

(Oppure è una cattiva domanda che dovrebbe essere cancellata?)

** Penso che al di fuori dell'Australia si chiami un corso

    
posta Portablejim 02.11.2011 - 00:50
fonte

4 risposte

2

Dai un'occhiata all'estensione di hg-git per Mercurial, link . Permette di accedere a un repository Git (inclusi pull, push e commit) usando Mercurial. Lo uso per gestire i miei progetti su Github usando TortoiseHg su Windows. Non ho ancora avuto problemi con questo approccio.

    
risposta data 02.11.2011 - 19:42
fonte
2

Non è necessario mantenere un repo hg sotto il tuo repository git. Quando (se) arriva il momento di passare a hg, usa hg convertire l'estensione .

Implementation information can be found here: ConvertExtensionImplementation...

The Convert extension converts repositories from other SCMs (or even Mercurial itself) into Mercurial repositories, with options for filtering and renaming. It can also be used to filter Mercurial repositories to get subsets of an existing one.

The current release supports the following repository types as sources:

  • CVS
  • Subversion
  • Git
  • Darcs
  • Monotone
  • Bazaar
  • GNU Arch
  • Mercurial
  • Perforce...
    
risposta data 02.11.2011 - 01:48
fonte
0

Ho fatto cose simili durante la transizione dei progetti. Non lo raccomanderei particolarmente - c'è sempre una rete fissa da cui partire e sicuramente ci sono alcune opzioni fuori dal tavolo. Vorrei solo usare hg per il progetto e trasferire il bit finale in git quando è fatto.

Sul lato tecnico, assicurati di ignorare la cartella .hg e altri artefatti hg. Questo almeno ti dà una possibilità di combattere.

    
risposta data 02.11.2011 - 13:43
fonte
0

Per il trasferimento / sincronizzazione di file / distribuzione, potresti provare Unison invece di git.

Unison is a file-synchronization tool for Unix and Windows. It allows two replicas of a collection of files and directories to be stored on different hosts (or different disks on the same host), modified separately, and then brought up to date by propagating the changes in each replica to the other.

Unison shares a number of features with tools such as configuration management packages (CVS, PRCS, Subversion, BitKeeper, etc.), distributed filesystems (Coda, etc.), uni-directional mirroring utilities (rsync, etc.), and other synchronizers (Intellisync, Reconcile, etc). However, there are several points where it differs:

  • Unison runs on both Windows and many flavors of Unix (Solaris, Linux, OS X, etc.) systems. Moreover, Unison works across platforms, allowing you to synchronize a Windows laptop with a Unix server, for example.
  • Unlike simple mirroring or backup utilities, Unison can deal with updates to both replicas of a distributed directory structure. Updates that do not conflict are propagated automatically. Conflicting updates are detected and displayed.
  • Unlike a distributed filesystem, Unison is a user-level program: there is no need to modify the kernel or to have superuser privileges on either host.
  • Unison works between any pair of machines connected to the internet, communicating over either a direct socket link or tunneling over an encrypted ssh connection. It is careful with network bandwidth, and runs well over slow links such as PPP connections. Transfers of small updates to large files are optimized using a compression protocol similar to rsync.
  • Unison is resilient to failure. It is careful to leave the replicas and its own private structures in a sensible state at all times, even in case of abnormal termination or communication failures.
  • Unison has a clear and precise specification.
  • Unison is free; full source code is available under the GNU Public License...
    
risposta data 10.06.2012 - 21:45
fonte

Leggi altre domande sui tag