Pregunta Team Foundation Server: mover origen con historial


Me preguntaba cuál sería el mejor enfoque para mover el código fuente, con historial, de un proyecto de equipo a otro proyecto de equipo. No me preocupan los elementos de trabajo, los informes o los sitios de SharePoint, ya que el sistema del que vamos a restaurar no usa estas funcionalidades. El motivo por el que queremos cambiarnos a un Team Project diferente también está motivado por el hecho de que la implementación original (que se restauró a partir de una copia de seguridad mantenida por un tercero) utilizaba una plantilla de proceso de un tercero que no deseamos utilizar. avanzando. Queremos comenzar a utilizar el seguimiento y la generación de informes de elementos de trabajo una vez completada la migración.

los Plataforma de integración TFS parece ser un escenario probable. Se puede usar para cambiar la plantilla de proceso, de acuerdo con la documentación. Sin embargo, tenía curiosidad de saber si la sintaxis del movimiento tf.exe podría funcionar. Algo como:

tf.exe mueve $ / ProjectA $ / ProjectB

Tengo entendido que este comando funciona de forma muy parecida a una operación de cambio de nombre, mientras que moverse con el elemento de menú contextual "Mover" en el Explorador de control de fuente es más parecido a una operación de eliminar y agregar. Además, ¿la ruta de movimiento de tf.exe asociaría realmente el código de las carpetas con el proyecto de equipo apropiado, suponiendo que $ / ProjectA es la carpeta de control de origen raíz para un proyecto y $ / ProjectB es la carpeta de control de origen raíz para el otro? La clave es poder preservar el historial, si es posible.

¡Cualquier consejo o consejo sería muy apreciado!

Editar - ¿Podría la ramificación de otro proyecto manejar este escenario? De manera similar a como Microsoft discute en el Orientación ramificada ¿documentación? Creo que esta podría ser la respuesta, ya que la historia probablemente se conservaría con la sucursal. Sin embargo, no tengo acceso a una instancia de Team Foundation Server 2008 en este momento para probarlo.


56
2018-02-07 01:56


origen


Respuestas:


Mover y Renombrar son alias. No hay absolutamente ninguna diferencia, en ninguna versión de TFS, desde la línea de comandos o la interfaz de usuario.

Ambos preservan la historia. Al menos en 2005/2008, mantiene el mismo elemento físico en la tabla VersionedItem sin importar qué tan a menudo o cuán drásticamente cambie el nombre y / o la ruta principal. En realidad, no hay forma de obtener un cambio de nombre "falso" (eliminar + agregar) sin mucho trabajo manual de su parte.

Sin embargo, aunque este modelo de control de versiones es muy puro en un sentido teórico, tiene algunos errores prácticos. Debido a que diferentes elementos pueden ocupar el mismo nombre en diferentes momentos, TFS necesita el nombre completo + versión para identificar de manera única cualquier entrada que envíe. Normalmente, no observa esta restricción, pero una vez que ha cambiado el nombre de los elementos en el sistema, si usted dice tf [doSomething] $ / newname -version: versión anterior luego se confundirá y arrojará un error u operará sobre un elemento que quizás no tenía previsto. Debe tener cuidado de pasar combinaciones válidas (newname + newversion o oldname + oldversion) para asegurarse de que los comandos se comporten de la manera que desee.

TFS 2010 cambia algo la historia: es una rama + eliminar debajo de las coberturas, lo que hace que el ítem cambie. Aun así, los comandos cotidianos como Get e History son "falsificados" muy bien; los clientes antiguos son aproximadamente 95% compatibles. La ventaja es que cuando tiene varios renombrados en el sistema y las búsquedas de elementos basados ​​en ruta comienzan a ser ambiguas como se mencionó anteriormente, el servidor simplemente aceptará el nombre que especifique y ejecutará con él. Esto mejora el rendimiento general del sistema y elimina varias trampas con las que los usuarios desconocidos suelen caer, a costa de no ser tan flexibles y no preservar la historia con una precisión del 100% (por ejemplo, cuando hay colisiones de nombres durante una combinación de dos ramas).

Volviendo al problema en cuestión ...

No es tan simple como decir tf renombre $ / projectA $ / projectB. Las carpetas de nivel superior en el árbol de control de fuente están reservadas para el Asistente de creación de proyecto de equipo; no puede ejecutar comandos estándar tf contra ellos. Lo que necesitas es un script como:

Get-TfsChildItem $/ProjectA |
    select -Skip 1 |  # skip the root dir
    foreach {
        tf rename $_.serveritem $_.serveritem.replace("$/ProjectA", "$/ProjectB")
    }

[por supuesto, puedes hacerlo a mano si no hay demasiados niños en $ / ProjectA]

En cuanto a los errores que mencioné, detallaré uno en este momento, ya que buscar la historia anterior parece muy importante para ti. Una vez que registra el cambio de nombre, tf history $ / ProjectA / somefile.cs no trabajará. Por defecto, los comandos tf asumen version = "latest". Cualquiera de estas alternativas tendrá el historial completo que desee:

  • tf history $ / ProjectA / somefile.cs; 1234 donde changeset 1234 era antes del movimiento
  • tf history $ / ProjectB / somefile.cs; 5678 donde el conjunto de cambios 5678 estaba después del movimiento. O simplemente podría omitir la versión.

