Subversion - общий доступ к папке без внешних
Моя группа SW пытается обновить нашу систему контроля версий с Visual Source Safe, которая больше не поддерживается Microsoft, до Subversion (потому что наш дочерний сайт уже использует ее). У нас много общего кода, который в VSS можно сделать напрямую с помощью внутренних ссылок. Они должны быть перемещены в общие папки для использования несколькими проектами. Хотя внешние элементы могут использоваться для их введения, они несколько рискованны и не могут быть естественным образом интегрированы в архитектуру SVN (хотя мы по-прежнему намереваемся использовать их для стороннего кода и других вещей, которые не меняются). В любом случае, мы придумали решение, которое я нигде не описал, но все мы думаем, что имеет смысл, поэтому я хотел посмотреть, что думают другие, и есть ли подводные камни (на самом деле еще не пробовал его вживую).
Поэтому я называю эту папку "Shared Internal", чтобы контрастировать с внешними. Предположим, у меня в корневом каталоге репозитория есть каталог Common_Code, содержащий файлы общей библиотеки для данного языка (в данном случае C++). Теперь я создаю MyProject со стволом /branch /tags и хочу поместить общую папку в подкаталог моего проекта. Поэтому я создаю нормальную ветку subversion, которая ветвится от Common_Code к MyProject/trunk/Common_Code. Таким образом, различные члены команды работают над MyProject, разветвляясь от ствола. Ветвь Боба может выглядеть так: MyProject/branch /Bob_Working, а подпапка будет ветвиться в MyProject /branch /Bob_Working/Common_Code. Это фактически ветвь ветви общей папки.
Когда Боб закончил, он сливается обратно в багажник. Это продолжается без вмешательства в любой другой проект, который также мог создать "внутреннюю ветвь" из корневой общей папки. Мы в конечном итоге выпускаем наш продукт, но обнаруживаем, что внесли некоторые общие изменения в Common_Code, которые пойдут на пользу другим проектам. Поэтому после некоторой групповой проверки мы согласны объединить версию Common_Code нашего проекта с корневой версией, из которой она была изначально взята. Это устраняет необходимость обновления общего кода для выпуска и необходимость делиться изменениями с остальной частью компании.
Это кажется простым, но гибким способом прямого обмена кодом. Я вижу два возможных ограничения. Во-первых, он не будет работать в репозиториях, и в этом случае необходимо будет использовать внешние. Во-вторых, вы не можете удалить первую ветвь после слияния, поэтому я не думаю, что будет использоваться -reintegrate. Я до сих пор не уверен, будет ли приемлемо обычное слияние или наш клиент Tortoise его поддерживает.
1 ответ
После дальнейших исследований и долгих обсуждений мы решили придерживаться внешнего метода совместного использования кода. Я публикую отчет о заключении, чтобы другие могли извлечь выгоду из обоснований, которые мы смогли определить. Если люди думают, что это принесет пользу другим, пожалуйста, проголосуйте, чтобы это было видно.
Я вернулся и рассмотрел нашу политику в отношении сайтов-партнеров для внешних устройств, а затем попытался выявить основные фундаментальные различия между этими двумя методами. Одна вещь, которую я изначально не осознавал, это то, что они описывают метод обновления внешних устройств, который может быть выполнен без необходимости иметь ствол и ветви на общих папках - что было для меня большим недостатком, который ушел. Различия тогда просто сводились к этим:
Метод Externals позволяет при желании выполнить привязку к ревизии общей папки, но если вы хотите изменить общий код, вам необходимо отменить фиксацию, обновить до последней версии локально, добавить свои собственные изменения и зафиксировать обратно в общую папку. Другими словами, все работают от ствола в общих зонах - но колышки позволяют вам не быть затронутыми, пока вы не захотите внести изменения. Он синхронизирует общее, добавляя уровень разделения между кодом, специфичным для вашего проекта, и общим, который он использует.
Двойная ветвь позволяет вам вносить изменения в общий код локально изолированно, но требует, чтобы вы не забыли объединить его обратно в общую магистраль позже. В некотором смысле он идет другим путем - он обеспечивает постоянную синхронизацию специфического и общего кода проекта для всех времен и ветвей, но добавляет уровень разделения между общей версией проекта и общей версией.
Практическое следствие этого различия состоит в том, что для внешних целей вы вынуждены сначала объединить общий код (при коммите), а затем - во вторую ствол вашего проекта. Но другие проекты остались одни, поскольку они привязаны к более ранним версиям. С другой стороны, двойное ветвление позволяет вам сначала объединиться со стволом проекта, а затем объединить общий код (второе объединение). Хотя вы можете сделать это в любом порядке в этом случае.
Мы выдвинули идею позволить проектам выбирать любой из этих методов, но кто-то справедливо указал на преимущества максимально возможного соблюдения единой политики. Если бы мне пришлось выбирать один, учитывая то, что я знаю сейчас, я бы использовал метод externals, потому что мне кажется, что общий код должен быть принудительным, чтобы он оставался непротиворечивым во всем хранилище. Предоставляя ему такой уровень независимости от конкретных проектов, он заставляет людей задуматься о том, чтобы общий код оставался достаточно универсальным для использования. Если кто-то действительно хочет адаптировать его для использования в проекте, он должен сделать отдельную копию необходимых файлов и сделать это в каталоге проекта. В конце концов, в этом случае нет намерения объединяться с исходным каталогом, поэтому нет необходимости оставлять эту дверь открытой.