Migrar de ClearCase a SVN / Mercurial

En el trabajo, estamos usando ClearCase en este momento. Sin embargo, se requieren muchos gastos generales, especialmente cuando alguien hace algo estúpido (como borrar una vista con múltiples saldos reservados en el maletero …). Como intentamos networkingucir nuestros gastos generales y ser lo más livianos posible, hemos superado la posibilidad de abandonar CC y search algo más ligero (Subversion o Mercurial), ya que no usamos el 90% de las funciones de CC. de todas forms. ¿Suena razonable o vamos a cambiar nuestro Ferrari por una camioneta?

Desde mi experiencia, ClearCase realmente ha tenido muchos gastos generales y logramos un gran manejo con SVN.

Yo voto, "rebajar" (en realidad es una ACTUALIZACIÓN). 😉

Lo más importante que aprendí es que, más importante que el producto es el process .

Si ha implementado ClearCase (CC) utilizando un model tipo SVN, entonces SVN funcionará bien y será mucho más económico.

Por otro lado, si usa las funciones de bifurcación diferida, compilation por label y dinámica (o puede), que utilizamos con gran ventaja para ahorrar time y esfuerzo, y mejorar la confiabilidad, lamentará seriamente perder estas características. (Sin mencionar gestión de compilation, UCM, etc.)

Encuentro que la mayoría de la gente usa la primera opción, que es como usar un Ferrari en el tráfico de hora punta …

¿Ejemplo? Defina las tags GA, SP1, SP2 (puede tener tantas versiones entre GA y SP1 como desee, no es relevante, y recuerde, las tags CC NO son lo mismo que SVN). GA fue su lanzamiento base, SP1 es su versión actual. SP2 es tu próximo lanzamiento. La versión actual se basa en GA y SP1. La próxima versión se basa en GA, SP1 y SP2 (consulte las especificaciones de configuration CC)

Comience QA. El desarrollo está haciendo un trabajo continuo para la "próxima versión", y los usuarios pueden hacer reference (no cambiar) a GA y SP1, y pueden aplicar SP2. El mantenimiento está trabajando para reparar los defectos encontrados por QA y puede hacer reference a GA, y aplicar SP1.

Caso 1: en ClearCase, el simple hecho de aplicar la label SP1 hace que la solución esté automáticamente disponible para el equipo de lanzamiento de Dev SP2. Ningún trabajo. Nada, Zero.

En Subversion, estaría realizando el cambio en una twig de QA, y luego (con suerte, recuerde) migrar el cambio a SP2.

Caso 2: antes de preguntar, sin duda, si agrega un cambio de SP2, tendrá que bifurcar para agregar un cambio posterior para SP1, como lo haría en la mayoría de los sistemas.

En mi mundo, los numbers del mundo real: el Caso 1 ocurrió 122 veces para mi último SP (8 SP por año). Más de 800 cambios por año que no tuve que hacer en ClearCase I habría tenido que hacer si utilicé el model de Subversion.

El caso 2 ha sucedido 6 veces desde principios de 2002 cuando instalamos CC.

Mire el process , no solo el producto .

