Как должны обрабатываться бинарные артефакты (например, документы) в Mercurial - PullRequest
0 голосов
/ 07 июля 2011

В настоящее время мы в основном пользователи SVN с четко определенным рабочим процессом. Мы используем центральные / зеркальные репозитории, блокировку для предотвращения случайного одновременного редактирования двоичных артефактов, ветвление / слияние определенным образом для кода и т. Д.

Мы использовали hg (и git) в некоторых экспериментах, и они очень хороши. Мы хотели бы более широко использовать их в реальных проектах.

Как, однако, мы должны обрабатывать трудно / невозможно объединить двоичные артефакты, такие как документы из различных инструментов или изображения и т. Д.?

Какой рабочий процесс рекомендуется для того, чтобы пользователи не могли вносить изменения в такие элементы в своих различных репозиториях, а также избегать сложного процесса согласования изменений вручную?

1 Ответ

0 голосов
/ 07 июля 2011

Я думаю, что простое объединение двоичных файлов вообще невозможно, поскольку оно зависит от типа двоичных данных.Поэтому это должно быть сделано вручную в приложении, которое может работать с определенным форматом файла.

В целом, чтобы пользователи не могли вносить изменения в некоторые элементы одновременно, вам необходимо реализовать блокировку.механизм.Правильная блокировка может быть выполнена только в том случае, если все клиенты знают, что что-то заблокировано (например, связавшись с центральным сервером или передав вопрос, заблокировано оно или нет).На данный момент у меня нет никакой полезной идеи о том, как это сделать без написания специализированного программного обеспечения (которое запускается действиями или постоянно выполняющимся фоновым процессом или чем-то в этом роде).

В случае, если двоичные файлы являются только скомпилированнымиВывод некоторого другого исходного кода, вы также можете добавить их в .hgignore и не иметь дело с ними в хранилище.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...