Team Foundation Server-Mover Fuente con Historial

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

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

Sin embargo, mientras que este modelo de versionado es muy puro en un sentido teórico, tiene algunas trampas prácticas. Debido a que diferentes elementos pueden ocupar el mismo nombre en diferentes momentos, TFS necesita el nombre completo + versión para identificar de forma única cualquier entrada que se envíe. Normalmente no te das cuenta de esta restricción, pero una vez que hayas renombrado elementos en el sistema, si dices tf [doSomething] / / newname-version:oldversion entonces se confundirá y lanzará un error u operará en un elemento que puede que no hayas pretendido. Tienes que tener cuidado para pasar combinaciones válidas (newname + newversion o oldname + oldversion) para asegurarse de que los comandos se comportan de la manera que desee.

TFS 2010 cambia un poco la historia: es una rama+borrar debajo de las portadas, haciendo que el ItemId cambie. Aun así, los comandos cotidianos como Get e History son "falsos" muy bien; los clientes antiguos son aproximadamente 95% compatibles. La ventaja es que cuando tiene varios renombres en el sistema y las búsquedas de elementos basadas en rutas 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 en las que los usuarios desconocidos a menudo caían, a costa de no ser tan flexibles y no preservar el historial con 100% de precisión (por ejemplo, cuando hay colisiones de nombres durante una fusión de dos ramas).

Volviendo al problema en cuestión...

No es tan simple como decir tf rename {/ProjectA {/ProjectB . Carpetas de nivel superior en el control de origen los árboles están reservados para el Asistente de Creación de Proyectos de Equipo; no puede ejecutar comandos tf estándar 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 bajo Proj/ProjectA]

En cuanto a los gotchas que mencioné, voy a elaborar uno ahora mismo, ya que buscar la vieja historia parece muy importante para ti. Una vez que compruebe el cambio de nombre, tf history history/ProjectA/somefile.cs NO funcionará. Por defecto, los comandos tf asumen version = " latest."Cualquiera de estas alternativas tendrá la historia completa que desea:

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

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

• tf history history/ProjectA/somefile.cs-slotmode . Sólo vea los cambios que ocurrieron antes del movimiento; sin embargo, también verá el historial de cualquier otro elemento que pueda haber vivido en el archivo some/ProjectA/somefile.cs "slot" anterior o posterior al objeto que moviste debajo de B.

(En TFS 2010, "slot mode" es el comportamiento predeterminado; hay una opción-ItemMode para solicitar que su búsqueda se rastree a través del historial como si fuera 2008 en lugar de basarse en la ruta.)

EDITAR - no, la ramificación no es una gran alternativa. Mientras que la ramificación hace deje suficientes metadatos en el sistema para rastrear el historial completo desde y hacia ProjectB, no es terriblemente fácil de usar en 2008. Planee pasar mucho tiempo aprendiendo el comando tf merges (sin equivalente de interfaz de usuario). 2010 mejora drásticamente su capacidad para visualizar los cambios en varias ramas, pero todavía no es la experiencia unificada limpia que obtendría de un cambio de nombre.