Я работаю в компании, где мы создаем множество небольших приложений для конкретных клиентов.
Мы несколько разработчиков, но в большинстве случаев на проект приходится только один разработчик.
Customer1
ProjectX
App
Tests
ProjectY
App
Tests
Customer2
Project2
Products
Product1
Common
Сегодня все хранится в одном хранилище.
Процесс прост.
- Разработчик берет новый проект для клиента
- Создать новую папку для проекта
- Код в новом проекте
- Выполнить техническое обслуживание в другом проекте
- Проверка обновлений проекта технического обслуживания
- Больше работы в новом проекте
- Регистрация в новом проекте
- Доставить клиенту
Нет тегов и разветвлений. Более ранние версии проверены на основе даты.
Этот процесс хорошо работал в течение многих лет, но есть несколько болевых точек с текущим инструментом (CVS)
- Медленное. Оформление заказа занимает минуты, даже если ничего не изменилось. История хранится на сервере, поэтому diffs занимает слишком много времени
- Добавление новых проектов. Если вы работали с CVS, вы знаете, что это похоже на: добавить папку, добавить файлы в папку, добавить следующую папку ...
- Нет способа отменить очевидные ошибки (проверка в двоичных файлах и т. Д.)
- Нет поддержки переименования, что делает необходимый рефакторинг еще более болезненным.
Я какое-то время пользовался Mercurial в частном порядке и хотел бы распространить его на всех разработчиков.
Возможно, я все понял неправильно, но есть несколько вещей, которые я не понимаю, как реализовать в нашей организации.
CVS-коммиты - это только текущая папка, но в Mercurial они охватывают весь репозиторий.
В нашем случае это означает, что выполнение работ по техническому обслуживанию в одной папке также приведет к тому, что еще незаконченные вещи будут сохранены в другой папке.
(Я предполагаю, что мы можем сделать hg ci ./** в измененных папках, но это не допускается при слиянии, по крайней мере, так сказано в документации If you are committing the result of a merge, do not provide any filenames or -I/-X filters.)
Обычной практикой в Mercurial является наличие одного хранилища на проект.
Один репозиторий на проект - это нормально для нас, но это создает некоторые другие проблемы, такие как:
Как управлять несколькими репозиториями на центральном сервере?
Если разработчик создает новый проект, он в конечном итоге должен продвигать свои изменения.
Просто делаю
hg push <a href="http://localhost:8000/Customer1/NewProject" rel="nofollow">http://localhost:8000/Customer1/NewProject</a>
аварийно завершает работу hg-веб-сервера с отвратительным дампом стека и приводит к зависанию клиента.
Насколько я понимаю, разработчику необходим доступ к оболочке сервера, чтобы добавить новый репозиторий в файл конфигурации и перезапустить hgweb
Альтернатива - использовать SSH или общий ресурс
(есть ли преимущества использования SSH вместо общего файлового ресурса?)
cd Customer\NewProject
hg init
hg clone --noupdate --pull . //mercurialshare\Customer\Project
echo "[paths]" >.hg\hgrc
echo "default=//mercurialshare\Customer\Project" >>.hg\hgrc
hg push
Работает, но немного сложно для некоторых разработчиков
Всем разработчикам необходимо иметь все проекты.
(Не все, но многие проекты связаны между собой, поэтому они должны присутствовать, и проще всего иметь все)
Поскольку многие существующие проекты и новые добавляются еженедельно, нам нужен способ собрать все проекты за один раз, а также клонировать новые.
Я думал, что subrepos может решить "глобальную" тягу, но следующее
строка в документации это showtopper
"Когда мы фиксируем, Mercurial попытается создать непротиворечивый снимок состояния всего проекта и его подпунктов.
Он делает это, сначала пытаясь выполнить фиксацию во всех измененных подпунктах, а затем записывая состояние всех подпунктов. "
Возвращаемся к проблеме единого хранилища глобальных коммитов.
(пробовал несколько вариантов hg ci .hgsub .hgsubstate <subrepo>, но .hgsubstate, похоже, обновляется только при полной фиксации. Другие пользователи не увидят изменения проекта без явного hg pull --update в папке проекта)
В настоящее время я думаю, что в корне должен быть пакетный файл, который извлекает все проекты
Есть еще какие-нибудь идеи о том, как использовать ртуть в нашей организации?
Редактировать
Спасибо за ответ. В настоящее время я оцениваю, как один репозиторий на проект будет работать для нас. Я поставил командный файл на верхнем уровне
FOR /F %%x IN (repolist.txt) DO (
If EXIST .\%%x\.hg (
ECHO Pull %%x
hg pull --update --repository .\%%x
) ELSE (
ECHO Clone %%x
mkdir .\%%x
hg clone --pull %1\%%x .\%%x
)
)