Будь-які причини не використовувати декілька систем управління версіями?


9

Я працюю над проектом, який використовує GIT в якості основної системи контролю версій для магістралей, офіційних відділень та більшості підпроектів / неофіційних гілок. Я хочу зробити так, щоб моя власна філія використовувала GIT, щоб дозволити іншій громаді отримати доступ до моєї філії за допомогою системи, яку вони знають.

Однак я працюю над частиною проекту, який перекриває як офіційні, так і неофіційні відділення, а також деякі патчі, які ніколи не увійдуть у магістраль - як такий, мені потрібно вміти тримати окремі патчі, що дозволяють використовувати всі мою гілку та вибіркові патчі, які потрібно взяти для використання в багажнику. Це, природно, схиляється до використання ртутних черг.

Чи є якась причина, що я не можу використовувати mercurial для свого власного локального сховища, але підштовхую цілість до GIT і Mercurial сховищ? А точніше, чи є якась вагома причина цього не зробити, я впевнений, що це можливо.


2
Єдиний спосіб я бачу, що це робота, якщо одна завжди є авторською копією, а інша завжди генерується з першої. Таким чином, можливого плутанини немає.
Йоахім Зауер

Спасибі, ось що я думав - Гіт був би просто рабом Меркуріала. Меркуріал використовується для мене як звичайне, а потім натискати з меркуріалу на Git, щоб дозволити користувачам Git отримати доступ до моєї гілки (без дзвіночків)
Jon Story

Відповіді:


8

Ви не повинні робити це з тієї ж причини, у вас не повинно бути змінної, яка намагається відстежувати стан іншого - ви можете втратити відслідковувати, яка версія є авторитетною.


У цьому випадку завжди була б авторитетна копія - Mercurial, оскільки саме я використовую себе для відстеження змін, роботи з декількома виправленнями тощо. Git був би просто невільником, копією сховища ртутних даних, щоб дозволити членам громада, яка знайома з Git, але не Mercurial, щоб отримати копію мого відділення. Людям, які цікавляться окремими патчами, очевидно, доведеться використовувати меркурій, але я намагаюсь дотримуватися конвенцій проекту, полегшуючи собі життя.
Jon Story

Дякуємо за відгук. Це було не зовсім з цієї причини (я також просто вирішив, що віддаю перевагу GIT і можу жити без черкавих черг), але ваша відповідь змусила мене зрозуміти, що надмірність є безглуздою, якщо її можна уникнути, чого в цьому випадку можна.
Історія Джона

2

Зараз я роблю це за допомогою git та svn. Хоча є причини цього не робити, загального правила немає. Git може робити те, що svn не може, я звик до цих функцій, отже, мій робочий процес збільшує продуктивність, коли я можу використовувати git. Дивлячись на плюси і мінуси в моїй ситуації, я був би дурним не використовувати обох. Ви повинні дивитися на свою ситуацію так само. (btw - єдині мінуси для мене - це запустити єдиний крихітний сценарій для синхронізації git зі svn)


1

Ви можете зберігати свої патчі окремо в Git: робити кожен на своїй гілці, а потім об'єднати їх вибірково за бажанням.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.