Продукты контроля версий, которые поддерживают связанные / общие файлы? - PullRequest
4 голосов
/ 11 сентября 2009

Мы заинтересованы в переходе от системы контроля версий , которая поддерживает концепцию общих или связанных файлов.

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

Мы пытаемся выяснить, могут ли какие-либо другие широко используемые системы контроля версий удовлетворить наши потребности, и включают в себя связанные или общие файлы. Мои ограниченные исследования показывают, что:

  • Team Foundation Server не поддерживает обмен файлами
  • Subversion не поддерживает общий доступ к файлам (включая Внешние )
  • CVS не поддерживает общий доступ к файлам (включая Модули )

Что-нибудь еще? (кроме нашего текущего продукта контроля версий, очевидно)

Ссылки

Ответы [ 5 ]

8 голосов
/ 11 сентября 2009

Я использовал Sourcegear's Fortress (все включено ALM - для просто контроля версий, проверяйте их Vault продукт) годами без нареканий, и он поддерживает Sharing. По сути, вы можете ветвить файл из одного проекта в другой, и вторая копия будет обновляться без дополнительных действий.

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

2 голосов
/ 11 сентября 2009

Я не знаю, сколько у вас степеней свободы, чтобы решить эту проблему. Однако, похоже, что более традиционным решением этой проблемы было бы создание библиотеки , которая является внешней по отношению к проектам, которые зависят от нее. Ссылка на библиотеку (сборка, .jar, .so, .pm и т. Д.) В ее «официально опубликованном» месте.

Пусть начнутся "мод даунс", чтобы не отвечать на заданный вопрос, но для меня это звучит как неправильный вопрос .

1 голос
/ 11 сентября 2009

Опираясь на ответ Roboprog: более общее решение вашей проблемы - обновить make-файлы в «общих целях», чтобы они включали элементы из «общего источника» по ссылке, а не полагались на то, что система SCC сделает это для их.

Если общая функциональность может быть легко разложена в библиотеке (сборка, jar, заголовки C ++ + библиотеки), то отлично! Это поможет всем в долгосрочной перспективе. Теперь библиотеку можно тестировать модульно с помощью различных автономных инструментов; потребляя это также становится легче теперь, когда контракты с обеих сторон стандартизированы. Кроме того, теперь вы можете относиться к библиотеке как к первоклассному управлению изменениями WRT. Разрывные изменения могут быть внесены в их собственную ветку; исправления других групп, которые совместно используют код, могут распространяться по хранилищу вместе с остальной частью вашего приложения; и т. д.

Но ничего из этого не является строго необходимым. Даже если вы делаете все в одной ветке, или даже если рассматриваемый общий ресурс представляет собой один файл foo.h, вы можете продолжать использовать существующие методы SCM с помощью всего нескольких настроек. Каждая система сборки, с которой я когда-либо сталкивался, способна включать файл из модуля A в модуль B, если относительный путь верен. Если вы используете * proj make-файлы Visual Studio, самый быстрый способ сделать это - Добавить -> Существующий элемент -> перейти к исходному файлу -> нажать стрелку раскрывающегося списка на кнопке Сохранить -> Добавить как ссылку.

1 голос
/ 11 сентября 2009

Ну, источниксэйф - очевидный, который поддерживает это (он ужасно сломан во всех отношениях, но поддерживает это). Интересно, поддержит ли это хранилище sourcegear, так как предполагается, что это исправленная версия sourcesafe.

0 голосов
/ 11 сентября 2009

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

git - это потрясающая система контроля версий. У них есть подмодули, которые можно использовать для выполнения ваших задач, за исключением того, что сопровождающему каждого хранилища потребуется выполнить одну команду для обновления набора «общих файлов».

Если у вас есть подмодуль REPO/share, то каждый обновляемый репозиторий должен будет:

cd REPO/share; git pull

Вы могли бы на 100% автоматизировать это, используя git hooks, если бы вы действительно этого хотели.

...