контроль версий для многих несвязанных файлов

Question

Мне любопытно узнать мнение людей о том, как управлять контролем версий для не связанных функций в Matlab.

У меня достаточно большой набор сценариев общего назначения, каждый из которых более или менее независим от других.Я держал их все в одном каталоге, содержащем один репозиторий в Mercurial.Я начинаю больше сотрудничать, и я бы хотел, чтобы мои соавторы могли изменять файлы, фиксировать, ветвиться и объединять.

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

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

Я открыт для изменения систем контроля версий (хотя мне очень нравится Mercurial).Есть предложения?

Answer 1

Рекомендуется проверять код после каждого исправления ошибки / добавления функции / или чего-либо еще.Учитывая, что ваши файлы действительно являются независимыми «проектами», маловероятно, что ошибка или функция будут охватывать несколько файлов.Вероятно, лучшее, что вы можете сделать, - это рекомендовать своим коллегам в передовой практике вносить изменения только для одного файла одновременно.Объясните, что более высокая дисциплина в отношении регистрации приводит к более управляемому контролю за источниками позже.Надеюсь, вы сможете заставить большинство следовать за практикой, а несколько упрямых просто перестанут принимать свои коммиты.

Answer 2

Это действительно зависит от ваших типичных причин объединения одного изменения, но не другого. Если вы используете его для создания конфигурации программного обеспечения , то есть иногда вы хотите использовать версию 1 файла A и версию 2 файла B, а иногда - наоборот, тогда вы, вероятно, захотите использовать подпункты держать каждый файл. Если это потому, что вы никогда не хотите принять часть изменений соавтора, их необходимо проинструктировать, как сделать свои изменения более связными, и представить их отдельно. Иногда это может быть трудной концепцией для людей, которые либо ранее не использовали управление исходным кодом, либо привыкли к управлению исходным кодом, таким как svn, который практически не имеет внутренней концепции набора изменений.

Answer 3

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

Answer 4

Это зависит от того, хотите ли вы сохранить единственную «основную» версию файлов, объединяя изменения, которые вам нравятся, и игнорируя другие.Если коллаборационисты хотят разрабатывать другие ветки, им, возможно, следует клонировать репозиторий, и тогда вы можете принять наборы изменений, которые вы хотите в мастере.

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