Subversion с командой разработчиков контрактов

Question

Любые предложения о лучших методах предоставления доступа к Subversion сторонней команде разработчиков.Мы наняли команду для работы над небольшой итерацией проекта, и я не хочу предоставлять им доступ ко всему репозитарию.Мы используем BeanStalk для размещения нашей subversion, поэтому детальное управление доступом вплоть до просто ветки невозможно (я не знаю, является ли ограничение beanstalk здесь или svn в целом).

Вместо создания ветки в моем главном репозитории я создал новый репозиторий и предоставил им доступ к нему только с самым последним снимком кода, который им потребуется.Я думаю, мне придется объединить их изменения вручную в любом случае.

Что бы вы сделали?

Answer 1

Честно говоря, я не знаю много о настройке сервера SVN.Наш SVN-сервер - «Collabnet» - часть названия, это примерно столько, сколько я знаю, - позволяет нам объединять пользователей в группы, а затем назначать разрешения каждой группе на любом уровне детализации.

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

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

Answer 2

Я не собираюсь переворачиваться, но я хотел бы, чтобы хост SVN позволял мне использовать детализированные элементы управления доступом в моем хранилище.

Кроме этого, я бы также исследовал использование svn: externals для подключения репозитория, переданного сторонней команде, и моего основного репозитория. Умная настройка может уменьшить некоторые усилия по объединению.

Answer 3

Хорошее решение доступно - отметьте ответ . Однако может случиться так, что вы не сможете сделать это, поскольку используете внешнего поставщика.

Answer 4

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

Answer 5

Я, вероятно, запустил бы проект в Google Code и сделал бы то же самое, объединив изменения позже, когда они были сделаны.

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