Migrar de ClearCase a SVN/Mercurial

Question

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 reducir nuestros gastos generales y ser lo más livianos posible, hemos superado la posibilidad de abandonar CC y buscar algo más ligero (Subversion o Mercurial), ya que no usamos el 90% de las funciones de CC. de todas formas. ¿Suena razonable o vamos a cambiar nuestro Ferrari por una camioneta?

Answer 1

Desde mi experiencia, ClearCase realmente ha tenido un montón de gastos generales y nos las arreglamos mucho con SVN.

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

Answer 2

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

Answer 3

Acepto 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 rebaja 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 proceso de pasar de CVS a SVN y estamos bastante satisfechos con el resultado.

Answer 4

Cumpliendo con la recomendación de cambiar. 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 debes elegir si actualmente estás usando un repositorio de VC centralizado. No solo el modelo operativo de SVN es simple e intuitivo, sino que SVN tiene simplemente la mejor comunidad de desarrolladores y documentación que he visto en un proyecto de código abierto. La lista de correo de los usuarios es magnífica, los desarrolladores son receptivos y responsables con sus usuarios, y el Red Bean book es la mejor pieza de escritura manual de código abierto que existe.

Answer 5

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

Administro SCM (ClearCase y Subversion) y recomiendo Subversion para proyectos pequeños independientes.

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 archivos que permite al usuario acceder a los archivos de la red. Que yo sepa, ClearCase es el único con ese tipo de acceso.

Y tener en cuenta el cambio de paradigma:

• ClearCase es archivo-céntrica (cada archivo que se cree es de sólo lectura, y obtener sólo los archivos en la que se hace el trabajo)
• Subversion es repositorio-céntrica (todos los archivos que se obtiene es de lectura y escritura, que checkIN toda modificado/añadido/archivos eliminados en una confirmación atómica)

Answer 6

la principal cosa que he aprendido es que, más importante que el producto es el proceso .

Si ha implementado ClearCase (CC) utilizando un modelo de tipo SVN, entonces SVN funcionará perfectamente y será un lote más económico.

Por otro lado, si usa las funciones diferidas de ramificación, compilación por etiqueta y dinámicas (o puede), que aprovechamos al máximo para ahorrar tiempo y esfuerzo y mejorar la fiabilidad, lamentará seriamente perder estas características. (Por no hablar de gestión de construcciones, UCM, etc.)

encuentro 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 etiquetas GA, SP1, SP2 (puede tener tantas versiones entre GA y SP1 como desee, no es relevante, y recuerde, las etiquetas CC NO son lo mismo que SVN). GA fue su versión base, SP1 es su versión actual. SP2 es su 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 configuración de CC)

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

Caso 1: En ClearCase, el simple hecho de aplicar la etiqueta 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 rama 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, números 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 Hubiera tenido que hacer si utilicé el modelo de Subversion.

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

Mire el proceso , no solo el producto .

(Lo siento por la longitud, no comenzó ese tiempo :-)

Answer 7

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

Ojalá hubiera investigado Git o algo así antes de recomendar SVN.

Answer 8

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

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

¿Por qué no se puede introducir un desencadenador en el script rmview impidiendo que los usuarios eliminen una vista mientras todavía tienen salidas? Este es un ejercicio bastante trivial, y hay muchas fuentes 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 SCM compatible comercialmente) es posible que desee echar un vistazo a Team Concert y Jazz.

Answer 9

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

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

Para una solución sencilla SMC revisar lo siguiente:

• Accurev: Esta es una herramienta de SMC que tiene soporte nativo para el desarrollo basado en la corriente/paralelo. Proporciona un muy buen navegador de flujo que le brinda una vista gráfica de sus transmisiones y le permite promover gráficamente los cambios como problemas o como conjunto de cambios (aplica promoción atómica de un conjunto de archivos fuente). Tiene un rastreador de problemas integrado para darle administración de cambios y permitirle trabajar de una manera basada en tareas. 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 la ramificación 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 gestión de casos de prueba TestTrack TCM (que se combinan en TestTrack Stuido). Finalmente, también tienen QA Wizard Pro, que es una herramienta de prueba automatizada para web y winforms.
• PureCM: Esta es otra alternativa que es bastante popular, pero no he mirado con gran detalle
• Perforce: Otra alternativa en este espacio que no estaba tan impresionado con, pero tiene algunos interesantes funciones de nicho como la capacidad de comparar y combinar imágenes.
• Plástico SCM: Un producto natural pero muy interesante a la vista.

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

