Хорошо, я собираюсь сосредоточиться на части совместного проекта, посвященной вашему вопросу, поскольку я только что пришел с рабочего места, где у нас было несколько проектов и несколько общих проектов в 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 (мой любимый). Это дает вам быструю обратную связь о любых проблемах, прежде чем они попадут под радар и укусят вас сзади.
Хорошо, я сейчас остановлюсь, я не собирался идти на значок «Самый длинный ответ».