Una alternativa final para fines de exhaustividad y depuración:

  • tf history $ / ProjectA / somefile.cs -slotmode. Solo verá los cambios que ocurrieron antes del movimiento; sin embargo, también verá el historial de cualquier otro elemento que pueda haber vivido en el "espacio" $ / ProjectA / somefile.cs antes o después del elemento que movió debajo de B.

(En TFS 2010, el "modo de ranura" es el comportamiento predeterminado; hay una opción -ItemMode para solicitar que su búsqueda se rastree a lo largo de la historia como si fuera 2008 en lugar de estar basada en rutas).

EDITAR - no, la ramificación no es una gran alternativa. Si bien la bifurcación deja suficientes metadatos en el sistema para rastrear el historial completo hacia y desde ProjectB, no es terriblemente fácil de usar en 2008. Planifique pasar mucho tiempo aprendiendo tf se fusiona comando (sin equivalente UI). 2010 mejora drásticamente su capacidad para visualizar cambios en múltiples ramas, pero aún no es la experiencia limpia y unificada que obtendría de un Rename.


37
2018-02-07 02:47



La respuesta de Richard está bien escrita y explica bien la situación. Sin embargo, tenía un par más práctico para agregar.

En TFS2010, el comportamiento predeterminado lo hace parecer como mover un archivo hace que pierdas todo el historial antes del movimiento. El comando que es probable que usen mis usuarios (y el que usa, al parecer, la GUI de VS2010) es:

tf history $/ProjectB/somefile.cs

Mis usuarios tienen la intención de obtener todo el historial de somefile.cs, tanto antes como después del movimiento. Quieren "el historial del código que se almacena actualmente en $ / ProjectB / somefile.cs", independientemente del nombre del archivo en cualquier momento. Quizás otras personas lo vean de manera diferente.

El primer problema es que la GUI que aparece para mí en VS2010 usando TFS2010 inicialmente muestra solo la historia desde la mudanza. El elemento menos reciente de la lista es la operación de cambio de nombre. Se puede expandir con una pequeña flecha desplegable sutil. Debajo está la historia de la ubicación anterior. Si no sabe buscar esto, puede parecer que su historia se ha ido.

El segundo problema es que si luego eliminas ProjectA (porque has terminado la migración a ProjectB, por ejemplo), la historia realmente se ha ido. Expandir el menú desplegable en el historial de $ / ProjectB / somefile.cs no genera el historial anterior.


16
2018-02-15 04:06



Otra opción (y creo que más fácil) es importar a Git y luego exportar a TFS utilizando el Git-TF herramientas de línea de comando.

  • Instale Git-TF desde código binario, Choclatey o fuente.

  • Clonar una carpeta TFS:

git tf clone https://myAcc.visualstudio.com/mycollection $/TeamProjectA/Main --deep 

  • Desvincular el Git Repo del servidor TFS al eliminar el .Git/tf carpeta y el .Git/git-tf archivo.

  • Configure el nuevo Git Repo para conectarse a un vacío Carpeta TFS.

git tf configure https://myAcc.visualstudio.com/mycollection $/TeamProjectB/Main --deep

  • No olvides --deep

git tf pull

Debería recibir un mensaje en este momento "git-tf: este es un repositorio recién configurado. No hay nada que recuperar de tfs".

git commit -a -m "merge commit"

git tf checkin --deep 


1
2018-01-30 12:38



Respecto al comando original anterior: -

Get-TfsChildItem $/ProjectA |
select -Skip 1 |  # skip the root dir
foreach {
    tf rename $_.serveritem $_.serveritem.replace("$/ProjectA", "$/ProjectB")
}

Tanto el nombre de origen como el de destino deben estar rodeados por comillas en caso de que haya espacios en el nombre completo del archivo de ruta. Me resultó difícil hacer esto en $ _. ServerItem al rodearlo con escapado "devuelve ese objeto secundario completo y no solo la cadena .serverItem. O si logré obtener la cadena, obtuve retornos de carro no deseados como

"
$ proj / carpeta / archivo
"

Eventualmente obtuve el comando para trabajar con lo siguiente, pero descubrí que la historia aún no se transfiere, ¡lo cual era todo! Así que creo que este comando es el equivalente directo de simplemente hacer clic con el botón derecho del mouse en el explorador de origen y seleccionar cambiar el nombre (o mover).

$tfsServerString = "http://machine:8080/tfs/DefaultCollection"
$tfs = Get-TfsServer $tfsServerString
Get-TfsChildItem -server $tfs "$/Dest Project/MyTestProject" | select -Skip 1 | foreach { $sourceName = $_.serveritem; $targetName = $_.serveritem.replace("$/Dest Project/MyTestProject/", "$/Dest Project/Source/StoreControllers/dSprint/dSprint2/") ; ./tf rename `"$sourceName`" `"$targetName`" /login:myUser }

También tenga en cuenta que requiere el uso del backtick `para escapar '


0
2018-06-02 16:10