? Структурирование системы контроля версий (SVN) для обработки зависимостей - PullRequest
1 голос
/ 13 июня 2009

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

Я недавно решил начать использовать контроль версий. Изучив кучу статей и страниц и опробовав несколько разных, я в итоге остановился на Subversion (хотя он и удваивает размер проекта из-за BASE).


Теперь мне нужен совет по нескольким аспектам, по которым я не могу найти полезную информацию. Сначала я проверяю, что у меня есть базовый процесс использования RCS:

  1. импортировать все мои проекты в репозитории SVN
  2. удалить оригиналы
  3. проверить проект из репозитория
  4. работа над этим
  5. совершить это

Вот и все? Так что насчет новых проектов? Нужно ли создавать новый проект в папке, а затем импортировать его?


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

  X:\Data
      \H
        \3rdParty
          \Graphics
        \Controls
          \ThisControl
          \ThatControl
        \Libraries
        \Classes
          \CFoo
          \CBar
      \VC
        \Big
          \CoolApp
            \res
        \Small
          \CoolerApp
            \res
            \misc
        \Test
          \CFooTest

… и так далее.

У меня есть несколько каталогов заголовков, которые я часто использую (например, 3rdParty \ Graphics , Classes \ CFoo и т. Д.) В пути Include моей IDE. Зависимости уже были проблемными, но теперь с RCS, это еще хуже. Например, CoolApp может включать ThisControl и CFoo . Раньше это было бы не идеально, так как если бы я изменил CFoo во время работы над CoolApp и сломал его, другие приложения, использующие его, например CoolerApp , были бы сломан также.

Причина, по которой я сделал это вместо копирования CFoo et. и др. в CoolApp и других каталогах из-за хлопот, связанных с попытками объединить обновления из каждой копии обратно в основную копию в папке \ H .

Я бы подумал, что при использовании формального RCS такого рода проблемы будут устранены. Однако теперь произошло то, что, когда я импортирую проекты из \ VC \ CoolApp и т. Д. В репозитории SVN, такие компоненты, как CFoo , * Библиотеки \ ** и т. Д. не включайтесь, так как они находятся во внешнем каталоге, и, следовательно, не имеют версий, что наносит ущерб всей сути.

Я ищу советы о том, как справиться с такой ситуацией. Например, если у меня есть CWidget в \ H и WidgetTest (тестовый контейнер, включающий CWidget ) в \ VC , тогда как бы я структурировал вещи так, чтобы WidgetTest и CWidget были версионированы, при этом максимально упрощая его для других приложений, использующих CWidget включить и использовать его последнюю версию?


Кроме того, мне удалось импортировать все свои проекты только в один каталог репозитория, потеряв Большой \ , Маленький \ , Тест \ и т. Д. состав. Я не могу заставить Subversion сохранить это.


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



О, и в настоящее время у меня настроена Subversion с моим сервером Apache, а также установлены VisualSVN, SVNServe и CollabNet SVN Server. Я заставил каждого работать, но хотел бы получить совет, которым можно воспользоваться, поскольку уверен, что мне нужен только один.



Большое спасибо.

Ответы [ 2 ]

2 голосов
/ 13 июня 2009

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

Первое, что я бы посоветовал сделать решающим, - это начать работать со следующей идеей: "Выполнение проверки ствола проекта в любом месте на жестком диске - это все, что требуется для создания решение "

Также помните, что рабочие копии без изменений не имеют значения . Не должно иметь значения, где на диске вы что-то извлекаете, и удаление рабочей копии не должно вызывать у вас панику, так как вы можете просто снова проверить ствол и начать сразу. На своих предыдущих местах я обнаружил, что много заботы уделяется «созданию» среды разработки и получению всего в нужном месте. Это абсурдно, и время, потраченное на это, никогда не возвращается. Сделайте это один раз, сделайте это в приличном контроле исходного кода (например, svn, или git, или TFS) и будьте счастливы, что теперь вы можете работать с рабочими копиями, как вчерашняя газета.

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

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

