Настройка SVN для атомарных коммитов и ограниченного доступа - PullRequest
Новая
       31

Настройка SVN для атомарных коммитов и ограниченного доступа

1 голос
/ 28 сентября 2011

В настоящее время у нас идет обсуждение на работе, и я искал несколько советов по настройке SVN.

Наш шаблон заключается в том, что в SVN проверено множество проектов, некоторые из которых зависят от других.,Например, FooWebServices зависит от FooCommons.

В случае, когда я работаю над функцией, которая требует изменений в FooWebServices и FooCommons, я хочу иметь возможность выполнять атомарный коммит между этими двумя проектами.Если я как-то облажался и коммит не удастся для FooWebServices, то весь шарик воска потерпит неудачу.Таким образом, я не буду портить какие-либо другие разработчики и не буду вынужден возвращать изменения, пока буду отслеживать любую проблему, которая у меня возникла.Сервер CI также, кажется, запутывается довольно часто.

Я могу сделать мелкую проверку корневого каталога (затем FooWebServices и FooCommons под этим) нашего репо и получить это поведение.Тогда я могу получить такое поведение атомарного коммита.

Ситуация сложная в том, что у нас есть подрядчики, также работающие в хранилище.В настоящее время они не могут проверить мелкую копию root, поэтому они не могут получить такое поведение.

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

Возможно ли это?Я слишком усложняю проблему, и атомарные коммиты даже не нужны?

1 Ответ

0 голосов
/ 28 сентября 2011

Я думаю, что это слишком сложно - И в сочетании.

Вы должны не иметь двунаправленные отношения; если вы это сделаете, у вас есть большие проблемы. (На самом деле это всего лишь один проект.)

Следует избегать циклов. Разбейте их с помощью хорошо расположенных интерфейсов.

Лучшим подходом для связанных проектов может быть односторонняя зависимость. Если проект A зависит от B, вы можете работать над проектом B, зафиксировать изменения, а затем создать файл JAR, добавленный в проект A.

Прелесть этого подхода в том, что изменения в A не должны вызывать развертывание B; он может принимать изменения в A, когда он может, продолжая использовать старый JAR, пока не наступит подходящее время для обновления.

...