Миграция с CVS (NT) на Subversion: что эквивалентно (виртуальным) модулям? - PullRequest
1 голос
/ 05 августа 2009

В настоящее время мы рассматриваем возможность перехода от CVSNT, очень вероятно к Subversion (потому что мы уже используем trac, который хорошо подготовлен для интеграции SVN). Поскольку мы довольно широко использовали некоторые менее распространенные CVS (NT) -функции, пара вопросов возникла очень рано. Это только первый из них.

Вот сценарий: (Для нетерпеливых: мой настоящий вопрос находится в самом низу этого поста ниже горизонтальной линейки.)

Все наши "проекты" имеют общий код. Иерархия каталогов внутри хранилища CVS выглядит примерно так ( упрощенно - надеюсь, не слишком сильно ):

  • Libs
    • Lib1
    • Lib2
  • Внешний
    • ExtLib1
      • Docs
      • Источник
    • ExtLib2
      • Docs
      • Источник
  • ProjectA
  • ProjectB

... где ProjectA может, например, зависеть от Lib1, Lib2, ExtLib1 и ExtLib2, а ProjectB зависит от Lib1 и ExtLib1 (на самом деле это может быть потому, что сама Lib1 зависит от ExtLib1). Мы смоделировали это с помощью файла CVSROOT/modules следующим образом:

ExtLib1Full -d Lib/ExtLib1Full    External/ExtLib1
ExtLib1Src  -d Lib/ExtLib1/Source External/ExtLib1/Source
ExtLib2Full -d Lib/ExtLib2Full    External/ExtLib2
ExtLib2Src  -d Lib/ExtLib2/Source External/ExtLib2/Source

Lib1        -d Lib/Lib1           Libs/Lib1
Lib1_WDeps  -a ExtLib1Src Lib1
Lib2        -d Lib/Lib2           Libs/Lib2
Lib2_WDeps  -a Lib2

ProjectAMain -a ProjectA
ProjectALibs -a Lib1_WDeps Lib2_WDeps ExtLib2
ProjectAFull -a ProjectAMain ProjectALibs

ProjectALibs_OursOnly -a Lib1 Lib2
ProjectAFull_OursOnly -a ProjectAMain ProjectALibs_OursOnly

ProjectBMain -a ProjectB
ProjectBLibs -a Lib1_WDeps
ProjectBFull -a ProjectBMain ProjectBLibs

ProjectBLibs_OursOnly -a Lib1
ProjectBFull_OursOnly -a ProjectBMain ProjectBLibs_OursOnly

Для сборки ProjectA серверу сборки теперь просто нужно проверить виртуальный модуль с именем "ProjectAFull", чтобы получить все взаимозависимые модули, необходимые для этой конкретной сборки, - и даже создать структуру каталогов, предпочитаемую компилятором (то есть внешние и обе внутренние библиотеки находятся под общей родительской папкой "Lib"). Точно так же, когда мы хотим пометить релиз, включающий все зависимости, мы просто использовали бы cvs rtag -rTagName ProjectAFull. При создании ChangeLog мы использовали бы вывод cvs rlog ProjectAFull_OursOnly, чтобы не допустить загрязнения ChangeLog сообщениями о фиксации из внешних библиотек (которые мы поддерживаем с помощью cvs import и веток поставщика).


Есть ли эквивалент этих виртуальных модулей в SVN? Как мне настроить структуру каталогов внутри нового хранилища SVN, чтобы приспособиться к этому? Должен ли каждый проект и библиотека стать собственным проектом SVN (т. Е. Со своим собственным набором папок «ствол», «теги» и «ветки») или я должен просто импортировать существующую структуру каталогов как есть? Как определить зависимости?
Я бы очень предпочел продолжать иметь возможность выполнять одношаговые операции с тегами / извлечениями / журналами, которые влияют только на соответствующие модули.

Ответы [ 3 ]

4 голосов
/ 05 августа 2009

Вам следует взглянуть на SVN Externals , но учтите, что я не уверен, что понимаю, что вы делаете с CVS, поскольку я не использовал CVS годами.

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

В принципе, вы можете получить этот макет:

ProjectA      - svn://server/ProjectA
  classes      (svn://server/ProjectA/classes)
  app          (svn://server/ProjectA/app)
  externals    (svn://server/ProjectA/externals)
    Ext1      - svn://server/Ext1
      classes  (svn://server/Ext1/classes)
    Ext2      - svn://server/Ext2

Пояснение: - svn: // ... - это URL-адрес, который я извлек, (svn: // ...) - это относительный URL-адрес этого каталога, но он был частью извлечения из каталога исходного проекта.

Обратите внимание, что внешние ссылки добавляются в качестве свойств в каталог "externals" и фиксируются в репозитории как часть ProjectA. После того, как вы добавили эти свойства, обновление или новая проверка автоматически загрузят и Ext1, и Ext2 как часть обычной проверки.

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

Другими словами, если для добавления функции в проект вы изменяете некоторые файлы в ProjectA / classes, а затем добавляете некоторую поддержку фреймворка для Ext1 / classes, вам придется выполнить два коммита, один для Ext1 и один для ProjectA.


Если вы хотите живой пример, вот подкаталог моей библиотеки классов C #: http://vkarlsen.serveftp.com:81/LVK/LVK_3_5/trunk/LVK.UnitTests

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

Внешние ссылки в моем проекте модульного тестирования библиотеки классов включают в себя как каталог "SigningKey" (проверьте свойства subversion в главном каталоге), так и содержимое подкаталога "libs" (проверьте свойства subversion на библиотеках libs). Как вы заметили, когда вы проверяли проект модульного тестирования, он собирал все остальное, что ему было нужно, из библиотек, ну, кроме проектов, которые он тестировал.

Однако, если я сейчас добавлю модульный тест и одновременно обновлю версию файлов библиотеки SQLite, мне нужно будет сделать 2 коммита. Один для загрузки новых файлов SQLite в хранилище, потому что это отдельная проектная / рабочая папка, а второй для загрузки нового модульного теста в хранилище.

2 голосов
/ 05 августа 2009

Вы смотрели на SVN externals еще? Кажется, это то, что вы ищете.

0 голосов
/ 05 августа 2009

Не забудьте также взглянуть на Mercurial или Git , если вы вносите изменения. В конце концов, будущее - DVCS .

РЕДАКТИРОВАТЬ: Существует много невежества в отношении DVCS, о чем свидетельствуют отрицательные голоса по этому комментарию, но я поддерживаю мое предложение, чтобы оно было рассмотрено, потому что вопрос говорит о том, что рассматривается миграция контроля версий и что Subversion является кандидат. Боюсь, мне придется сойти с корабля на этом.

Я понимаю, что многие пользователи svn все еще жалуются на то, что Линус Торвальдс говорит, что это был самый бессмысленный проект за всю историю ( на камеру ), но, за исключением оскорблений, достоинства DVCS были достаточно сильны, чтобы увидеть принятие Mercurial от таких как Mozilla , Google Code и других. Даже авторы проектов Subversion признают , что растет число проектов, которые не могут извлечь выгоду из Subversion по сравнению с DVC.

...