Lo primero que debe entender es que el modelo TFS del árbol de versiones es diferente de lo que puede estar acostumbrado. Está en un extremo del espectro. ‡
He usado Subversion durante un par de años y me encanta cómo funciona.Siempre configuré tres carpetas debajo de cada proyecto, Troncal, Etiquetas y Sucursales.
Lo que usted piensa como "etiquetas, ramas y troncos" está representado por carpetas en TFS. Un "tronco" es una carpeta que fue creada por un simple agregado, no como una rama de otra carpeta. Una "rama" es una carpeta que se deriva de (y de ahora en adelante se relaciona con) otra carpeta en otro lugar del sistema a través de las operaciones de fusión de Branch &. TFS no tiene "etiquetas" per se; el análogo más cercano es crear una rama basada en una versión histórica (a través del número de conjunto de cambios o etiqueta). Una vez más, esto se convierte en otra carpeta.
Cuando se trata de administrar su espacio de trabajo local, el concepto de que "todo es una carpeta" es buenas noticias. Si desea crear vistas arbitrariamente complejas en etiquetas/branches/troncos, en el mundo TFS, esa tarea se reduce al simple problema de mapear rutas locales < -> rutas de servidor.
Por supuesto, eso no significa que debería. El espacio en disco es mucho más barato que el ancho de banda de red o los ciclos de CPU del servidor. Lo que es más importante: cuanto más complejas sean sus asignaciones, más probabilidades habrá de que accidentalmente ingrese el archivo equivocado en el lugar equivocado. Mi recomendación habitual es:
- Cree un área de trabajo por rama/etiqueta en la que trabaje activamente.
- En cada espacio de trabajo, cree una sola asignación recursiva en la raíz de la rama.
- Si esto no es posible debido al tamaño de las ramas, evite las capas. No son una buena solución porque no se mantendrán sincronizados con las carpetas agregadas/cambiadas de nombre hechas por otras personas. Es mejor utilizar una asignación de un nivel a la raíz de la sucursal + asignaciones recursivas adicionales a las carpetas que necesita.
- Si esto no es posible porque tiene dependencias de tiempo de compilación no incluidas en la bifurcación, avergüéncese :) Agregue el menor número posible de asignaciones adicionales a bibliotecas comunes.
- Asegúrese de que las rutas relativas sean las mismas dentro de cada rama. (Y si cambian, los cambios en la estructura propagan al mismo paso con los cambios en los archivos MAKE.)
- Crear un espacio de trabajo adicional para lo que llamaré "mantenimiento" tasks.§
Esta estrategia proporciona:
- Zero resource overhead. No es necesario volver a descargar cuando cambia de contexto.
- Bajo costo mental. Para comenzar a trabajar en otra rama, simplemente abra la otra copia de la solución desde el disco. O cambie el menú desplegable del área de trabajo en Source Control Explorer.
- Baja probabilidad de errores. Debido a que las sucursales están confinadas a su propio espacio de trabajo, al hacer clic en Registrar todo nunca se realizarán cambios pendientes en otra rama ... o peor, no se pueden realizar cambios accidentales en la rama "liberar" que estaban destinados a ir en contra de los "inestables". " versión.
Lo que quiero hacer es tener la carpeta "Proyecto/Sitio Web" root en mi disco duro, y ser capaz de tener que apunte al (asignada a) o bien las etiquetas, las ramas o el tronco, dependiendo de lo que estoy haciendo, sin tener que meterme con arreglar referencias de proyectos de Visual Studio.
Esto también es posible. Como se mencionó, solo está intercambiando espacio en disco para ancho de banda/CPU. No es gran cosa si su infraestructura lo admite. Yo personalmente lo encontraría demasiado limitado en términos de desarrollo paralelo, además de una mayor posibilidad de errores, pero es natural que una persona criada en SVN pueda sentir de manera diferente.
Estos son los pasos:
- Crear un espacio de trabajo. Asócielo a la rama/tag/trunk en la que intenta trabajar a continuación.
- Siga todas las otras pautas anteriores.
- Cuando llega el momento de cambiar de rama/etiqueta/troncal, vuelva a abrir el cuadro de diálogo Espacio de trabajo y apunte la misma carpeta local a la nueva ruta del servidor.
- Obtener más reciente.
- A partir de TFS 2008, el cliente le indicará automáticamente que ejecute Get cada vez que realice un cambio como este.
- Comenzando en TFS 2008 SP1, hay una manera aún mejor. Haga clic en "no" en el indicador, luego ejecute para obtener/reasignar. Esto solo descargará las diferencias entre las dos ramas. Esto puede suponer un gran ahorro de ancho de banda/CPU en función del tamaño de la carpeta y qué tan estrechamente relacionados estén. (En realidad se podría tomar más de la CPU del servidor de carpetas que son muy pequeños, muy alejadas, o [supuesto] que no están relacionadas en absoluto, utilizar el buen juicio debiera Siga estrictamente menor ancho de banda, sin embargo..)
‡ En TFS, cuando crea una bifurcación, le aparece al usuario como una nueva jerarquía de carpetas. Dicho de otra forma: cuando mira el repositorio a priori, no hay una manera clara de distinguir los archivos/carpetas "reales" de las sucursales. Y, francamente, no es mucha diferencia. Una "rama" es simplemente otro elemento, uno que tiene> = 1 fragmentos de metadatos del historial de fusión asociados. Un montón de comandos TFS dependen de dichos metadatos, y ciertamente puede consultarlos directamente, pero no aparecerán en un simple tf dir. Mientras tanto, debido a que cada sucursal ocupa una posición única en path space, eso significa que no es más o menos complejo especificar de forma exclusiva una especificación de versión ramificada. $/path; changeset es suficiente, al igual que cualquier otro elemento.
CVS toma el enfoque opuesto. Cuando te ramificas, la ruta no cambia. Lo que ha hecho en su lugar es bifurcar las versiones a lo largo de otra dimensión. Esto hace que los casos simples sean muy fáciles de visualizar: solo hay un árbol. Por supuesto, solo cambiaste la complejidad a otra parte. Cuando quiera especificar de manera única una versión de un artículo, ya no es suficiente conocer una ruta y un número de revisión; también necesitas conocer la sucursal. ¿Y qué pasa si cambia el nombre de un archivo en una rama pero no en otra? En TFS, a nadie le importaría hasta que fuera el momento de fusionar las sucursales; en CVS solo viendo el repositorio plantea el problema. Estoy seguro de que puedes pensar en otras sutilezas, no estoy lo suficientemente familiarizado como para saber cómo maneja cada caso extremo.
La mayoría de los sistemas SCC se encuentran en algún lugar entre estos extremos. Llamemos TFS 2005/2008 el extremo "izquierdo" y CVS el opuesto "derecho".
Subversion se sienta básicamente sobre TFS en el poste "izquierdo".Si bien las implementaciones son muy diferentes, la vista de ramificación del usuario es casi idéntica ahora que finalmente se implementa el seguimiento de fusión. (Uno podría argumentar que antes de la v1.5, estaba incluso un poco más a la izquierda que TFS. Las sucursales eran simplemente copias con optimizaciones de bajo nivel, el usuario no tenía forma de consultar los metadatos relacionales. SourceSafe entra en esta misma categoría, sino incluso más lejos dejado debido a la falta de números de versión del sistema.) Los usuarios que vienen del mundo SVN no deberían tener dificultades una vez que entienden el modelo de espacio de trabajo cliente/servidor y rehacen su terminología. (SVN tiene una gran cantidad de equipaje CVS en sus términos, por ejemplo, la palabra "tag"; en justicia TFS hereda algo de crud verbal de VSS, por ejemplo, el uso generalizado de "checkin/checkout" a pesar de ser edit-merge-commit por defecto).
Perforce está a una muesca a la derecha de TFS. Su modelo subyacente es idéntico. Tienen el concepto adicional de , las especificaciones de rama que cumplen con algunos escenarios de usuario comunes, por ejemplo, saber rápidamente "qué carpetas representan las ramas", accesos directos para especificar las versiones de las versiones ramificadas sin necesidad de la ruta completa, pero es solo sintaxis.
TFS 2010 se encuentra a un par de muescas a la derecha. Al igual que Perforce, han creado una tienda de "objetos de sucursal" que existen independientemente de (pero vuelven a hacer un mapa) del árbol del repositorio. Cada rama también conoce sus relaciones (por ejemplo, padre, hijo, infundado) dentro de una jerarquía de rama definida por el usuario.
Colocaría ClearCase unos 2/3 del camino a la derecha. Los escenarios de ramificación complejos ocurren fundamentalmente en el espacio de versión desde el punto de vista del servidor. Sin embargo, tienen un sistema extremadamente poderoso de "vistas" en capas en la parte superior. Como resultado, la estructura que el usuario realmente ve puede ser manipulada para parecerse al espacio de ruta, o algún híbrido. Un nivel similar de personalización se aplica a sus asignaciones de espacio de trabajo local.
La mayoría de los SCM "empresariales" están a aproximadamente 3/4 del camino a la derecha. (por ejemplo, AccuRev, MKS, StarTeam) Los usuarios pueden normalmente ver el repositorio + árbol de ramificación en una variedad de maneras poderosas, pero no pueden configurar el sistema en sí mismo tan flexiblemente como CC. Esto es probablemente una buena cosa :)
CVS está en el extremo derecho como se describió anteriormente. Lo mismo ocurre con sus antepasados RCS y SCCS.
La clasificación de sistemas distribuidos como Monótono, BitKeeper, y sus derivados está más allá del alcance de esta respuesta :)
§Una pareja nueva operaciones en TFS se puede hacer sin un espacio de trabajo en absoluto:
- Creación de una rama (rama TF/check - 2008 SP1 requiere)
- artículos Destruir (requiere 2008)
Algunos otros requieren asignaciones en un espacio de trabajo, pero no requieren que descargar los archivos:
- Eliminar elementos
- artículos de bloqueo
- Creación de una rama a la antigua usanza (tf rama/noget - disponible desde 2005 betas tempranos)
Un poco más requieren asignaciones parciales y/o descargas parciales:
- Merge solo requiere que se desglose la ruta de destino &.
- El cambio de nombre requiere la asignación de ambas rutas y la descarga del destino.
- Undelete/newname funciona como Cambiar nombre.
Prefiero hacer este tipo de operaciones en su propio espacio de trabajo de "mantenimiento", aislado de mi desarrollo diario. Tener su propio espacio de trabajo también significa que puedo mapear grandes partes del repositorio de una sola vez sin tener que descargarlas. (Por el contrario, en sus áreas de trabajo de "desarrollo", es una buena práctica ejecutar Get sin ningún alcance de ruta restrictivo.) Y como he mencionado algunas veces ahora, mantener el < -> servidor local de asignación amplia & simple significa relativo los caminos permanecen constantes, las referencias no se rompen, los archivos no se comprometen accidentalmente o se envían al lugar equivocado; todos son generalmente más felices.
YMMV.
Sí, la asignación de tfs parece ser un remanente de sourcesafe. No soy un gran admirador, podría ser que todavía no los asimilo, pero me parecen un dolor –
Sí, realmente debilita la herramienta y hace que parezca que es solo SourceSafe con un poco de brillo. Escuché que Microsoft todavía usa un sabor Perforce en la empresa, lo que te dice algo. Perforce las rocas. –
Um, SourceSafe no fue el primer ni el último sistema de control de origen en utilizar la bifurcación de espacio de rutas. En particular, Perforce tiene el mismo modelo. (La compatibilidad y la familiaridad con el sistema de SCC derivado de P4 interno de MS es la razón principal por la que TFS tomó esa ruta). –