Perforce, Visual Studio и ветвление - PullRequest
0 голосов
/ 20 мая 2010

Мы пытаемся внедрить работу в нашем небольшом ИТ-отделе. Мы в основном разрабатываем в .net с использованием visual studio 2008. Мои проекты были организованы следующим образом:

Customer
    Product
        main_line
        version_1
        version_2
Libraries
    Library_Name
        main_line
        version_1

Папки main_line / version содержат файл решения, а также файлы кода для основного проекта в решении. Решение обычно включает в себя один или несколько проектов, содержащихся в иерархии «Библиотеки», и эти библиотечные проекты обычно включаются в несколько решений. На практике это, кажется, работает нормально, пока я применяю управление исходным кодом к отдельным проектам, а не ко всем решениям. Фактически, либо плагин Perforce, либо сама Visual Studio предупреждают меня, если я пытаюсь найти решения для управления исходным кодом, которые используют общие проекты / библиотеки.

Проблемы начинают возникать, когда я пытаюсь разветвлять решения. Поскольку я не являюсь источником, контролирующим все решение, файл .sln не копируется в каталог филиала, что, как я подозреваю, в любом случае будет бесполезным из-за неправильного сопоставления файлов. У меня вопрос: я делаю что-то не так или ветвление визуальных студийных решений всегда так болезненно? Есть ли способ лучше? Perforce, кажется, работает хорошо только для простых решений. Есть ли продукт управления версиями, который лучше работает с visual studio?

Ответы [ 2 ]

2 голосов
/ 21 мая 2010

Я думаю, что Perforce - меньшая часть проблемы.Вы не упоминаете, какие конкретные проблемы возникают при попытке поделиться общими проектами / библиотеками, и ни то, как вы пытаетесь это сделать.

Я предполагаю, что вы хотите использовать стабильные версии библиотек для каждого продуктаверсия?Я бы порекомендовал вам развернуть библиотеку с правильной версией в месте, расположенном по пути депо продукта.В зависимости от характера вашего проекта, вы можете также построить библиотеку в рабочей области продукта и проверить артефакты (например, dll) на предмет простых и воспроизводимых сборок.Пример:

//depot
    /customer
        /product
            /MAIN
                /deps
                    /src
                        /lib1 ... (branched from lib1/REL1 below)
                    /bin
                        /lib1 ... (prebuilt libs)
//depot
    /libs
        /lib1
            /MAIN
            /REL1

Обрабатывать путь "// depot / customer / product / MAIN / deps / src / lib1 / ..." только для чтения.Сделать это по соглашению - самый простой способ, но вы могли бы настроить отображение защиты в Perforce, чтобы обеспечить это.Не делайте этого, если вы действительно не уверены, что вам это нужно, поскольку вы будете добавлять сложность.

Как только вы это сделаете, вы можете легко добавить файл решения для всего продукта в Perforce.(Для решения не требуется для ссылки на библиотеку «напрямую», поскольку вы не будете над ней работать в контексте продукта.)

В зависимости от характера и состава вашейпродукт, который вы, вероятно, вместо этого захотите использовать «subolutions» для различных частей продукта (exes, libs, installers), чтобы несколько упростить одновременную работу с различными частями продукта.Perforce обладает отличными возможностями слияния, но я предпочитаю избегать слияния файлов решений / проектов.

Когда вы захотите выпустить новую версию «продукта», разветвите все под MAIN, например, REL1 (включаячасть зависимостей).Если для новой версии продукта требуется обновленная версия библиотеки, вы можете просто «p4 удалить» соответствующий материал в пути депо продукта и развернуть / интегрировать правильную версию, как описано выше.

ПРИМЕЧАНИЕ. Это должно быть возможнопросто выполнить интеграцию из новой версии библиотеки, например, в расположение продукта deps / libs / src / lib1 /, поскольку у них есть общие предки.Хотя я не уверен на 100% в этом, поэтому я бы порекомендовал начать с нового подхода p4 для удаления / интеграции.

ПРИМЕЧАНИЕ 2. Пути внутри файлов решения и проекта, как правило, относятся к файлу решения / проектасамо по себе, так что ветвление должно работать просто отлично в этом отношении.Только не добавляйте ссылки на другие файлы / каталоги, используя абсолютные пути самостоятельно.

0 голосов
/ 08 июня 2010

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

Customer
    Product
        main_line
           sln_file
           src
              code
    Library_Name
        main_line
           src

Это позволило мне сделать все ссылки на проекты в относительном файле sln_file. Затем я добавляю код в папку src в депо через плагин visual studio. Я добавляю проекты индивидуально, а не все решение. Единственная проблема заключается в том, что мне нужно напрямую управлять файлом sln через p4v, но так как он все равно не так часто меняет, это на самом деле не проблема. Теперь, когда я разветвляю main_line, я получаю копию файла .sln с относительными ссылками, и все работает как положено.

...