Рабочие области TFS могут использоваться, не будучи связанным с определенной машиной?
Таким образом, у меня есть ситуация, где у нас есть проект с 10 разработчиками. Каждый разработчик, когда они входят в течение дня, случайным образом выпущен машина для использования для разработки в тот день. Названия машины отличаются, говорят DEV01 - DEV10. В то время, когда они выпущены разработчикам, машины идентичны, и никакие изменения, которые разработчики вносят в течение дня, не сохраняются на машинах (изменения исходного кода хранятся в TFS, не локально). Это, конечно, на самом деле виртуальные машины, но это не действительно относится к точке под рукой.
Проблема состоит в том, что каждое утро, разработчики сталкиваются с 3 проблемами:
1) Машина, что им присваивают, не может быть той же машиной, которой их в последний раз присвоили. Например, DevMan A, возможно, вчера использовал DEV04 и получил DEV06 сегодня. Его определения рабочей области теперь связываются с DEV06; он должен создать новую рабочую область или переместить старую рабочую область в DEV04.
2) Машина, что им присваивают, возможно, вчера использовалась, и некоторые отображения могут конфликтовать. Например, DevMan A мог бы иметь DEV04 сегодня и хотеть создать рабочую область, отображающую папку проекта на "C:\MyProj\Solution". Однако DevMan B вчера имел DEV04, и он использовал ту же папку проекта. TFS теперь жалуется.
3) Это может быть первым разом, когда они находятся на данной машине. Они теперь должны воссоздать для этой машины все свои отображения управления исходным кодом для новой машины.
Все эти вопросы могут быть решены простым способом в зависимости от конкретного случая, но он действительно иссушает некоторую производительность с утра. Мы очень предпочли бы, если определения рабочей области TFS могли бы быть 'ослаблены', такие, что они не включали название машины в определение так или иначе. Запрет этого, если кто-либо знает о решении вышеупомянутых проблем, которые могут работать автоматически, или с ограниченным вмешательством пользователя, которое также было бы идеально.
4 ответа
Во-первых, очевидный ответ - выделить компьютеры пользователям.
Во-вторых ... если вы действительно хотите решить проблему, как указано:
Вы не можете использовать рабочие области, не назначая их определенной машине. Это предположение подразумевается в продукте. Но вы можете обмануть его :)
Предупреждение: Этот рецепт, кажется, работает, но я лично не запускал проект, использующий его.
- Назначьте имя «виртуальной» машины для каждого пользователя, например, UseridVM
- Для каждой виртуальной машины требуется следующая настройка (постоянная или запускаемая по сценарию):
- создать новая переменная среды «User Variable», т.е. _CLUSTER_NETWORK_NAME_ = UseridVM
- Приятно иметь: используйте виртуальный жесткий диск, который выделен для идентификатора пользователя и сопоставлен (или смонтирован с помощью сценария) с «D:», который следует за пользователем из виртуальной машины к ВМ.
Теперь, когда пользователь открывает Visual Studio, рабочее пространство будет использовать указанное значение «UseridVM» в качестве имени компьютера, таким образом, одно и то же рабочее пространство будет найдено на каждом компьютере.
Если у вас нет постоянного виртуального жесткого диска, то каждый пользователь должен обязательно выполнить «настоящее» «Получить последнюю версию» (получить конкретную версию, установить все флажки) в начале дня, потому что рабочая область запоминает, что файлы уже были загружены, и не будет повторно загружать их, если сочтет, что они уже существуют.
Вы можете разместить рабочую область на общем сетевом диске, так что не имеет значения, на какой машине (виртуальной или иной) вошел разработчик. Это отлично работает, но вам также придется настроить некоторые COM вещи один раз, чтобы все было хорошо.
1.) Для каждой рабочей станции, на которой вы собираетесь работать, необходимо определить рабочее пространство (удаленное <=> локальное отображение). Вы можете хранить исходные файлы в сети (не рекомендуется из-за кэширования VS), но локальное рабочее пространство (определение отображения) должно существовать на конкретном ПК для конкретного пользователя.
2.) Создайте отдельные локальные папки для каждого разработчика, чтобы предотвратить беспорядок, когда разные люди работают над одной папкой и получают последние сведения о проверенном коде других. Например:
c:\Projects\DevManA\...
c:\Projects\DevManB\... etc.
3.) Это, вероятно, вызовет много дискуссий, но я рекомендую отобразить корень вашей TFS на вашу локальную рабочую область, например, DevManA отображает:
$/ to C:\Projects\DevManA\
Затем, когда вы проверяете проекты, вы получите структуру:
c:\Projects\DevManA\TFSProject1\..
c:\Projects\DevManA\TFSProject2\..
c:\Projects\DevManA\TFSProject3\..
и т.д.
Это простое и быстрое отображение, которое каждый может сделать за 5 секунд, и вы готовы к работе. Тогда у всех будет одинаковая схема на диске, как в TFS, что также легче "укладывается в голове".
Я не знаю, будет ли это соответствовать требованиям, указанным в вопросе, но вы можете проверить это:
http: // blogs. msdn.com/granth/archive/2009/11/08/tfs2010-public-workspaces.aspx
В TFS 2010 добавлены общедоступные / общие рабочие области, которые могут использоваться несколькими пользователями на одном компьютере.