Voy a ser responsable de decidir cómo va a suceder el etiquetado de bifurcación en nuestro repositorio de CVS/SVN.Mejores prácticas de CVS/SVN para la ramificación y el etiquetado
¿Hay literatura que me ayude a entender la mejor manera de trabajar con CVS? ya sea ramificación/etiquetado, etc.?
gracias
Mi experiencia personal durante más de 10 años de CVS en el proyecto FreeBSD es: cambiar a otra cosa lo más rápido que pueda. CVS está orientado a archivos no orientado a snapshot/changeset, lo que hace que la fusión entre ramas sea bastante dolorosa. Las ramas son dolorosas con CVS de todos modos.
En cuanto a los recursos para CVS ver CVS Home
Si quieres hablar de SVN, sugeriría la SVN Book sí y esto question.
El Cederqvist es generalmente considerado como la guía a CVS.
Para saber qué hacer, no necesariamente cómo hacerlo. –
reglas de oro: Sensible
Por lo general, necesita publicar versiones lanzadas para que pueda probar y liberar parches. Es posible que tenga otras razones para la bifurcación.
Y definitivamente estás mejor con Subversion.
"Etiquetar cada compilación" debe ser "Etiquetar cada versión"? En el mejor de los casos, cada compilación se compila, pero una etiqueta para cada revisión no tiene mucho sentido. –
Creo que es mejor decir: etiquetar cada compilación pública. Construir que se aleja de los desarrolladores, probadores o usuarios, etc. – abatishchev
No veo la necesidad de ser tacaño, pero si lo vas a hacer, "cada construcción pública" probablemente esté bien. Si algo sale mal de una compilación a la siguiente, es más fácil retroceder si hubiera etiquetado la última compilación. –
Te recomiendo SVN en Windows, Git en Linux. No use CVS, es terrible.
SVN Book es lo que necesita primero.
Etiquete cada compilación pública (versión). Branch es un tronco que se copia por alguna razón, p. otra forma de desarrollo. Repositorio de sucursales cada vez que lo necesite :)
Recomiendo leer los dos libros de Pragmatic Programmer en SVN y CVS llamados "Pragmatic Version Control Using CVS" y "Pragmatic Version Control Using Subversion".
Ambos son excelentes recursos llenos de recetas que describen lo que desea hacer en lugar de las descripciones básicas de la tecnología en los libros mencionados anteriormente.
HTH
aplausos,
Rob
Las entradas posteriores en Eric Sink's Source Control HOWTO cubierta de ramificación y fusión.
debe dejar CVS.CVS es viejo y no muy rápido en términos de ramificación/etiquetado (creación/etiqueta de la rama depende linealmente de número de archivos en un proyecto)
Usted debe pensar en su estrategia de ramificación primera: es lo que quieren tener un
Esto depende en gran medida de su filosofía del proyecto y el desarrollo
Si desea utilizar SVN que realmente tiene que pensar en el diseño del repositorio, porque casi todos los softwareprojects son a base de módulo y que debe encontrar una estructura en el que puede etiquetar fácilmente todos los módulos necesarios. SVN con su enfoque basado en carpetas de ramas/etiquetas no es fácil de lograr este requisito.
Dicho esto debe quedar claro, que los diseños multirepository son más difíciles de mantener un sistema de etiquetado estable. Prefiero un enfoque de "etiquetar todo", sin embargo, esta es mi elección personal.
> Dicho esto, debe quedar claro, que los diseños de múltiples depósitos son más difíciles de mantener un sistema de etiquetado estable. Sin saber exactamente lo que quiere decir, me pregunto si esto se puede remediar mediante el uso de svn: externals para juntar el diseño de múltiples repositorios antes del etiquetado. – RjOllos
puede hacer esto utilizando externos, sin embargo las cosas se pondrán feas, si sus subproyectos usan externos. No hay forma de buscar todas las externalidades en todos los proyectos y es PiA mantener las externas en más de un nivel. –
me gustaría recomendar el uso de GIT como el etiquetado/proceso de ramificación es extremadamente fácil de usar. El beneficio de usar SVN (especialmente en Windows) es el número de herramientas GUI y la integración del shell de Windows.
También segundos la recomendación para los libros programador pragmático en SVN.
Creo que este es el horror de codificación:
papel de Chris Birmele de ramas y la mezcla es la mejor introducción que he encontrado para esta tarea esencial de control de origen. Hay docenas de formas de ramificarse, y ninguna forma correcta de hacerlo. Familiarícese con sus opciones para que sepa cuáles son las compensaciones con cada uno.
Si quieres un motor de arranque para el 10 por subversión:
Treat 'tronco' como una historia completa de su desarrollo. Todo lo que se libere debe aparecer en el tronco en algún punto y de alguna forma.
Utilice las ramas de desarrollo (ramas del tronco) en tareas de desarrollo complicadas. Cuando finalice la tarea, utilice la fusión re-integrar para extraer los cambios de la rama al tronco. De esta forma, tiene algunas confirmaciones específicas para el enlace troncal en lugar de muchas confirmaciones relacionadas con la misma tarea. Elimine estas ramas de desarrollo cuando ya no sea necesario. Nombrarlos como 'FeatureX'
utilizar la versión ramas (de nuevo desde el tronco) para gestionar las versiones de marketing que están destinadas a ser liberado a los clientes/desplegado para vivir. Una versión es un subconjunto de las revisiones en el tronco. Para usarlos, bifurcar desde el tronco en una revisión apropiada (puede no ser la cabecera), registrar manualmente las revisiones del tronco como fusionadas en esa rama, combinar cualquier revisión adicional que necesite desde el enlace troncal (solo desde el enlace troncal). No desarrolle directamente en una rama de versión, solo fusione desde el tronco, aunque la fusión puede necesitar trabajo adicional para hacerlo compatible con la versión. Nombre como 'Versión 2.4 '
Cree etiquetas específicas de las ramas de su versión siempre que realice una compilación o revisión que se publique en clientes o se implemente en vivo. Nombre como '2.4.1', '2.4.2', etc.
Al trabajar de esta manera, puede usar el seguimiento de combinación de subversión (versión 1.5 y superior) para ver exactamente qué hay en cada etiqueta en revisión por revisión. Para ello, obtenga una copia de trabajo de su etiqueta o rama de versión y haga 'svn mergeinfo --show-revs fusionadas http://svn/trunk c: \ workingcopy \'
Eso es ideal para auditores, notas de la versión generadas automáticamente, probadores y su propia confianza sobre exactamente lo que está dentro y lo que está fuera. Use una matriz generada automáticamente con esta información para ver de un vistazo qué contienen las diferentes versiones.
Usted dice que todos los cambios deben ir primero a trunk y nunca a convertirse directamente en una rama de versión. Estoy de acuerdo, pero ¿qué hay de corregir errores en una rama de versión, cuyo código ya no está disponible en el tronco (tal vez debido a la limpieza del código o la eliminación de características)? –
Al ir a mi primer SMC real (desde la fuente de seguridad) Hace años, me encontré con el siguiente útiles - en aquel entonces había un papel blanco por forzosamente pienso:
Bueno, en realidad no importa qué sistema de control de fuente utilices, básicamente todos siguen alguna forma de estructura troncal/ramas/etiquetas. Incluso si se trata de un modelo distribuido, los repositorios se configurarán de forma que reflejen eso.
Hay una explicación bastante simple para comenzar here.
Solo utilicé CVS durante un par de años, pero rápidamente formé la misma opinión. Cuando empezamos desde cero, usamos SVN y lo encontramos, aunque no perfecto, aún mucho más preferible. –
El mayor problema que tengo con CVS es que no se garantiza que los commits sean atómicos. Se produce mucha hilaridad. Simplemente use un VCS moderno ... SVN es bastante bueno para la mayoría de los propósitos. – rmeador
Los errores en CVS son "atómicos" en el mismo directorio (debido al bloqueo) pero no en el exterior. Las versiones recientes (1.12) tienen una identificación de confirmación almacenada en el archivo RCS, pero sigue siendo un hack. – Keltia