В моей организации мы хотели бы перейти с использования CVS на Mercurial по ряду причин.Мы провели много исследований, пытаясь определить, как мы должны организовать наши репозитории Hg на основе того, что у нас есть в нашей кодовой базе и как мы склонны работать.Мы нашли удовлетворительные ответы на большинство наших вопросов, но есть один момент, который немного озадачивает нас, и это сводит меня с ума, потому что самый удобный способ организовать репо для нашего рабочего процесса просто кажется неправильным путемконцептуальная точка зрения.Я пытаюсь выяснить, является ли наше восприятие того, как это «должно» работать, неправильным или мы просто сталкиваемся с законным пробелом в доступных инструментах.
Прежде всего мы поддерживаемкодовая база среднего размера, состоящая из набора приложений, которые выпускаются в одном пакете.Концептуально вы можете разделить наш код на три категории:
- Общий код
- Код приложения для нашего основного пакета (использует общий код)
- Различные небольшие утилиты, которыеподдерживается редко (использует общий код)
Это не кажется мне необычным, но я хочу подчеркнуть, что мы поддерживаем код приложения и общий код одновременно и всегда хотимони должны быть кровоточат по отношению друг к другу.То есть мы хотим, чтобы все наши сборки приложений всегда использовали самую последнюю версию и одну и ту же версию общего кода.Мы часто добавляем или изменяем код приложения и общий код одновременно.В настоящее время общий код находится в одном модуле CVS, а все приложения находятся в своих отдельных модулях.Общий код и модули приложения извлекаются таким образом, что общий код создается один раз, а затем связывается с каждым приложением.Мы часто делаем коммиты cvs, которые включают изменения между общими и прикладными модулями одновременно.Нам бы очень хотелось сохранить эту возможность.
Я понимаю, что коммиты в Hg являются атомарными в репозиториях - это прекрасно, но я бы хотел иметь возможность разглядывать и фиксировать приложение и общую библиотеку в«в одно и то же время» (т.е. мне все равно, действительно ли это атомарно, но я не хочу вручную делать два отдельных diff-файла и два отдельных действия фиксации).
Концептуально кажется, что это будетправильно иметь одно или несколько репо для общего кода, а также отдельное репо для каждого приложения и каждой маленькой служебной программы.Это означает, что вам нужно проверить несколько репозиториев для каждой сборки, но для нас это не проблема.Проблема в том, что, похоже, нет какого-либо инструмента, который позволял бы вам просматривать обновления или изменения сразу на нескольких репо или разносить несколько репо одновременно, а затем последовательно фиксировать их для вас.Это было бы легко написать, но это не помогло бы разработчикам, которые хотят использовать различные интерфейсы графического интерфейса для дополнения командной строки.
Похоже, что можно выполнять фиксацию одновременно на нескольких кодовых базах (отс точки зрения пользователя) и держите все на переднем крае, единственными двумя решениями являются:
- Использование монолитного репо с ВСЕМ в нем.
- Создайте несколько подпунктов, но получите доступ / совершитевсе через большой монолитный «основной» репо, который содержит все подпункты, чтобы держать все в последних ревизиях (что не кажется мне лучше, чем (1)).
Это не можетНеобычно хотеть работать с несколькими «одноранговыми» репозиториями одновременно, даже если действия не являются действительно атомарными во всех них - и все же я не нахожу тонны статей или сообщений, требующих этой способности.
В итоге:
- Мы хотели бы организовать наш код так, чтобы мы могли различать и фиксировать код приложения иобщий код в то же время с точки зрения пользователя (они не обязательно должны быть атомарными).
- Кажется, что мы должны помещать код приложения и общий код в отдельные репозитории.
- Подпозитории связывают родительские репозитории с конкретными ревизиями, которые нам не нужны.
Что мне здесь не хватает?