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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

EDIT - как сказал другой плакат (и я повторяю это здесь, так что вы не пропустите его) -

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

EDIT:

Вот еще одно решение - не уверен, что если кто-то уже предложил.

создать отображение в другое место в вашей структуре пути и сделать его сетевой диск - как X: \

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

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

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

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

Виола!

C: \

Answer 3

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

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

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

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

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

Answer 4

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

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

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