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

Ответ 1

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

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

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

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

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

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

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

Удачи!

Ответ 2

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

Ответ 3

Вы можете использовать службу, например 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

Ответ 4

Возможно, достаточно одного репозитория для ваших проектов. Мне нравится типичный подход, который индексирует макет по проекту (см. этот раздел из 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 для хранилища данных, в отличие от DB Berkeley. FSFS более устойчив, и скорость проверки не сильно беспокоит небольшие команды/проекты. Вы можете сравнить и решить для себя.

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

Ответ 5

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

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

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

Ответ 6

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

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

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

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

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

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

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

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

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