Si usted tiene un amplio despliegue racional es posible que desee ver en estas alternativas:

• MKS Integrity: Una bonita bien juntos producto que tiene excelentes herramientas de gestión de carteras con un bonito construido en marcha de prueba ver. Todas sus herramientas se encuentran en un IDE y son muy personalizables.
• Serena CM: Nuevamente una suite lo suficientemente bonita con herramientas extensas alrededor de la solución ALM básica.Pieza de administración de carteras muy grande y hay una gran cantidad de soporte de procesos de negocio con sus componentes de Mashups y también soporte para creación de prototipos.
• 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 rama 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 reducido 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 haya sido de utilidad.

Answer 10

cosas que me gustó ClearCase que no he sido capaz de hacerlo tan bien o en absoluto en otras herramientas SCM:

1. Trabajando con ramas de desarrolladores fue como la seda. En CC (UCM), trabajas en tu flujo (por ejemplo, una rama) y "entregas" un montón de trabajo al flujo de integración. Mientras tanto, otros desarrolladores hacen lo mismo. El integrador (tal vez uno de los desarrolladores) hace algunas pruebas 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 línea de base nueva 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 rama. 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 ramas de desarrollador condujeron a revisiones de código efectivas. Cuando estaba usando CC, revisamos todo. Prácticamente, sin embargo, las revisiones tomaron tiempo 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 archivos 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 objetivo era realizar cambios, crear, probar y depurar en plataformas Linux y PowerPC (y Windows para otro proyecto) y comprometer un solo conjunto de cambios una vez que me alegré de que funcionara en todas las plataformas. Para las compilaciones de PowerPC, teníamos una estación de trabajo solar (acceso a la vista dinámica) que usamos para construir y probar un objetivo. Fue lento, así que hicimos la mayor parte de nuestra codificación y depuración en Linux, y luego construimos y probamos en el PowerPC antes de la prueba final en el objetivo (PowerPC), y finalmente un check-in. Una forma de evitar esto es compartir archivos de red. Un problema que he visto aquí es incompatibilidades de versión entre Linux svn y TortoiseSVN en Windows. Si deja Tortoise en una copia de repositorio de Linux, cambia el.svn files, y Linux svn luego 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 objetivo). Por lo tanto, no puedo usar mi herramienta diff de Windows en un repositorio svn de Linux. Si voy por el otro lado, usando un check-out de Windows y Linux montando el repositorio de Windows, los enlaces simbólicos no se conservan (que son necesarios en la compilación de Linux).

No estoy en desacuerdo, manteniendo ClearCase es una pesadilla, y lo hará coste 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 proceso.

Answer 11

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 si combinan mejor con su flujo de trabajo.

Answer 12

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, así que cuando lea el artículo, puede sustituir cada aparición de la palabra "Subversion" por "ClearCase" y aplicarlo a su situación.

Este es el escrito que finalmente convenció mí para comenzar a usar Mercurial en el trabajo.

Answer 13

En mi compañía anterior (proceso CMMi), aproximadamente 100 desarrolladores/probadores/integradores trabajan con ClearCase (CC) con 3 administradores de tiempo completo (agregue 2 voluntarios a tiempo parcial). A menos que use la parte de administración de la configuración (línea de base), debe avanzar en SCM moderno. La característica de referencia es poderosa: en SCM tradicional, cuando actualiza/rebase obtiene las últimas revisiones por defecto. Una línea de base es un conjunto de componentes de software en cierta revisión 'compatible' para asegurarse de que la compilación 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 empresa (tienda Ágil), utilizamos SVN y Mercurial y creo que CC fue un dolor cotidiano. Con CC para trabajar en un proyecto (repositorio), tiene que crear una vista, crear una actividad y luego extraer un archivo. Algunos colegas tenían miedo de hacer ramas :). 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 de latencia de red lenta, alto costo de licencia y necesita administrador de tiempo completo. Entonces, ¿cuáles son los beneficios, excepto la gestión de configuración.

En Mercurial, el flujo de trabajo es más ligero. Para nuestro proyecto actual, uno cometió un error al comprometer archivos 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 copia de seguridad de un archivo eliminado :). Para crear un nuevo repositorio, le pregunta a su administrador :)

Después de dejar 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 proceso, €€ y obtendrá más productividad.

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

No me gustan los productos de IBM Rational en favor de las soluciones de código abierto elegantes.

Si leyó esto y lo entendió, debe titular "Actualización de clearcase a svn-mercurial".

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