(Lo siento por la longitud, no comenzó tanto time 🙂

Estoy de acuerdo con los carteles anteriores. El abandono del producto de IBM y el cambio a un producto de control de código fuente abierto no será una degradación en absoluto. Probablemente estarás más feliz con estas herramientas más livianas y fáciles de usar. En nuestra tienda, estamos en el process de pasar de CVS a SVN y estamos bastante satisfechos con el resultado.

¡Definitivamente consideraría un cambio de clearcase a subversion una actualización!

Pasamos de ClearCase LT a SVN y nos encanta. Ahorramos mucho dinero en honorarios de mantenimiento y todo está funcionando igual de bien que antes.

Solo desearía haber investigado a Git o algo así antes de recomendar SVN.

Cuarta recomendación de que cambies. Si no está usando las funciones, es una opción de negocios deficiente ir con la solución de precio comercial.

Ahora, también hay un costo asociado con la solución "gratuita". Ni SVN ni Mercurial van a proporcionarle soporte comercial. Si esto es un problema, y ​​sin duda puede serlo en algunas situaciones, es posible que no desee hacerlo.

De los dos que mencionas, SVN es el que deberías elegir si actualmente estás usando un repository de VC centralizado. No solo el model operativo de SVN es simple e intuitivo, sino que SVN tiene simplemente la mejor comunidad de desarrolladores y documentation que he visto en un proyecto de código abierto. La list de correo de los usuarios es magnífica, los desarrolladores son receptivos y responsables con sus usuarios, y el libro Red Bean es la mejor pieza de escritura manual de código abierto que existe.

No tengo ningún problema con tu "interruptor". Será una actualización si no tienes muchos proyectos interdependientes usando UCM.

Administro tanto SCM (ClearCase como Subversion) y recomiendo Subversion para proyectos independientes pequeños o medianos.

Sin embargo, asegúrese de que sus desarrolladores no estén acostumbrados a las vistas dinámicas de ClearCase: es una encapsulación del sistema de files que permite al usuario acceder a los files de la networking. Que yo sepa, ClearCase es el único con ese tipo de acceso.

Y tome en consideración el cambio de paradigma:

  • ClearCase está centrado en files (cada file que obtienes es de solo lectura y solo compras los files en los que trabajas)
  • Subversion está cinput en el repository (cada file que obtiene es de lectura y escritura, registra todos los files modificados / agregados / eliminados en una confirmación atómica)

Cosas que me gustaron de ClearCase que no he podido hacer tan bien o nada en otras herramientas de SCM:

  1. Trabajar con las twigs de desarrollador no fue doloroso. En CC (UCM), trabajas en tu flujo (también conocido como sucursal) y "entregas" un montón de trabajo a la secuencia de integración. Mientras tanto, otros desarrolladores hacen lo mismo. El integrador (tal vez uno de los desarrolladores) hace algunas testings sobre la secuencia de integración, y se asegura de que todo se desarrolle y tal vez el humo evalúe las cosas, luego recomienda una nueva línea base, que incluye el trabajo de todos los desarrolladores. Mientras tanto, sigues trabajando en tu sucursal. La próxima vez que quiera entregar (o antes, si lo desea), verá que hay una nueva línea de base disponible, por lo que se fusionará con su transmisión. De hecho, se le obliga a volver a establecer la base si hay una línea base más nueva disponible. Intenté hacer esto en Microsoft Team Foundation Server y SVN. Primero, no pude encontrar una forma de aplicar una política como la rebase forzada de CC, así que tuve que ir y averiguar qué revisiones hice desde la última fusión, y qué se hizo en el enlace desde entonces, y luego se fusionan desde el tronco en mi twig. Luego, cuando quise fusionar mi nuevo trabajo en el baúl, tuve que volver a fusionar todas las cosas que acababa de fusionar en mi sucursal, además de mi nuevo trabajo.
  2. Las sucursales de desarrolladores propiciaron revisiones de código efectivas. Cuando estaba usando CC, revisamos todo. Prácticamente, sin embargo, las revisiones tomaron time y tuvimos que seguir trabajando. Cada trabajo correspondía a una actividad en CC. Solo cuando se completó la revisión, entregamos la actividad al flujo de integración. Si la revisión requería cambios, podría decidir realizar el cambio en la actividad en la que hice el trabajo original (siempre que no se hayan realizado cambios posteriores a los files modificados en esa actividad), crear una nueva actividad para abordar los cambios de revisión, o posiblemente soplar toda la actividad y comenzar de nuevo (nuevamente, siempre que no se hayan realizado cambios posteriores). En TFS y SVN, una vez que se compromete algo, no se puede volver fácilmente sin soplar el trabajo posterior. Entonces teníamos que encontrar otra forma de mostrar nuestros cambios a otros desarrolladores. Esto terminó convirtiéndose en páginas web, pero aún así, no pudimos continuar con más trabajo sin que se mezclara con el trabajo pendiente de revisión.
  3. El desarrollo multiplataforma se facilita con vistas dinámicas. Solo tengo SVN para comparar aquí, así que quizás Mercurial u otros sean mejores. Mi objective era realizar cambios, crear, probar y depurar en plataforms Linux y PowerPC (y Windows para otro proyecto) y comprometer un solo set de cambios una vez que me alegré de que funcionara en todas las plataforms. Para las comstackciones de PowerPC, teníamos una estación de trabajo solar (acceso a la vista dinámica) que usamos para build y probar un objective. Fue lento, así que hicimos la mayor parte de nuestra encoding y debugging en Linux, y luego construimos y probamos en el PowerPC antes de la testing final en el objective (PowerPC), y finalmente un check-in. Una forma de evitar esto es compartir files de networking. Un problema que he visto aquí es incompatibilidades de versión entre Linux svn y TortoiseSVN en Windows. Si deja Tortoise en una copy repo de Linux, cambia los files .svn, y svn de Linux se queja de que la versión es demasiado nueva. (No pudimos actualizar nuestras cajas Linux a un svn suficientemente nuevo debido a la plataforma que elegimos para un objective). Por lo tanto, no puedo usar mi herramienta diff de Windows en un repository svn de Linux. Si voy por el otro lado, usando un check-out de Windows y Linux montando el repository de Windows, los enlaces simbólicos no se conservan (que son necesarios en la compilation de Linux).

No estoy en desacuerdo, mantener ClearCase es una pesadilla y le costará dinero. Pero una vez configurada, puede proporcionar un muy buen entorno de desarrollo. Especialmente cuando comienza a integrarse con ClearQuest (seguimiento de defectos, que también usamos para el seguimiento de revisiones de códigos).

Como dijo otro respondedor, la respuesta para usted depende en gran medida de las necesidades de su process.

En mi compañía anterior (process CMMi), aproximadamente 100 desarrolladores / probadores / integradores trabajan con ClearCase (CC) con 3 administradores de time completo (agregue 2 voluntarios a time parcial). A less que use la parte de administración de la configuration (línea base), debe avanzar en SCM moderno. La característica de reference es poderosa: en SCM tradicional, cuando actualiza / rebase obtiene las últimas revisiones por defecto. Una línea de base es un set de componentes de software en cierta revisión 'compatible' para asegurarse de que la compilation está correcta. De alguna manera, es como la construcción de la dependencia (es decir, Maven, Ant Ivy). Cuando los desarrolladores rebasan (actualizan) en la línea de base, obtienen lo que debería ser "edificable".

Ahora, mirando hacia atrás desde mi nueva compañía (tienda Agile), utilizamos SVN y Mercurial y creo que CC fue un dolor diario. Con CC para trabajar en un proyecto (repository), tiene que crear una vista, crear una actividad y luego extraer un file. Algunos colegas tenían miedo de hacer twigs :). Con SVN y Mercurial, no tenemos tantos problemas con sus clientes GUI. Los desarrolladores se comprometen 10 veces a diario. En comparación, la gente de CC se registraría una vez al día.

