Как бы вы организовали репозиторий Subversion для собственных программных проектов?

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

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


person minty    schedule 09.09.2008    source источник


Ответы (9)


Настройка репозиториев SVN может быть сложной только в том смысле, как вы их организовываете. Прежде чем мы настроим SVN, я фактически использовал RTFM в интерактивном руководстве по Subversion, в котором обсуждаются организационные методы для репозиториев и о некоторых подводных камнях следует подумать заранее, а именно о том, что нельзя делать после создания репозиториев, если вы решили передумать. Я предлагаю прочитать это руководство перед настройкой.

Для нас, как консультантов, мы занимаемся разработкой программного обеспечения на заказ и собственными силами, а также ведем некоторый документооборот через SVN. В наших интересах было создать по одному репозиторию для каждого клиента и по одному для себя. В каждом репозитории мы создали папки для каждого проекта (программного или другого). Это позволило нам сегментировать безопасный доступ по репозиторию, по клиенту и даже по проектам в репозитории. Если углубиться, для каждого программного проекта мы создали папки «рабочие», «теги» и «ветки». Обычно мы помещаем выпуски в «теги», используя «release_w.x.y.z» в качестве тега для стандарта.

В вашем случае, чтобы синхронизировать sprocs, скрипты и другие связанные документы, вы можете создать папку проекта, затем под этой «рабочей» папкой, затем под этим «кодом» и рядом с ним «скрипты» и т. Д. когда вы помечаете рабочую версию для выпуска, вы в конечном итоге помечаете ее все вместе.

\Repository
   \ProjectX
      \Working
         \Code       
         \Scripts
         \Notes       
      \Tags
      \Branches

Что касается некода, я бы предложил прямую компоновку папок по проекту или типу документа (руководства, политики и т. Д.). Обычно с документами и в зависимости от того, как работает ваша компания, достаточно иметь историю версий / журналы.

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

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

Удачи!

person John Virgolino    schedule 09.09.2008
comment
Обратите внимание, что установленный стандарт для папок верхнего уровня - trunk, branches, tags. Если вы используете working вместо trunk, вы запутаете многие инструменты, которые работают с репозиториями SVN. Я настоятельно не рекомендую это делать. - person sleske; 18.06.2012

Для подрывной деятельности существует также Assembla, которая поставляется с Trac и другие полезные инструменты. Это бесплатно, или вы можете заплатить за учетную запись, если вам нужно больше места или пользователей для каждого проекта.

person marcospereira    schedule 09.09.2008

Вы можете использовать такую ​​службу, как www.unfuddle.com, для создания бесплатного репозитория SVN или GIT.

Мы используем Unfuddle, и это действительно здорово. Есть бесплатная и платная версии (в зависимости от ваших потребностей).

Или, конечно, вы можете создать локальную копию. Для этого в Google можно найти множество руководств: http://www.google.com/search?rlz=1C1GGLS_enUS291&aq=f&sourceid=chrome&ie=UTF-8&q=set+up+svn

person Eric    schedule 09.09.2008

Вероятно, достаточно одного репозитория для ваших проектов. Мне нравится типичный подход, при котором макет индексируется по проектам (см. этот раздел из книги O'Reilly Subversion):

/first-project/trunk
/first-project/branches
/first-project/tags
/another-project/trunk
/another-project/branches
/another-project/tags
/common-stuff/trunk
/common-stuff/branches
/common-stuff/tags

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

Кроме того, для работы внутри компании я предпочитаю FSFS для хранилища данных, а не Berkeley DB. FSFS более устойчива, и скорость оформления заказа не очень важна для небольших команд / проектов. Вы можете сравнить и решайте сами.

Другие стандартные части рецепта включают Trac и минимальный сервер Linux для размещения репозитория в локальной сети.

person David Crow    schedule 09.09.2008

После публикации этого вопроса я поговорил с коллегой, который посоветовал мне прочитать статью:

http://www.codinghorror.com/blog/archives/000968.html

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

person minty    schedule 10.09.2008

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

person Rob Williams    schedule 20.11.2008

В своей компании я использую svn + ssh и аутентификацию на основе ключей. Вы можете сделать это как с клиентами Windows, так и с клиентами Linux. Это действительно легко использовать, когда вы получите свои ключи прямо, поскольку вы используете ключ ssh для входа в систему, а не вводите пароль.

Вот статья о настройке svn + ssh с примечаниями по безопасность. Если вы поймете все это и выполните следующие действия, у вас будет хорошее начало.

В этой статье описывается ряд способов дополнительной защиты ваши логины ssh для учетных записей svn.

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

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

Удачи и наслаждайтесь преимуществами системы контроля версий!

person Mnebuerquo    schedule 09.09.2008

Как указано в это thread, распределенные VCS (git, Mercurial) - лучшая модель, чем централизованные, из-за простоты создания веток, легкости слияния ветвей, отсутствия необходимости настраивать специальный сервер, нет необходимости иметь доступ к сети для работы и некоторые другие преимущества. Если вы будете работать в одиночку, DVCS позволит вам очень легко привлекать людей к вашим проектам, если в этом возникнет необходимость.

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

person Vinko Vrsalovic    schedule 09.09.2008

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

Проекты содержат все отдельные проекты или модули. Релизы содержат теги выпуска, которые включают несколько модулей. Пользователи имеют частные ветки пользователей. Администратор хранит мои сценарии ловушек, сценарии резервного копирования и т. Д.

Теги выпуска полезны, если у вас есть продукт, состоящий из нескольких модулей, которые могут быть разными тегами для определенного выпуска (одно кольцо для их связывания и все такое). Это упрощает условное депонирование источника и разработки для ссылки на то, что составляло выпуск 1 или 2.

person Peter Kahn    schedule 18.09.2008