Qualche motivo per non usare più sistemi di controllo versione?

9

Sto lavorando a un progetto che utilizza GIT come sistema di controllo della versione principale per trunk, filiali ufficiali e la maggior parte dei sottoprogetti / filiali non ufficiali. Come tale, voglio fare in modo che il mio ramo utilizzi GIT per consentire al resto della comunità di accedere al mio ramo usando il sistema che conoscono.

Tuttavia, sto lavorando a una parte del progetto che si sovrappone sia ai rami ufficiali che a quelli non ufficiali, insieme ad alcune patch che non entreranno mai nel trunk - in quanto tale, devo essere in grado di mantenere separate le patch, consentendo a tutti di essere utilizzate in il mio ramo e le patch selettive da prendere per l'uso nel bagagliaio. Questo tende naturalmente all'utilizzo di code mercuriali.

C'è qualche motivo per cui non posso usare mercurial per il mio repository locale, ma spingere il tutto su entrambi i repository ospitati su GIT e Mercurial? O meglio, c'è qualche buona ragione per non farlo, sono sicuro che sia possibile.

version-control git mercurial

— Jon Story
fonte

2

L'unico modo per vedere che funziona è se uno è sempre la copia autorevole e l'altro è sempre generato dal primo. In questo modo non c'è confusione possibile.

— Joachim Sauer,

Grazie, è quello che stavo pensando: Git sarebbe solo uno schiavo di Mercurial. Mercurial è usato normalmente per me, quindi spinge da mercurial a Git per consentire agli utenti Git di accedere al mio ramo (senza campane e fischietti)

— Jon Story

8

Non dovresti farlo per lo stesso motivo per cui non dovresti avere una variabile che tenti di tracciare lo stato di un altro - potresti perdere la traccia di quale versione è autorevole.

— James McLeod
fonte

Uno sarebbe sempre una copia autorevole - Mercurial, in questo caso, poiché è quello che sto usando me stesso per tenere traccia delle modifiche, lavorare con più patch, ecc. Git sarebbe solo uno schiavo, una copia del repository mercuriale per consentire ai membri di la comunità che ha familiarità con Git ma non Mercurial per ottenere una copia del mio ramo. Le persone che sono interessate ai singoli cerotti dovrebbero usare mercurial, ovviamente, ma sto cercando di rimanere all'interno delle convenzioni del progetto, rendendo la vita facile per me stesso.

— Jon Story

Grazie per il feedback. Non è stato interamente per questo motivo (ho anche appena deciso che preferisco GIT e posso vivere senza code mercuriali) ma la tua risposta mi ha fatto capire che la ridondanza è inutile se può essere evitata, che in questo caso può.

— Jon Story,

2

Attualmente lo faccio usando git e svn. Mentre non ci sono ragioni per non per farlo, non esiste una regola generale. Git può fare cose che svn non può, sono abituato a quelle funzionalità, quindi il mio flusso di lavoro aumenta quindi la produttività quando posso usare git. Guardando i pro e i contro nella mia situazione, sarei stupido a non usare entrambi. Dovresti guardare la tua situazione allo stesso modo. (a proposito gli unici contro per me sono dover eseguire un singolo minuscolo script per sincronizzare git con svn)

— Stijn
fonte

1

Puoi mantenere le tue patch separate in Git: esegui ognuna sul proprio ramo, quindi uniscile selettivamente come desideri.

— Marnen Laibow-Koser
fonte