Можно ли использовать рабочие пространства TFS без привязки к конкретной машине?

Question

Итак, у меня есть ситуация, когда у нас есть проект с 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 могли быть «расслаблены», так что они не включали имя машины в определение каким-то образом. Если это не так, если кто-то знает о решении вышеупомянутых проблем, которые могут запускаться автоматически или с ограниченным вмешательством пользователя, это также было бы идеальным.

Answer 1

Во-первых, супер-очевидный ответ - посвятить машины пользователям.

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

Вы не можете использовать рабочее пространство, не назначая их к конкретной машине. Это предположение неявно в продукте. Но вы можете обмануть его :)
Предупреждение: Этот рецепт, похоже, работает, но я лично не использовал проект, используя его.

1. Назначить «Виртуальное» имя компьютера для каждого пользователя, т.е. UseridVM
2. Для каждой виртуальной машины следующего (постоянного или запуск сценария) требуется установка:
   • создать новые переменные среды «User Переменная», т.е. _CLUSTER_NETWORK_NAME_ = UseridVM
3. Приятно иметь: использовать виртуальный жесткий диск, который посвящен иД пользователя и отображенный (или смонтированный с помощью сценария) в„D:“, который следует за пользователем из VM на VM ,

Теперь, когда пользователь открывает Visual Studio, рабочая область будет использовать указанное значение «UseridVM» в качестве имени машины, таким образом, одно и то же рабочее пространство будет найдено на каждой машине.

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

Answer 2

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

Answer 3

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, который также «подходит для мозга» более легко.

Answer 4

Я не знаю, если это будет соответствовать требованиям, указанным в вопросе, но вы можете проверить это:

http://blogs.msdn.com/granth/archive/2009/11/08/tfs2010-public-workspaces.aspx

TFS 2010 добавил общественные/общие рабочие области, которые могут использоваться несколькими пользователей на одном компьютере.