Как мне отразить структуру каталога репо SVN в моем рабочем каталоге без полной проверки root?

Question

Сначала пара рабочих параметров:

• .NET разработка с использованием Visual Studio 2005/2008
• клиент TortoiseSVN

В основном я работал только с системами контроля версий Visual Source Safe и SourceGear Vault. В каждом я сопоставляю корень хранилища с локальным рабочим каталогом. Например:

$/  -->  C:\source

Пока существует локальный каталог, у меня настроена «рабочая копия» (svn) или «рабочая папка» (VSS).

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

Когда я захожу в любой дочерний каталог в репозитории и «получаю последние» (то есть извлечение svn), клиент автоматически создает для меня полную иерархию каталогов, отражая структуру на моем локальном диске. Таким образом, когда я получаю самое последнее из

$/foo/bar/project1

создается на диске в

C:\source\foo\bar\project1

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

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

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

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

Answer 1

Операция "извлечения" из Subversion создает новую рабочую копию. Что вы, вероятно, хотите сделать, это проверить весь ваш проект (который автоматически создает правильную структуру каталогов в том виде, в каком он находится в хранилище), а затем использовать операцию «обновления» Subversion. Обновление обновит все в указанном каталоге и в подкаталогах.

Возможно, это связано с различием в терминологии между VSS и Subversion. Subversion Book стоит прочитать, особенно главу Основное использование .

Обновление: я полагаю, я не совсем понимаю, каков ваш ожидаемый вариант использования. Похоже, одна из новых функций Subversion 1.5, которая может вам понадобиться, - разреженные проверки . Это позволяет вам выборочно получить часть репозитория, не обязательно получая все целиком. Он достаточно гибок в опциях, которые дает вам возможность управлять тем, сколько вам нужно получить.

Поскольку разреженные проверки относительно новы, я не думаю, что книга SVN была обновлена ​​с целью включения информации об этой функции. Она была обновлена, см. Комментарии.

Обновление 2: Похоже, вы можете создать то, что вы хотите, проверив верхний уровень вашего хранилища в c: \ source с опцией --depth = empty. Затем для каждого подкаталога, который вы хотите, обновите этот подкаталог с помощью --depth = empty или --depth = infinity, в зависимости от ситуации.

Я полагаю, что все это основано на цели разработки Subversion, состоящей в том, чтобы иметь возможность иметь несколько независимых исходных деревьев в вашей системе одновременно. В VSS $ / настроен глобально для обращения к определенному каталогу (c: \ source), так что вы можете иметь только одну проверку (без необходимости возиться с глобальной конфигурацией при каждом переключении).

Answer 2

Чтобы ответить на ваш жирный печатный вопрос вкратце: НЕТ нет способа создать все папки выше местоположения вашего проекта

Причина этого немного длиннее:

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

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

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

Однако, если вам удобнее использовать старый рабочий процесс на основе VSS, вы можете оформить заказ с помощью параметра --sparse-checkout и заново создать структуру вручную или написать простой пакетный файл, выполнив это. Я не вижу в этом никакого преимущества, и вы наверняка забудете это сделать, если продолжите работу с SVN и забудете старый ржавый VSS-рабочий процесс

Answer 3

Кажется, я нашел подходящее решение для моей проблемы.

Используя TortoiseSVN, действие «Обновить элемент до ревизии» в обозревателе хранилища можно использовать для локальной реконструкции структуры папок хранилища по произвольному пути хранилища.

Подробные шаги:

1. Создайте локальную папку, которая будет корневым каталогом рабочей копии самой верхней папки репозитория, для которой вам необходимо поддерживать физическую структуру папок
2. Выполнить поверхностную проверку корня хранилища (для проверки выберите «Глубина проверки» из всего, что нужно , за исключением «Полностью рекурсивный»)
3. Запустить браузер репо из папки с рабочей копией
4. Найдите путь репо, который вы хотите получить
5. Щелкните правой кнопкой мыши нужную папку, выберите «Обновить элемент до ревизии»
6. Оставьте значения по умолчанию для редакции HEAD и глубины обновления «Рабочая копия», нажмите OK

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

Примечания к параметру контекстного меню «Обновить элемент до версии»:

• Этот параметр отображается только для путей к хранилищу, которые еще не существуют в локальной рабочей копии
• Похоже, что для параметра "Глубина обновления" по умолчанию "Рабочая копия" можно получить все содержимое выбранного пути. (Вместо того, чтобы явно выбирать «Полностью рекурсивный».)

Answer 4

1. Сначала просмотрите ваш репозиторий Subversion, используя Repo Browser.
2. Перейдите вниз по иерархии к нужному каталогу; Вы должны получить URL-адрес, показывающий что-то вроде https://subversion:8443/svn/BranchMerge/Branches/TestWeb
3. Щелкните правой кнопкой мыши по этому каталогу в левой панели навигации и выберите «Оформить заказ» ...
4. Скопируйте (в буфер обмена) этот путь к каталогу "BranchMerge / Branches / TestWeb" из URL-адреса текстового поля хранилища.
5. Вставьте это в текстовое поле Каталога Checkout, чтобы смешать и сопоставить с имеющимся у него путем, чтобы он отображал желаемую иерархию для вашего локального диска. "C: \ источник \ BranchMerge / Филиалы / TestWeb"
6. Когда вы нажимаете OK, должно появиться диалоговое окно с просьбой автоматически создать эти отсутствующие каталоги.
7. Согласитесь, конечно.

Answer 5

Хорошо, прежде всего, то, как вы работаете, в конечном итоге вызывает проблемы.

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

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

1. В Repo-браузере создайте новую корневую папку дерева, возможно, «Проекты».
2. В этой папке Projects создайте папку для вашего проекта "MyProject".
3. В этой папке щелкните ее правой кнопкой мыши и отредактируйте свойства, добавьте новое свойство с именем «svn: externals» - оно будет в списке.
4. Используйте это свойство для определения дерева, необходимого для вашего проекта.
5. Оформить заказ http://svnserver/svn/Projects/MyProject и будет извлечено все дерево.
6. Работать как обычно.

Примером свойства svn: externals может быть:

http://mysvn/svn/foo/bar/project1 foo/bar/project1
http://mysvn/svn/bar/foo/project2 bar/foo/project2

Хотя было бы лучше использовать относительные ссылки, как описано в руководстве.

Answer 6

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

Корень проблемы кроется в зависимостях проекта. У меня много приложений, которые имеют много зависимостей. Из-за иерархической структуры проектов .NET ожидается, что зависимости будут находиться в определенных физических местах. Итак, если я собираюсь начать работу над этим проектом:

http://mysvn/svn/foo/bar/project1

этот проект войдет в

C:\source\foo\bar\project1

Теперь этот проект зависит от другого проекта. В файле проекта .NET ссылка на проект имеет относительную «обратную ссылку»:

..\..\..\bar\foo\project2

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

C:\source\bar\foo\project2

Таким образом, структура родительского каталога является критической.

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

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

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

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

Answer 7

ankhsvn (с открытым исходным кодом) и VisualSVN (коммерческий) - это продукты, интегрированные с Visual Studio, которые могут лучше соответствовать вашей модели разработки.

Answer 8

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

Что вам, вероятно, нужно, это использовать свойство svn: externals. Здесь есть несколько постов, в которых говорится об этом. Вот один из них:

Как заставить SVN обновлять только файлы, но не добавлять новые

Answer 9

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

Извините, если мне не ясно, что я начинаю с чистого, пустого места для рабочей копии.

И я прочитал хорошую часть книги SVN. Тем не менее, он не охватывает такие вопросы.