Как правильно сгенерировать сложную внешнюю структуру с помощью sharpsvn?

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

Структура репозитория состоит из следующего шаблона:

root-|- main -|- branches
     |        |- tags
     |        |- trunk - main - plugins
     |
     |- modules -| - module1 -|- branches
                 |            |- tags
                 |            |- trunk - module1 - plugins - plugin1
                 |            |- modules - ...
                 |
                 | - module2 -|- branches
                 |            |- tags
                 |            |- trunk - module2 - plugins - plugin2
                 |            |- modules - ...

Источником каждого внешнего является папка pluginX. Целью является папка плагинов ствола на уровень ниже (или папка плагинов основного). К сожалению, документации по API почти не существует. Я подозреваю, что мне каким-то образом нужна функция propset, но как указать конкретный целевой каталог и исходные каталоги, нигде не описано, что мне удалось найти, и я не нашел никаких примеров.

Редактировать: каждый модуль можно вытащить отдельно и работать над ним независимо от корневого проекта. Я не могу просто использовать рут для этого. Черт, я даже не могу получить враждебный ответ на этот вопрос!!


c# externals sharpsvn
person Richard Robertson    schedule 15.07.2018    source источник
comment
Является ли pluginX таким же, как модуль1, модуль2?   -  person royalTS    schedule 20.07.2018
comment
Извините, в чем именно проблема? У вас есть куча декларативных утверждений и предположение, что вам нужно установить свойства файла с помощью svn propset, но нет реальной постановки проблемы, кроме неопределенного предложения: как указать на конкретный целевой каталог и исходные каталоги нигде не описано.   -  person gregory    schedule 24.07.2018
comment
создайте папку «сборка» в корневой папке, затем используйте относительный путь для ссылки на проекты в ваших решениях, затем настройте все проекты их выходной папки на «сборку», все выходные папки также являются относительным путем. с этим шаблоном, независимо от того, кто загружает репозиторий, они могут компилировать проекты в одну и ту же папку и отлаживать с той же проблемой configure.dependencies, которая будет полностью решена.   -  person Dongdong    schedule 25.07.2018
comment
@royalTS - если вы посмотрите, есть ряд папок, которые перечислены как plugin1, plugin2, plugin3 и т. д. Я просто обобщил это на pluginX.   -  person Richard Robertson    schedule 26.07.2018
comment
@gregory - проблема определена в заголовке. Вас смутило отсутствие вопросительного знака? Далее следует описание параметров задачи. Они были бы декларативными по своей природе. Я определяю как часть причины, по которой у меня возникают трудности, отсутствие прямой документации для этой части API. Это репозиторий SVN с подрепозиториями, которые мне нужно связать вместе с внешними и независимо извлекать/редактировать. Чтобы помочь вам, я добавил вопросительный знак в заголовок.   -  person Richard Robertson    schedule 26.07.2018
comment
@Dongdong - Вы дали ответ, а также комментарий. Ваш ответ и комментарий игнорируют условие о том, что файловая структура проекта не подлежит изменению. Я не спрашивал, как структурировать проект. Я спрашивал, как настроить внешние SVN, используя определенную библиотеку.   -  person Richard Robertson    schedule 26.07.2018
comment
@RichardRobertson Ваша проблема заключается в том, чтобы сопоставить пути сервера с путями к файлам? Добавление вопросительного знака к заголовку не помогает. В чем собственно проблема?   -  person Git    schedule 26.07.2018
comment
@Git - Нет, проблема не в этом. Чтобы понять этот вопрос, в первую очередь вы должны знать, что такое внешняя Subversion. SharpSVN — это библиотека C# для Subversion. Мне нужно было настроить несколько подрепозиториев, чтобы иметь независимые внешние ресурсы. Мне нужно было знать, какие библиотечные функции использовать и как их использовать для настройки внешних папок по мере необходимости.   -  person Richard Robertson    schedule 26.07.2018
comment
@RichardRobertson Я знаю и то, и другое, но если вы спросите о сложной проблеме X, люди решат, что сложная часть - это проблема, а не X.   -  person Git    schedule 26.07.2018
comment
@RichardRobertson: проблема не определена в названии. Но ваш комментарий, наконец, описывает вашу проблему: мне нужно настроить несколько подрепозиториев, чтобы иметь независимые внешние... Мне нужно было знать, какие библиотечные функции использовать [в SharpSVN]. А теперь вернитесь к своему вопросу — вы где-нибудь видите этот конкретный вопрос? Неа. ...лучшие вопросы дают лучшие ответы.   -  person gregory    schedule 26.07.2018
comment
@gregory - тогда вы переписываете заголовок вопроса. Помните, что у вас ограниченное количество символов, поэтому вам нужно быть ОЧЕНЬ кратким.   -  person Richard Robertson    schedule 30.07.2018

Ответы (2)


arrow_upward
0
arrow_downward

создайте папку build в «корневой» папке и используйте relative path для ссылки на проекты в ваших решениях, затем настройте все проекты их output folder на build\xxx folder, все выходные папки тоже relative path. и в основной программе настройте привязки сборки снова с относительным путем. с этим шаблоном, независимо от того, кто загружает репозиторий, они могут компилировать проекты в одну и ту же корневую папку и выполнять отладку с той же настройкой.

Для очень сложных зависимостей, таких как A=>B=>C=>D, при первом открытии решения A, если B/C/D не скомпилировано и на него не ссылаются, тогда A покажет справочное предупреждение, вам нужно открыть и скомпилируйте B&C&D, тогда A будет работать. но обычно мы должны добавить B/C/D к раствору A, чтобы при первом открытии больше не было ошибки.

Иногда некоторый исходный код открыт не для всех разработчиков, поэтому они могут получить только скомпилированные dll, для этих dll нам нужна другая папка (например, «инструменты»), которая включает все скомпилированные сборки на сервере исходного кода. мы добавляем file references с relative path в наши решения и настраиваем их как "Copy to local"=true

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

person Dongdong    schedule 24.07.2018
comment
Неа. Первая часть вопроса дает понять, что структура файлов/папок абсолютно не подлежит изменению. Кроме того, ваш английский очень плохой, и его почти невозможно читать. Люди не компилируют в одну и ту же корневую папку. В этом проекте не используются библиотеки DLL. Это создает подпроекты более крупного проекта для Unreal Engine 4.X от Epic. Это означает отсутствие привязок сборки. - person Richard Robertson; 26.07.2018

arrow_upward
0
arrow_downward

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

person Richard Robertson    schedule 26.07.2018