Управление исходным кодом: Должно ли локальное исходное дерево зеркально отражать исходное дерево сервера? - PullRequest
3 голосов
/ 21 марта 2009

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

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

\\ TeamServer \ Project \ Релизы \ 2008

На нашей локальной машине этот каталог будет отображаться так:

D: \ 2008_Releases

вместо:

D: \ Project \ Релизы \ 2008

Ответы [ 7 ]

5 голосов
/ 21 марта 2009

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

Кто-то, вероятно, допустил ошибку, когда изначально все настраивал, и это никогда не исправлялось. ИМХО это небольшое раздражение; только один из побочных эффектов не жить в идеальном мире;)

2 голосов
/ 21 марта 2009

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

Лично я понятия не имею, где хранятся исходные деревья на серверах, и мне это не нужно. Я просто запустил cvs co или svn co, чтобы получить копию дерева в моем рабочем каталоге. Пока я запускаю make или ant где-нибудь в дереве исходников, все, что ниже, будет компилироваться.

1 голос
/ 21 марта 2009

Я предпочитаю, чтобы отдельные пары проекта / выпуска в их собственных каталогах были как можно ближе к root. Это ужасная PITA - кликать по дереву каталогов щелчком мыши или без необходимости вводить часть «c: \ project \ Release \ 2008».

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

0 голосов
/ 21 марта 2009

Люди имеют разные мнения о том, как организовать свои жесткие диски, зачем вам применять конкретный макет?

Можно иметь возможность извлекать несколько рабочих копий одного и того же проекта в хранилище - невозможно, если вы настаиваете на использовании одной и той же иерархии.

В одном большом проекте, над которым я работал, буквально тысячи файлов предполагали, что рабочая копия находилась в фиксированном абсолютном жестко заданном пути (\projectname). Чтобы работать с несколькими ветвями проекта, нам пришлось прибегнуть к использованию разных букв дисков (в Windows), что означало, что мы должны были разделить наши жесткие диски на множество разделов (6 или более были общими). Это было очень неудобно.

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

Использование относительных путей дает вам гораздо больше гибкости; однако, если у всех есть корень проекта в одном и том же месте, вы не заметите, если кто-то случайно добавит абсолютный путь куда-либо.

0 голосов
/ 21 марта 2009

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

Мы также используем TFS там, где я работаю. У нас есть общая корневая папка с именем C: \ Source Control, которая является основной папкой, в которой живут все командные проекты. Этот выбор был сделан из-за крайней неприязни всех сторон к тому, что диск будет загроможден различными папками.

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

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

0 голосов
/ 21 марта 2009

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

0 голосов
/ 21 марта 2009

Есть одна причина не делать этого: когда у вас есть доступ к производственной машине. В этом случае я предпочитаю иметь разные пути. Это повышает вероятность того, что я заметил, что мой "rm -rf" находится не в том поле ...

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...