Это также означает, что наличие определений уровня IDE относительно расположения заголовков / библиотек просто не будет работать. Это была ужасная идея, которую представила Visual Studio, но они также позволяют вам указать этот материал, используя относительные папки в отдельных настройках проекта - где это должно быть. Поверьте мне, если вы используете определения местоположения на уровне IDE, в какой-то момент вы будете собирать свое приложение и пытаться понять, почему ваши изменения не появляются. Тогда вы почувствуете это погружение, когда поймете, что только что создали свои последние 3 релиза для старой, глючной версии библиотеки. По крайней мере, я сделал.

Чтобы добраться до этой утопической ситуации, вам будет намного лучше, если вы будете рассматривать каждый проект и библиотеку (например, CoolApp, CFoo, ThisControl, CWidget) как отдельные проекты с отдельными циклами выпуска, транками и так далее. Двигайтесь к тому, чтобы думать об этих вещах независимо, развивая и выпуская их отдельно.

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

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

/Projects
 /CoolApp
  /trunk
  /branches
  /tags
/Libraries
 /CFoo
  /trunk
  /branches
  /tags
 /CWidget
  /trunk
  /branches
  /tags
 /ThisControl
  /trunk
  /branches
  /tags 
/Vendor
 /NUnit
  /current
  /1.6
  /1.7

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

Теперь зацените только ствол вашего основного проекта (CoolApp). Конечно - это не будет построено как есть, потому что ни один из зависимых проектов не существует. Следующим шагом является добавление других проектов как externals . В папке верхнего уровня вашей рабочей копии, используя tortoisesvn, щелкните правой кнопкой мыши и перейдите в svn-> properties. Добавьте новое свойство с именем "svn: externals". Определите свойства в формате

/repository_location[@revision]    working_copy_folder

Так что для coolapp вы можете добавить следующее определение svn: externals:

/Libraries/CFoo/trunk        CFoo
/Libraries/CWidget/trunk     CWidget
/Libraries/ThisControl/trunk ThisControl

Когда это будет сделано, зафиксируйте изменения, затем выполните «Обновление», и ваши внешние компоненты также будут сбиты.

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

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

Это ситуация по другому принципу: «Любые изменения в проекте ДОЛЖНЫ иметь соответствующую ревизию в стволе основного проекта» Изменение внешнего расположения, чтобы указать на новую версию библиотеки, является идеальным пример того, что я могу сказать: «Привет, я сейчас использую версию 2 foolib здесь». Проблема в предыдущем абзаце заключалась в том, что код изменился «под вами».

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

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

Если вы полагаетесь на какие-либо сторонние инструменты, такие как nAnt или nUnit, - добавьте их в хранилище в качестве веток поставщика и обращайтесь к ним через внешние источники. VS позволяет вам ссылаться на DLL, просматривая их, что является более гибким, чем из GAC. Это может показаться не большой проблемой для одного разработчика, но если вы попытаетесь обновить nUnit по одному проекту за раз, вы увидите, насколько приятнее иметь возможность извлекать ствол из своего проекта и знать, что вы вы получили правильную версию nUnit вместе с ней (вместо того, чтобы потом удалять nUnit и переустанавливать правильную версию).

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

Наконец, как только вы начнете работать, я действительно рекомендую использовать движок сборки, такой как CruiseControl.Net или Hudson (мой любимый). Это дает вам быструю обратную связь о любых проблемах, прежде чем они попадут под радар и укусят вас сзади.

Хорошо, я сейчас остановлюсь, я не собирался идти на значок «Самый длинный ответ».

2 голосов
/ 13 июня 2009

Книга Subversion, бесплатная онлайн, дает несколько предлагаемых конфигураций хранилища:

http://svnbook.red -bean.com /

Эта страница дает хорошие ссылки для дальнейшего чтения:

http://svnbook.red -bean.com / о / 1,5 / svn.tour.importing.html # svn.tour.importing.layout

Одна очень хорошая вещь в SVN, которая не относится к CVS, заключается в том, что перемещение по каталогам довольно тривиально. Так что не испытывайте давления, чтобы придумать «окончательную» организацию прямо на лету. Делай то, что работает, играй со структурой, пока тебе не понравится больше.

Еще одна вещь, о которой стоит упомянуть, SVN использует технику копирования при записи для данных. Поэтому не стесняйтесь делать копии svn cp целых каталогов, когда вам это необходимо.

...