Subversion - общий доступ к общей папке без внешних ссылок

Question

Моя группа SW пытается обновить нашу систему управления версиями из Visual Source Safe, которая больше не поддерживается Microsoft, для Subversion (поскольку наш сайт-партнер уже использует ее). У нас есть много общего кода, который в VSS можно сделать напрямую с внутренними ссылками. Они должны быть перемещены в общие папки для использования нескольких проектов. Хотя внешние средства могут использоваться для их внедрения, они несколько рискованны и не являются естественным образом интегрированы в архитектуру SVN (хотя мы все еще намерены использовать их для стороннего кода и других вещей, которые не меняются). Во всяком случае, мы придумали решение, которое я не видел нигде, но все мы думаем, что это имеет смысл, поэтому я хотел посмотреть, что думают другие, и если есть подводные камни (на самом деле они еще не пробовали его жить).

Так что я называю это «Общие внутренние» папки, чтобы контрастировать с внешними. Предположим, у меня есть каталог Common_Code в моем корне репозитория, содержащий общие файлы библиотеки для данного языка (в данном случае C++). Теперь я создаю MyProject с помощью соединительных линий/ветвей/тегов и хочу поместить общую папку в подкаталог моего проекта. Поэтому я создаю нормальную ветвь subversion, которая отделяется от Common_Code до MyProject/trunk/Common_Code. Так что различные члены команды работают над MyProject, отрываясь от ствола. Филиал Боба может выглядеть так: MyProject/branch/Bob_Working и вложенная папка будут входить в MyProject/branch/Bob_Working/Common_Code. Это фактически ветвь ветки общей папки.

Когда Боб закончен, он снова сливается с багажником. Это продолжается, не мешая никакому другому проекту, который мог бы также создать «внутреннюю ветвь» из корневой общей папки. В конечном итоге мы выпускаем наш продукт, но обнаруживаем, что мы внесли некоторые общие изменения в Common_Code, которые принесут пользу другим проектам. Поэтому, после некоторого группового обзора, мы соглашаемся объединить версию нашего проекта Common_Code с корневой версией, из которой было первоначально принято. Это отделяет необходимость обновления общего кода для выпуска из необходимости поделиться изменениями с остальной компанией.

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

Answer 1

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

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

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

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

Практическое следствие этого различия заключается в том, что для внешних сторон вы вынуждены сначала объединять общий код (в режиме фиксации), а затем сливаться во второй ствол проекта. Но другие проекты остались одни, поскольку они привязаны к более ранним версиям. С другой стороны, двойное ветвление позволяет вам сначала объединиться в ваш проект, а затем слить общий код позже (второе слияние). Хотя вы можете сделать это в любом порядке в этом случае.

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