Управление SVN в проекте, который использует абсолютные пути

Question

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

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

Мы храним снимок последнего выпуска в сетевой папке SMB, используем тег и обновляем его вручную? может ли несколько человек одновременно сохранять эту рабочую копию или папка связана только с создателем?

Все наши файлы "проекта" (содержащие манифесты файлов, информацию о сборке и т. Д.) Используют абсолютные пути. Это настоящая боль, если я использую c: \ myproject, а коллега использует c: \ MaiPrjLolKeke. Я слышал различные аргументы против того, чтобы все равно использовать файлы проекта с контролем исходного кода, но затем, если новый файл добавляется Каков наилучший способ сообщить коллегам о необходимости добавления новых файлов?

Answer 1

Настройте файлы сборки для использования относительных путей.

В идеале вы должны иметь возможность извлекать копию из SVN в любое время (и в любую папку), запускать скрипт сборки, запускать автоматические тесты и сразу же начинать работу. Если вы не можете этого сделать, вы делаете что-то не так.

(Да, вам также может понадобиться сначала настроить операционную систему, сервер базы данных, веб-сервер, язык программирования и среду IDE. Но как только глобальная инфраструктура уже существует, вы сможете поразить бег по земле в любое время и из любого места.)

Answer 2

Если у вас есть жестко запрограммированные пути в ваших проектах, то вам нужно стандартизировать один путь, чтобы вы все могли работать вместе. Это может означать, что вам всем нужно перейти на использование «c: \ work» или «C: \ dev», но это небольшая цена за то, чтобы все «просто работало».

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

Если вы можете использовать относительные пути, то вы находитесь в нирване с общим доступом. На самом деле попробуйте это, так как это просто решит все ваши проблемы.

Если у вас есть проблемы с ссылочными файлами, которые должны находиться в определенном каталоге по сравнению с другими вашими проектами (например, общим набором, который находится в каталоге c: \ include), то соедините его с местом, в которое вы его извлекаете, и вы будете в порядке, если вы справитесь с дисциплиной, которая требует управления. Или вы можете использовать svn: externals для проверки общих файлов по жестко заданному пути.

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

Answer 3

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

Для этого вы можете использовать относительные пути или переменные среды.

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

Это обычно используется во многих местах, где я работал, и обычно вы можете указать на сторонние библиотеки. Это также решает проблему наличия нескольких версий некоторого набора файлов на компьютере. Изменяя одну переменную среды (в сценарии сборки или иным образом), вы можете обслуживать определенные цели / сборки.

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

РЕДАКТИРОВАТЬ - как сказал другой плакат (и я повторяю это здесь, чтобы вы не пропустили его) -

Файлы решений и / или проектов в системе контроля версий НЕ являются плохой практикой.

EDIT:

Вот еще одно решение - не уверен, что кто-то еще предлагал это.

создайте сопоставление с другим местом в вашей структуре пути и сделайте его сетевым диском, например, x: \

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

Например, если разработчик А имеет

C: \ развитие \ проекта \ бла Карта X: \ project to c: \ development \ project

и разработчик 2 имеет: C: \ Мои документы \ пользователь \ Visual studio \ etc ..., она отображает X: \ на этот путь.

Viola!

C: \

Answer 4

Мне приходится иметь дело с подобной конфигурацией (файлы проекта в репозитории SVN.) Основная проблема заключается в том, что кто-то "исправит" путь для своей системы, а затем отметит изменения (которые убивают чужой проект или объединение сил (зла).)

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

Другим способом решения проблемы с .classpath является использование UserLibraries для включения всех ваших сторонних библиотек. Это позволяет разработчикам хранить их в любом месте и настраивать отображение в Eclipse.