¿Por qué mi ruta de espacio de trabajo TFS se sigue reasignando?

Question

Estamos usando Visual Studio 2008/TFS 2008.

Tenemos un pequeño equipo de desarrolladores y, por alguna razón, periódicamente, cuando cualquiera de nosotros "Recibe lo último", una de nuestras rutas reasigna a una ruta diferente en su propio. Esto hace que "Obtener lo último" comience a eliminar archivos, porque la ruta ha cambiado. Es el mismo camino cada vez que se vuelve a mapear en el camino equivocado.

1. ¿Dónde se almacenan las definiciones del espacio de trabajo?
2. ¿Hay algo que hayamos revisado en TFS que está causando esto?

Answer 1

Las definiciones del espacio de trabajo se almacenan en el servidor.

Si va a la línea de comando y escribe "tf workspace", verá la definición de su área de trabajo.

Answer 2

Esto no es un comportamiento normal, parece que algo va raro. Solo quería comprobar: ¿todo lo que está haciendo es simple obtener del explorador de Control de código fuente correcto? Además, ¿todos ustedes están en máquinas diferentes? (Es decir, no está compartiendo una imagen de PC virtual o cualquier cosa donde varias máquinas tienen el mismo nombre)

Creo que lo verificaría es ir a Archivo, Control de código fuente, Administrar áreas de trabajo y ver sus asignaciones de carpetas de trabajo antes y después del get y ver si algo está cambiando. No debería - si lo hace, podría darnos una pista de lo que está sucediendo.

Answer 3

También puede intentar borrar la memoria caché y volver a asignar espacio de trabajo que:

 
SET AppDataTF=%USERPROFILE%\Local Settings\Application Data\Microsoft\Team Foundation 
SET AppDataVS=%APPDATA%\Microsoft\VisualStudio 
IF EXIST "%AppDataTF%\1.0\Cache" rd /s /q "%AppDataTF%\1.0\Cache" > NUL 
IF EXIST "%AppDataTF%\2.0\Cache" rd /s /q "%AppDataTF%\2.0\Cache" > NUL 
IF EXIST "%AppDataVS%\8.0\Team Explorer" rd /s /q "%AppDataVS%\8.0\Team Explorer" > NUL 
IF EXIST "%AppDataVS%\9.0\Team Explorer" rd /s /q "%AppDataVS%\9.0\Team Explorer" > NUL 

Answer 4

he tenido que esto ocurra cuando llegue al abrir una solución. Si la solución contiene rutas relativas a otros proyectos que no están en su carpeta, que están mapeados de manera diferente en su espacio de trabajo, el GET me dirá que está reasignando para dar cuenta de ello. El problema es que las decisiones que toma son completamente incorrectas.

La única forma de evitarlo era garantizar que todos los desarrolladores usaran la misma estructura que utiliza el control sourcec y havev que representa en cada espacio de trabajo.

Llegar allí fue un dolor. Básicamente, todos tenían que eliminar todas las copias locales de todos los archivos, rehacer el espacio de trabajo, ELEGIR NO PARA 'OBTENER' CUANDO SE CAMBIÓ EL ESPACIO DE TRABAJO, cerrar VS, abrir, OBTENER LO MÁS RECIENTE.

La razón de esto era que si las copias de los proyectos existían localmente, incluso si esos proyectos NO estaban abiertos, el OBTENCIÓN aún sería incorrecto. Esto fue frustrante, porque al verificar las diferencias en los proyectos con los últimos no hubo cambios, pero al abrir la solución que contenía ese proyecto, las referencias dll en ese proyecto cambiarían automáticamente. En ese momento, no hay cambios pendientes en CUALQUIER archivo. Pero después de construir los cambios persistirían y provocarían que el siguiente se desconectara nuevamente ...

Estoy seguro de que todo esto está mal, pero eso es lo que nos sucedió esta semana.

Answer 5

Ok, lo tengo. Aquí está la solución.

Primero instale Visual Studio 2008 SP1. (Supongo que tiene VS 2008 y Team Explorer ya instalados).

Ahora ejecute Visual Studio 2008, Goto Source Control y elimine el espacio de trabajo. Crea un nuevo espacio de trabajo y crea una carpeta de control de origen para la asignación de carpetas locales. Haga clic en Aceptar. Cuando pregunta "Se ha modificado el espacio de trabajo, desea obtener la última", Seleccione NO.

Ahora Cerrar Visual Studio 2008.

Vuelva a abrir Visual Studio 2008 y vaya al control de código fuente y Get Specific (con ambas casillas de verificación marcadas para sobrescribir archivos).

Si usted tiene una solución basada en web asp.net, ahora es el momento para crear grupo de aplicaciones, configurar el sitio web en IIS, establecer la autenticación y la autorización adecuada. De lo contrario, es opcional!

Ahora vaya a la carpeta apropiada en control de fuente y haga doble clic en el archivo de solución. También puede abrir la solución haciendo doble clic en el archivo de la solución en su carpeta local, pero me resulta más fácil abrir la solución desde el control de código fuente.

Realizando el paso anterior, si su sitio web está configurado, Visual Studio 2008 detectará automáticamente su sitio web que había configurado y le pedirá que lo confirme. Haga clic en Aceptar.

Se pondrá en contacto con el servidor de control de fuente para ver si la sincronización es necesaria o no. Si tiene una cantidad de proyectos en su solución, , observará que la barra de progreso de obtención de archivos parpadea rápidamente en su pantalla y su solución se configurará en minutos.

El problema real es de Visual Studio 2008 Service Pack 1. Sin lo cual la correlación TFS se corrompe. SI SP1 está instalado y se sigue la guía anterior, no habrá problema.