TFS: cree un nuevo proyecto a partir de uno existente en TFS

Question

¿Cuál es la mejor manera de crear un proyecto completamente nuevo en TFS copiando uno existente?

Tengo un proyecto ASP.NET que tendrá más de 50 "versiones" por año. Cada versión es una entidad distinta que necesita permanecer independiente de todas las demás. Una vez creado, quiero asegurarme de que cualquier cambio en uno (el proyecto fuente o la copia) no afecte al otro.

Esto es solo para control de fuente. No necesito copiar ningún elemento de trabajo.

En el mundo anterior a TFS, haría esto simplemente copiando la carpeta que contenía todos los archivos del proyecto. Esto me dio el 90% del camino a la nueva aplicación, que luego podría adaptar para la nueva versión. Es muy raro que necesite agregar funcionalidad a la aplicación base, e incluso cuando lo hago nunca afecta las aplicaciones existentes. ¿Todavía es posible usar TFS, copiando mis carpetas locales y luego agregando la copia en TFS como un nuevo proyecto?

¿Alguna sugerencia? Una rama por lanzamiento se ve como la forma "estándar" de hacer esto, pero rápidamente terminaré con docenas de ramas que realmente no están relacionadas, y prefiero mantener cada proyecto nuevo como proyecto propio, sin posibilidad de cambios en uno que afecta al otro.

Gracias!

• Gracias por las respuestas. Creo que todos me han dado suficiente información para comenzar. Richard, gracias por los detalles. Estaba un poco preocupado de que podría ser demasiado fácil fusionar accidentalmente las ramas.

Answer 1

en realidad, hay dos preguntas aquí:

1) ¿Es mejor copiar/pegar o ramificar?

Me atrevo a decir que copiar/pegar nunca es apropiado. A menos que tenga mucho cuidado (como mínimo, ejecute 'tfpt treeclean' inmediatamente antes de copiar), es probable que termine revisando algunos archivos inapropiados en la nueva ubicación. Además, utilizará mucho más espacio en disco en el servidor, ya que debe almacenar más de 50 copias en lugar de solo diffs.

No existe prácticamente ningún peligro de que las ramas se vuelvan "accidentalmente" por la línea. La fusión de las ramas de nuevo implica al menos 3 pasos deliberados: colgar la fusión (en sí mismo un asistente de 4 páginas), luego resolver todos los conflictos y luego registrarse.

Tampoco es probable que te confundas en cuanto a tu lugar en el árbol. TFS usa la ramificación de "espacio de ruta". Eso significa que las sucursales aparecen para el usuario como ubicaciones físicas separadas en el árbol fuente, en lugar de simples etiquetas de versión en la parte superior de la misma ruta.Dado que las sucursales se parecen a las carpetas, puede hacer todas las operaciones de carpetas normales en ellas: Capa (no las descargue en su área de trabajo local), Permiso (en particular, eliminar el permiso de Lectura de alguien garantizará que ni siquiera lo puedan ver), Eliminar o Destruir (cuando hayas terminado con ellos).

2) ¿Cuándo es apropiado crear un nuevo proyecto de equipo?

Este es un tema más complejo en general. Official guidance. My opinion.

Sin embargo, diría que su caso es fácil: no lo haga. Los proyectos de equipo tienen muchos gastos generales. Hay un finite number you can create on a server ... alguna vez. No se olvide de otras formas de sobrecarga, como el tiempo que demora el administrador del proyecto en realizar todos los ajustes, y el tiempo que cada desarrollador de su equipo pasa volviendo a conectar su Team Explorer.

¿Por qué? Los enlaces de arriba entran en gran detalle sobre las formas de subestructura que se pueden crear dentro de un solo proyecto de equipo. En resumen, casi todo es posible. Las únicas áreas que faltan son las Consultas de equipo y las Definiciones de compilación, que están restringidas a una sola carpeta de contenedor, y algunas configuraciones como Exclusive Checkout que son todo o nada. A menos que tenga un equipo muy grande o muy diverso, es poco probable que los beneficios de los proyectos de equipo por lanzamiento sean mayores que los inconvenientes.

Por supuesto, si un "lanzamiento" es un evento importante que señala un cambio en sus prácticas de SCM, esa es otra historia. Nuevo SCM => nueva plantilla de proceso => ​​nuevo proyecto de equipo. Pero dudo que lo haga más de 50 veces al año :)

Answer 2

Recomendaría usar la ramificación. Crea una rama para cada lanzamiento desde la rama principal. Mientras no combines las ramas, seguirán siendo independientes. Los cambios en la sucursal principal solo afectarán a los lanzamientos creados después de los cambios realizados.

Se puede copiar los archivos y crear un nuevo proyecto, pero es posible que encuentre un par de problemas:

• Los proyectos de "recordar" que estaban en TFS, hay un poco de trabajo manual para limpiar los archivos especiales, etc.
• TFS puede ralentizar cuando tiene muchos proyectos, en comparación con un único proyecto con ramas

Answer 3

Esto puede parecer obvio, pero solo debe crear un nuevo proyecto para un "nuevo proyecto". Parece que de lo que estás hablando son versiones diferentes del mismo proyecto.

Si desea mantener bases de código separadas para lanzamientos anteriores, entonces, como han dicho los otros respondedores, la bifurcación del código es su mejor opción. Esto funciona bien cuando desea fusionar las correcciones de errores de su última versión en versiones anteriores también.

Sin embargo, si realmente debe tener nuevos proyectos, aún utiliza la bifurcación de la misma manera.