De hecho, CC tiene una gran sobrecarga y baja latencia de networking, un alto costo de licencia y un administrador de time completo. Entonces, ¿cuáles son los beneficios, excepto la gestión de configuration.

En Mercurial, el flujo de trabajo es más ligero. Para nuestro proyecto actual, uno cometió un error al comprometer files no fuente. La historia de Hg es inmutable. No tenemos administrador Un desarrollador re clonó un nuevo proyecto en medio día. En Clearcase, necesitaría pedirle a un experto que haga una copy de security de un file eliminado :). Para crear un nuevo repository, le preguntas a tu administrador 🙂

Después de alejarme de ClearCase, ahora estoy muy contento con SVN y especialmente con Mercurial. Por lo tanto, cambiar de ClearCase a Mercurial será muy ligero en términos de process, €€ y obtendrá más productividad.

¿Ahora la elección entre SVN y Mercurial? Debería preguntarse si es un repository centralizado o descentralizado. Puede hacer una búsqueda rápida en stackoverflow.

Me desagradaron los productos de IBM Rational en favor de las soluciones de código abierto elegantes.

Si lees esto y lo entiendes, debes titular "Actualización de clearcase a svn-mercurial" .

Agregado: Clearcase está detrás del umbral de recomendación, mientras que Mercurial, Subversion y Git son claramente recomendados. http://martinfowler.com/bliki/VersionControlTools.html
También puedes combinar Mercurial y Clearcase. Lea el párrafo "Multiple VCS"

Acabo de pasar las últimas semanas en mi nuevo trabajo buscando herramientas SCM (Software Configuration Management) y ALM (Application Lifecycle Management) para adoptar para replace CVS y apoyar la adopción de Agile.

Si está buscando algo que soporte un verdadero SCM con desarrollo y ramificación paralelos, entonces probablemente existan más alternativas de las que cree.

