Как бы вы организовали хранилище Subversion для собственных программных проектов? - PullRequest
19 голосов
/ 09 сентября 2008

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

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

Ответы [ 9 ]

19 голосов
/ 09 сентября 2008

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

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

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

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

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

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

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

Удачи!

6 голосов
/ 09 сентября 2008

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

3 голосов
/ 10 сентября 2008

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

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

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

3 голосов
/ 09 сентября 2008

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

/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 для размещения хранилища в локальной сети.

3 голосов
/ 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

2 голосов
/ 20 ноября 2008

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

2 голосов
/ 09 сентября 2008

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

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

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

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

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

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

0 голосов
/ 19 сентября 2008

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

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

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

0 голосов
/ 09 сентября 2008

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

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

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