Para una solución simple de SCM, examine lo siguiente:

  • Accurev: esta es una herramienta SCM que tiene soporte nativo para desarrollo basado en stream / paralelo. Proporciona un muy buen browser de flujo que le brinda una vista gráfica de sus transmisiones y le permite promover gráficamente los cambios como problemas o como set de cambios (aplica promoción atómica de un set de files fuente). Tiene un rastreador de problemas incorporado para darle la administración del cambio y permitirle trabajar en una tarea. Con AccuFlow puede tener aún más control de sus cambios con el flujo de trabajo y Accubridge le brinda integración IDE.
  • Seapine Surround: esta es una herramienta atractiva que funciona bien para ramificar pero no tan avanzada como Accurev. Lo bueno de Seapine es la integración con su herramienta de seguimiento de problemas, TestTrack Pro y también su solución de administración de casos de testing TestTrack TCM (que se combinan en TestTrack Stuido). Finalmente, también tienen QA Wizard Pro, que es una herramienta de testing automatizada para web y winforms.
  • PureCM: esta es otra alternativa que es bastante popular, pero no la he analizado con gran detalle
  • Perforce: Otra alternativa en este espacio que no me impresionó tanto, pero tiene algunas características de nicho interesantes, como la capacidad de comparar y combinar imágenes.
  • Plastic SCM: Un producto inmaculado pero muy interesante a la vista.

Todas estas soluciones ofrecen mucho mejor soporte de ramificación que ClearCase tiene conceptos nativos como sandboxes para desarrolladores (en lugar de usar esas locas vistas en ClearCase) y snapshots de verions. Esencialmente una twig de solo lectura, un poco como una línea de base.

Si tiene una amplia implementación de Rational, le recomendamos que consulte estas alternativas:

  • Integridad de MKS: un buen producto bien elaborado que count con excelentes herramientas de administración de carteras con una buena vista de ejecución de testing incorporada. Todas sus herramientas se encuentran en un IDE y son muy personalizables.
  • Serena CM: Nuevamente una suite lo suficientemente agradable con herramientas extensas alnetworkingedor de la solución ALM central. Pieza de administración de carteras muy grande y hay una gran cantidad de soporte de processs de negocio con sus componentes de Mashups y también soporte para creación de prototypes.
  • Telelogic: Irónicamente ahora es parte de IBM y pronto será IBM racional. Su solución SCM (Telelogic Change and Synergy) es fácilmente la mejor que he visto con la capacidad de promover cambios de código explícitamente por tarea en una twig de desarrollo de versiones.

Todas las soluciones anteriores admiten los mismos conceptos de SCM que Accurev, etc., pero son obviamente más productos de extremo a extremo y son de escala empresarial.

En este punto, hemos networkingucido nuestra elección a MKS o Telelogic.

Mi mayor punto sobre esto es que hay muchas, muchas soluciones entre ClearCase y CVS / Subversion que son comerciales pero realmente baratas.

Espero que esto sea útil.

Recomiendo leer HG Init , una guía de Joel Spolsky sobre cómo cambiar de SVN a Mercurial.

Como han mencionado algunas respuestas anteriores, SVN y ClearCase básicamente funcionan bajo el mismo paradigma, por lo que cuando lee el artículo, puede sustituir cada aparición de la palabra "Subversión" por "ClearCase" y aplicarlo a su situación.

Esta es la reseña que finalmente me convenció para comenzar a usar Mercurial en el trabajo.

Me interesaría saber cómo está configurada la estructura de su sucursal.

¿Por qué los usuarios trabajan en el 'tronco' de su producto? (Supongo que esto significa su twig principal). ¿Las twigs de desarrollo no evitarían que los desarrolladores afectasen al tronco principal?

¿Por qué no podría introducir un desencadenador en el script rmview que evita que los usuarios eliminen una vista mientras todavía tienen salidas? Este es un ejercicio bastante trivial, y hay muchas fonts en línea (¡y estoy seguro de que StackOverflow te proporcionará las respuestas si lo preguntas!).

Otra sugerencia sería, si tiene el efectivo ya invertido en productos de IBM (por lo tanto, está dispuesto a gastar dinero en un entorno de SCM compatible comercialmente) es posible que desee echar un vistazo a Team Concert y Jazz.

Me parece que estarás contento en git / mercurial y probablemente no en SVN. OTOH, toda mi experiencia clara fue tediosa y sin amor, por lo que consideraría cualquier acción de "escape" como algo muy bueno.

Los sistemas distribuidos suenan como que combinan mejor con su flujo de trabajo.