Ventajas / desventajas de ClearCase

Debido a que actualmente estoy luchando por aprender IBM Rational ClearCase, me gustaría escuchar su opinión profesional.

Estoy particularmente interesado en las ventajas / desventajas en comparación con otros sistemas de control de versiones como Subversion o Git.

Puede encontrar una buena comparación entre ClearCase y Git en mi SO respuesta:
" ¿Cuáles son los conceptos básicos de ClearCase que todo desarrollador debería saber? ", Que ilustra algunas diferencias importantes (y algunas deficiencias de ClearCase)


Operaciones cinputs en file

La única deficiencia importante de ClearCase es su antiguo enfoque " centrado en files " (en lugar de " repository- céntrico" como en SVN o Git o Perforce …)
Eso significa que cada pago o logging se hace file por file. La atomicidad de la operación está en niveles de files.
Combine eso con un protocolo muy detallado y una networking con potencialmente varios nodos entre la estación de trabajo del desarrollador y el server VOB, y puede terminar con un server de files bastante lento e ineficiente (que ClearCase está en su núcleo).

Las operaciones de file por file significan: operaciones recursivas lentas (como el pago recursivo o recursivo "agregar al control de origen" , incluso por clearfsimport ).
Una LAN rápida es obligatoria para mitigar los efectos secundarios de ese protocolo de conversación.

VCS centralizado

El otro aspecto a tener en count es su aspecto centralizado (aunque puede ser "distribuido" con su function VOB replicada de múltiples sitios)
Si la networking no permite el acceso a los VOB, los desarrolladores pueden:

  • todavía funciona en vistas de instantáneas (pero solo con files secuestrados)
  • esperar la restauración de la networking si están utilizando vistas dinámicas

Opción VCS distribuida costosa

Puede tener alguna function de VCS distribuida al replicar un Vob.
Pero:

  • necesitas un tipo especial de licencia para acceder.
  • esa licencia es costosa y se agrega al costo de la licencia regular
  • cualquier vob que use el vob replicado (admin vob, admin pvob, …) debe ser replicado también (lo que significa que algunos proyectos que no están directamente relacionados con un desarrollo distribuido tendrán que pagar la licencia multisitio …)

GUI antigua y no fácil de usar

  • la GUI es muy antigua y poco práctica (aspecto de MFC de mediados de los 90, interfaz gráfica de usuario completamente sincrónica, lo que significa que debe esperar una actualización antes de hacer clic en otra parte): al search líneas de base, no puede search rápidamente una en particular.
  • la GUI en Unix no es exactamente la misma que en Windows (la última versión 7.1 es mejor pero aún no está allí)
  • el process de installation es bastante complicado (aunque el último Administrador de installation introducido por CC7.1 ahora es una GUI coherente en Windows o Unix y simplifica el procedimiento)
  • la única aplicación realmente rica solo se ha desarrollado para CCRC (el cliente remoto)

Inconsistencias UCM y en coinheritance

Como se menciona en " Cómo aprovechar las características de ClearCase ", las vistas dinámicas son geniales (una forma de ver los datos a través de la networking sin tener que copyrlos en el disco), pero la característica principal sigue siendo UCM : puede ser un activo real si tiene gran proyecto con flujo de trabajo complejo.

Algunas deficiencias en ese frente:

  • las dependencies entre los componentes no se gestionan bien para una profundidad superior a uno (debido al error de " línea base del parásito ")
  • UCM todavía tiene algunas coinheritances e incoinheritances, como se documenta en CM Crossroads

Políticas limitadas con Base ClearCase

Usar ClearCase sin usar UCM significa tener que definir una política para:

  • crear una twig (de lo contrario, cualquier persona puede crear cualquier twig, y ​​usted termina con un gazillon de ellos, con una pesadilla de flujo de trabajo de fusión)
  • ponga tags (de lo contrario, se olvida de labelr algunos files, o coloca una label donde no se suponía que debía hacerlo, o "mueve" (jadea) una label de una versión a otra: al less las líneas base de la UCM no se pueden mover)
  • define changeset . ChangeSets solo existe con actividades de UCM. Con Base ClearCase, se cleartool find networkingucido a inteligentes cleartool find " cleartool find " …

Sin derechos de aplicación

La administración correcta de ClearCase se basa completamente en los derechos del sistema.
Esto significa que debe registrar a su usuario en el grupo de sistemas correcto, lo que no siempre es fácil cuando tiene que ingresar un ticket en su service de TI para que se registren correctamente.
Agregue a eso un entorno heterogéneo (usuarios en Windows y server en Unix), y necesita registrar su usuario en Unix y en Windows. (con el mismo nombre de inicio de session / grupo). A less que coloque algún tipo de correspondencia LDAP entre los dos mundos (como Centrify )

Sin API avanzada

  • solo CLI está completo (" cleartool " es ClearCase Command Line Interface), lo que significa que cualquier script (en Perl u otro idioma) consiste en analizar el resultado de esos commands cleartool )
  • ClearCase Automation Library (CAL) existe, pero es bastante limitado
  • Existe API Java, pero solo para vistas web para el cliente CCRC.

Ver almacenes no fácilmente centralizados / respaldados

Los almacenamientos de View son el equivalente del ".svn" de SubVersion, excepto que hay solo un "almacenamiento de vistas" por vista en lugar de muchos .svn en todos los directorys de un espacio de trabajo de SubVersion. Eso es bueno.

Lo malo es que cada operación dentro de una vista (un simple " ls ", comprobación, comprobación, …) desencadenará una request de networking al process view_server que gestiona su server de visualización.
2 opciones:

  • declare el almacenamiento de su vista en su estación de trabajo: ideal para la escalabilidad, puede tener tantas vistas como desee sin gravar la LAN: todas las comunicaciones se realizan directamente en su estación de trabajo. PERO si esa máquina muere sobre ti, pierdes tus puntos de vista .
  • declare el almacenamiento de su vista en un server centralizado: eso significa que todo el process de view_server se creará allí y que todas las operaciones en una vista por parte de cualquier usuario tendrán que comunicarse con ese server. Se puede hacer si la infraestructura es "correcta" (LAN especial de alta velocidad, server dedicado, monitoreo constante), pero en la práctica, su LAN no admitirá este modo.

El primer modo significa: debe hacer una copy de security de su trabajo en progreso (files privados o files desprotegidos)
El segundo modo significa: su estación de trabajo puede no estar disponible, puede simplemente iniciar session en otra y recuperar sus vistas (a exception de los files privados de una vista de instantánea)


Discusión lateral sobre vistas dinámicas :

Para agregar al aspecto de "vista dinámica", tiene una ventaja (es dinámica) y una deficiencia (es dinámica).
Las vistas dinámicas son excelentes para configurar un entorno simple para compartir rápidamente un desarrollo pequeño entre un equipo pequeño : para un pequeño esfuerzo de desarrollo, una vista dinámica puede ayudar a 2 o 3 desarrolladores a mantenerse constantemente en contacto, ver al instante cuando se rompe el compromiso algo en los otros puntos de vista.
Para un esfuerzo de desarrollo más complejo, es preferible el "aislamiento" artificial proporcionado por la vista de instantánea (solo verá los cambios cuando actualice o "actualice" su vista de instantánea)
Para un esfuerzo o curso de desarrollo realmente divergente, aún se requiere una twig para lograr el aislamiento verdadero del código (se necesitarán fusiones en algún momento, lo que ClearCase maneja muy bien, aunque lentamente, file por file)

El punto es que puedes usar ambos, por las razones correctas.

Nota: por equipo pequeño no me refiero a "proyecto pequeño". ClearCase se utiliza mejor para proyectos grandes , pero si desea utilizar vistas dinámicas, debe configurar " twigs de tareas para aislar un pequeño esfuerzo de desarrollo por twig: de ese modo un" pequeño equipo "(un subset de su gran equipo) ) puede trabajar eficientemente, compartiendo rápidamente su trabajo entre sus miembros.
Si usa vistas dinámicas en una twig "principal" donde todos hacen cualquier cosa, cualquier check-in lo "mataría" ya que podría introducir algunos "quiebres de construcción" no relacionados con su esfuerzo de desarrollo actual.
Eso sería un mal uso de vistas dinámicas, y eso olvidaría sus otros usos:

  • una forma adicional de acceder a los datos , además de vistas de instantáneas, lo que significa que es una gran herramienta para simplemente "ver" los files (puede usar una vista dinámica para modificar sus especificaciones de configuration hasta que vea lo que desea y luego copyrlas) reglas en su vista de instantánea habitual)
  • una vista lateral para realizar fusiones: trabajas con la vista de instantáneas, pero para las fusiones puedes usar tu dinámica "hermana-vista" ("hermana" como en "misma especificación de configuration"), para evitar tener una fusión fallida debido a los files extraídos (en los que estaría trabajando actualmente en la vista de instantánea) o debido a una vista de instantánea no completamente actualizada. Una vez completada la fusión, actualice su vista instantánea normal y reanude su trabajo.

Desarrollar directamente en una vista dinámica no siempre es la mejor opción, ya que todos los files (no pagados) se leen a través de la networking .
Eso significa que se accederá a la dll, jar o exe que necesita su IDE a través de la networking, lo que puede ralentizar considerablemente el process de compilation.
Soluciones posibles:

  • una vista de instantánea con todo en ella
  • una vista de instantánea con dll o jar o exe en ella (files que no cambian cada cinco minutos: una actualización por día) y vista dinámica con solo las fonts visibles.

El costo es una desventaja bastante obvia. No solo el costo de la licencia, sino también el costo del salario de un gurú de ClearCase. Casi todas las empresas que conozco que usan ClearCase parecen tener al less una persona cuyo único propósito es domesticar a la bestia rebelde.

El hecho de que sea lo suficientemente complicado como para requerir una niñera a time completo también es preocupante.

Una pesadilla absoluta de un sistema. Me hizo desear poder volver a VSS. (¡No importa ningún sistema de control de fuente moderno como Subversion o Git!)

  • Es slooooow .
  • Si utiliza vistas dinámicas y la networking no funciona, no podrá acceder a su copy de trabajo de la fuente. No puede hacer nada más que sentarse y esperar a que se solucione.
  • Si usa vistas de instantáneas parece que se encuentra con conflictos y files "secuestrados" todo el time, por lo que los files en su copy de trabajo nunca son exactamente los mismos que en el repository de origen .
  • Cada vez que intenta una gran actualización o entrega , invariablemente falla por una razón u otra, lo que requiere que su gurú de ClearCase pase unas horas / días averiguándolo. ¡Oh, sí, debes tener un gurú ClearCase dedicado y de time completo!
  • Cuando falla, a menudo tampoco puede deshacer la operación, por lo que está bloqueado con una operación en curso y los desarrolladores están bloqueados .
  • Cuando mira más allá de los icons bonitos (?), La GUI es muy pobre , ¡hasta cosas como no poder cambiar el tamaño de Windows para ver routes de files completas!
  • Su personal de soporte es bastante reacio a arreglar cualquier cosa. Su primera respuesta es siempre " esto es por layout " y "¿puedes solucionarlo?" Si finalmente proporcionan una solución (después de mucho discutir) será la solución más básica posible para el problema más inmediato.

Básicamente, es lento, complicado y poco confiable como el infierno. Ah, ¿y mencioné que es ridículamente caro ? ¡La única forma en que posiblemente puedan venderlo es hablando con tomadores de decisiones que nunca han usado el producto y nunca lo harán! Estoy bastante seguro de que ningún desarrollador en el mundo lo compraría alguna vez.

Los commits atómicos y los sets de cambios son mis principales quejas contra ClearCase. Digamos que ingresa cinco files como parte de una corrección de error o refactorización. Luego se descubre que algo se ha estropeado y que necesita revertir. Buena suerte para encontrar los cinco files que son y en qué versión debe estar cada uno. Pero retrocedamos un paso. Acaba de editar esos cinco files y es hora de comprometerse. Los primeros cuatro pasan bien. Ese último requiere una fusión masiva. Los otros cuatro files ya están registrados. No esperan a que termine los cambios necesarios en el último file. Espero que nadie haya actualizado o esté usando una vista dinámica. Un server de construcción de continuous integration va a fallar también.

A veces hacemos un directory completamente nuevo lleno de files que deben registrarse, pero no queremos registrarlos hasta que estén listos. Es temprano y todo sigue siendo volátil, entonces, ¿por qué revisar las cosas que podrías eliminar muy pronto? OK, bien hasta ahora. Ahora es el momento de registrarse. Agregue la carpeta recién creada al control de fuente. Bueno, ClearCase no es recursivo, por lo que solo esa carpeta está registrada. Con SVN, esa carpeta y todo lo que está debajo se agrega, como usted elija. El desarrollador debe recordar agregar todo, de lo contrario, faltarán muchos files.

ClearCase posee los files y las carpetas, por lo que no puede modificar nada a less que lo haya comprobado primero. El plugin Eclipse quita muchas molestias aquí. No puedo decirte cuántas veces abrí un file en vi para hacer un cambio rápido, solo para encontrar que había olvidado revisarlo primero. El pago no es recursivo tampoco.

Las actualizaciones pueden ser muy lentas sin sets de cambios. Cuando actualiza con una vista de instantánea, cada file se actualiza, no solo los files modificados. Trabajé en un proyecto con más de 20,000 files. Me gustaría acceder a mi máquina de trabajo de forma remota, iniciar la actualización y luego conducir al trabajo; conseguir café; ir a mi escritorio mientras estaba terminando. Eso puede sonar como una exageración, pero lamentablemente no lo es.

Las vistas dinámicas son terribles a less que se encuentre en un equipo muy pequeño. Y si ese es el caso, ¿por qué tienes ClearCase? He visto innumerables vistas de personas que se manchan porque alguien revisó files que rompieron las opiniones de todos los demás. Siempre debe actualizar y combinar cualquier conflicto en su propia vista. De esa forma, los cambios solo te afectan. Con una vista dinámica, no puede fusionarse antes de volver a presionar; solo compromete y espera.

Sé que el costo probablemente no sea una gran preocupación, pero los desarrolladores que generan el dinero para la compañía disfrutarían de gastar entre $ 50k y $ 100k (dependiendo de la licencia de ClearQuest, que es una adición común) en events divertidos o equipos nuevos ( sillas, monitores, etc.). IBM recomienda tener personal para mantener en marcha ClearCase. ¿Por qué no networkingiseñar a esas personas para generar ingresos para la empresa, en lugar de asegurarse de que las cosas no se estrellen y se quemen?


Algunas de las razones que he escuchado para no cambiar:

  • El aprendizaje llevará time y dinero
    • Aprender SVN o Mercurial no debería tomar más de un día. Solo ClearCase sugiere tener una cierta proporción de administradores a desarrolladores.
  • La migration será dolorosa
    • Esta es la razón por la cual existen herramientas: cc2svn
    • No es tan fácil con Mercurial
  • Seguridad
    • No se conocen agujeros en SVN AFAIK, y el equipo de desarrollo está dedicado a arreglar todo lo que se encuentre rápidamente. El Departamento de Defensa parece estar bien con SVN.
  • Sin ganancia de productividad real después
    • Lleva una eternidad intentar rastrear errores sin sets de cambios. Me encanta poder retroceder hasta que no puedo ver el error. No puedes hacer eso en ClearCase.
  • Multisite
    • WANdisco resuelve ese problema. Sin embargo, no es gratis.

Lo único que ClearCase hace mejor que el rest es ramificar files individuales, mientras mantiene a los demás en la misma pista que otra twig.

Todo lo que hice en Clearcase siempre parece difícil . Mientras que nunca tuve esa printing con otros sistemas (excepto quizás CVS en ocasiones).

He usado SVN, CVS, Clearcase y Mercurial.

Mi experiencia con ClearCase fue un desastre, y mencionaré la afirmación de Don de que requiere un experto residente, lamentablemente tuvimos más de uno. Tenía experiencia con CVS y otros sistemas de control de versiones, estaba familiarizado con los conceptos, pero encontré la documentation de ClearCase incomprensible y tuve que pedir ayuda varias veces; diferentes expertos me dieron consejos contradictorios hasta el punto en que rompimos el CD . Es decir, después de que emití un command ClearCase en un shell de UNIX, el command "cd" falló con un post de error.

La tarea básica de un sistema de control de versiones es realmente bastante simple. Honestamente, creo que media docena de commands deberían ser suficientes, usando un esquema de files que funciona bien con otros. Para mí, ClearCase parece el resultado de un ejecutivo de marketing que complica deliberadamente las cosas para que el producto se vea sofisticado y poderoso. He oído que se puede configurar para que se comporte de una manera simple, segura y confiable, pero una vez más eso requiere los services de un experto. De fábrica, es como una razor suiza motorizada.

Todo lo que he experimentado relacionado con ClearCase en cualquier capacidad es ineficiente, feo, demasiado complejo, lento, confuso, costoso e inconveniente.

Parece atraer a gerentes e ingenieros que SIMPLEMENTE LO HAN TOTALIZADO.

Maldita sea, IBM y Rational deben tener increíbles vendedores para vender un producto tan malo.

Estamos migrando de CC a Git por muchas de las razones dadas aquí. Me gustaría agregar una razón para mantenerse alejado de CC o cualquier otro sistema de control de fuente comercial.

Sus datos comerciales vitales son rehenes de ClearCase. No puedes sacarlo.

Sus datos comerciales vitales son el código, su historial de versiones y todos los metadatos, como los comentarios de confirmación, quién se registró y cuándo.

Todo el software tendrá una vida útil limitada. Siempre debe preguntarse cuándo introduce un nuevo sistema que absorbe datos comerciales importantes, ya sea código, errores, datos de clientes o no: ¿Cómo obtengo mis datos nuevamente? Si no puede responder esa pregunta, no debe introducir ese sistema.

Cuando migramos, perdimos la mayor parte de nuestra historia y todos nuestros metadatos. Básicamente, solo tenemos el historial correspondiente a las versiones publicadas, pero la información sobre qué cambios se realizaron en respuesta a las requestes de los clientes se perdió (tenemos esa información en el sistema de soporte al cliente y de errores), para que no se pierda por completo, pero el acoplamiento el código fuente se ha ido).

Esto será en algún momento entre una molestia y un problema para nosotros en el corto y mediano ploop. En un par de años, ya no es importante, pero quizás por 1-3 años será importante.

(Hay herramientas comerciales para migrar CC a otro SCM, pero no se consideraron adecuadas a nuestras necesidades, y dudo que hubiera sido posible. La export mínima que hicimos tomó suficiente time).

La lección aprendida es: Nunca confíe datos empresariales vitales a sistemas propietarios.

Sin compromisos atómicos

Una vez que haya registrado los files, es muy difícil revertir a un determinado estado, porque las confirmaciones atómicas no son compatibles. Al registrar múltiples files, cada file recibe una nueva revisión (similar a CVS) y no el logging mismo. Creo que esta es una característica crucial, ya que difícilmente se desea revertir files individuales, sino completar acciones de confirmación (que deben mapear tareas). Con ClearCase, solo puede volver a ciertos estados mediante el uso de tags. En la práctica, el uso de tags de ClearCase para cada logging es excesivo y, por lo tanto, no se realiza.

Interfaz de usuario Crappy

La GUI de ClearCase Explorer es solo una gran broma. Horrible en usabilidad y aspecto feo. No se proporcionan funciones diferentes ya menudo necesarias (por ejemplo, comprobación recursiva de los artefactos). La herramienta de línea de command cleartool utilizada con cygwin es mucho mejor, pero todavía hay algunas cosas que no están disponibles, como añadir recursivamente nuevos files / carpetas al control de fuente. Tengo que reírme si leo 50 líneas de código largo para solucionar esto.

Altos esfuerzos de administración

Administrar ClearCase bestia está lejos de ser obvio o liviano (a diferencia de otros sistemas scm como CVS, subversión o Git). Espere poner bastantes expertos dedicados de ClearCase para simplemente mantenerlo funcionando.

Rendimiento horrible

No hay nada peor ya que hacer que los desarrolladores esperen mientras interactúan con la herramienta SCM es como conducir con frenos de mano habilitados. Se ralentiza tu cerebro y también tu trabajo. Obtener nuevos files frescos para su vista de instantánea toma alnetworkingedor de 30 minutos para artefactos de 10K. Una actualización (no se modificaron los artefactos) por la misma cantidad demora aproximadamente 5 minutos. Cuando se experimenta mucho y se salta entre diferentes vistas actualizadas, hay que esperar mucho. Peor aún, cuando trabajas en files y quieres registrarlos o actualizarlos. Check-out, check-in y agregar a los ciclos de control de fuente toman alnetworkingedor de 10-15 segundos, lo cual es obviamente una pesadilla. Se vuelve muy molesto cuando estás refabricando cambiar el nombre / mover types o methods (muchos files pueden verse afectados).

La falta de apoyo del desarrollo distribuido

Hoy en día, el desarrollo de software es a menudo una cosa distribuida (los desarrolladores están diseminados por todo el mundo trabajando en el mismo producto / proyecto). Evidentemente, ClearCase no es adecuado para esto, ya que no es adecuado para trabajos fuera de línea. Hacer un check-out (una acción antes de poder editar un file / carpeta) requiere que esté conectado a la networking. Aquí podría usar la opción de secuestro, pero esto es más bien una solución alternativa (básicamente, desbloquea el file en el sistema de files). Si sus sitios de desarrollo están muy lejos de su server ClearCase, la latencia de check-in / check-out puede incluso boost tan dramáticamente que no se puede utilizar en absoluto. Hay soluciones para eso, como usar ClearCase Multisite (tecnología de réplica de DB DB), pero tiene que pagar extra por ello y no es trivial de administrar.

Git como alternativa

Aunque soy un gran seguidor de Open Source, estoy dispuesto a pagar por un buen software. Pero mirando al monstruo de IBM ClearCase, no invertiría mi dinero aquí, tiene todas estas deficiencias discutidas, y más IBM parece no invertir dinero para mejorar sus productos de manera significativa. Recientemente eché un vistazo a una scm de Git que se ve muy bien, especialmente por sus funciones de bifurcación y fusión, donde ClearCase tiene sus principales fortalezas.

Esta información tomada de http://www.aldana-online.de/2009/03/19/reasons-why-you-should-stay-away-from-clearcase/

Posiblemente el peor software jamás creado. No trabajaré para ninguna empresa que use algo racional. Aparte de que CC se bloquea y reinicia completamente mi estación de trabajo con frecuencia en comstackciones dinámicas. ¿Qué sucede cuando estás presionando algo para controlar la fuente y CC hace lo que hace mejor, bloquear? ¿Su código luego se pone en perdido + encontrado, respaldado en algún lugar tal vez? No, se ha ido para siempre. Entonces, si alguna vez se encuentra en la terrible situación de usar esta pieza gigante de software costoso, mantenga duplicates de todo. Buen trabajo Rational / IBM. Manera de capturar la parte más importante del control de fuente, confiabilidad. Muere lento.

Desventajas de ClearCase: una adición al post más profundo aquí.

  1. La herramienta de fusión no vale la pena. Apenas te ayuda, no restring las decisiones que tomaste, es solo una diferencia glorificada.

  2. La herramienta de fusión tiene que verificar los directorys para incluso CHECK si necesitan una combinación. Es un poco loco

  3. Utilizo BitKeeper en el trabajo (supongamos que Git) y fusionar dos repositorys incluso si hay conflictos es tan trivial y fácil de usar incluso con command-line, mientras que ClearCase tiene toneladas de herramientas GUI es un process largo y laborioso que también es extremadamente propenso a errores .

  4. Todas las herramientas de GUI requieren una gran cantidad de latencia. Incluso ver lo que se puede hacer en un file requiere una connection de alta velocidad. Por lo tanto, onclick derecho en la herramienta ClearCase en un file que funciona desde su hogar podría tomar uno o dos minutos tener Internet de alta velocidad debido a la cantidad extrema de requisitos de networking.

  5. Alguien puede estropear completamente el repository o los loggings si hacen que sus especificaciones de vista sean diferentes a las del equipo. Lo cual es una locura que nadie puede verificar alguna twig; necesitan la especificación de vista apropiada que de paso les dará las cosas correctas. El concepto completo puede ser agradable y flexible, pero el 99% del time causa mucho dolor. ¿Mencioné que no puede enviar sus especificaciones por correo electrónico a través de Microsoft Outlook debido a que las herramientas CC no aceptan UTF-8 por lo que no puede copyrlas y pegarlas?

  6. No tengo absolutamente nada bueno que decir sobre CC. Lo utilicé durante 2 años en 2 compañías y lo abandoné en un abrir y cerrar de ojos sintiéndome feliz todo el time. También es imposible experimentar en casa con sus propios proyectos, por lo que aún aprenderá SVN o Git en casa, y se verá obligado a pasar por el trabajo de ClearCase. Nadie que conozco ha usado CC voluntariamente. Solo lo usan porque algún gerente en el trabajo decidió CC es el path a la salvación y obligó a todos a migrar a ella. De hecho, mi última compañía migró de CVS a ClearCase, y luego de un año de ClearCase a SVN. Fue eso odiado.

  7. ClearCase no es solo una cosa que te hace decir que no. Es como vivir en una casa infestada de ants. Cada ant es solo un pequeño inconveniente en el mejor de los casos, pero la infestación te volverá loco.

Estoy intentando consolidar algunos comentarios en una publicación real aquí. No estoy aquí para convencerte de que uno es mejor que el otro, excepto por hacer algunos puntos:

  • Si comparas git y ClearCase, respetuosamente sugiero que necesitas definir mejor tus necesidades: si estás considerando ClearCase por una "buena" razón, el idiota probablemente ni siquiera está en la ecuación, es demasiado nuevo para confiar. para control de fuente de nivel empresarial, imo.
  • ClearCase presenta una gran cantidad de conceptos en el espacio de control de versiones que otros sistemas no tienen, por lo que puede ser bastante desalentador y confuso. Especialmente si la única experiencia que tiene es leer la documentation, como parece ser el caso para algunas personas aquí.
  • ClearCase definitivamente no es muy adecuado para grandes bases de código compatibles con desarrolladores que no están en una LAN con un server VOB. Puede tener muchos serveres VOB replicados (multisitio) para acercarlos a los desarrolladores remotos, pero esto no es necesariamente práctico si esos sitios remotos son solo un desarrollador.
  • ¿Desea un control de versiones de files o versiones de repositorys? Esta es una pregunta bastante importante, y que necesariamente filtrará un set completo de herramientas, facilitando su trabajo. El control de versiones del repository tiene muchas ventajas (y no es "nuevo", como afirman algunos carteles: herramientas comerciales como Perforce han existido por más de una docena de años, y puede que haya herramientas que hicieran versiones de repositorys incluso antes de Perforce), pero no es una panacea
  • Con una installation suficientemente grande de cualquier sistema de control de fuente, vas a necesitar ayuda. When considering tools, you need to consider how easy it will be to find people to help you (either job applicants who have experience, or consultants who will be there at a moments' notice to address any issues). There's no such thing as a maintenance-free SCM system, and assuming you have one will get you into more trouble than picking one that requires "too much" administration.
  • Don't pay too much attention to people who talk about how bad "dynamic views" are – bad SCM policies are bad, regardless of the tool you're using. Your configuration management policies and practices have to be separate from your choice of tool – no tool will stop people from smashing all over your codebase if you don't define sensible branching and merging policies. If someone suggests that having developers directly commit onto /main is ever a sensible idea, you might want to walk away from that conversation.

ClearCase is a fine tool, but it is a complicated tool. There is no getting around this – it does not have an "easy install" mode. 🙂 From a technical standpoint, there's nothing that git or SVN can do that ClearCase cannot (although often the terminology is different, since Open Source projects tend to just invent new taxonomy where there already existed one), but some things are definitely easier/harder for a given system, depending on their design. ClearCase "snapshot" views are basically the same thing you would have if you checked out a repository from SVN or CVS – it's a local copy of the source code on your machine, with pointers back into the central server for tools to query version history, etc. You can work with these views without any network connection to the ClearCase server at all once they have been created, and you can "recycle" them to avoid downloading your entire repository again when you want to move to work on another branch, for example. "Dynamic Views" are basically a ClearCase invention, and the standard operating mode for a LAN. They appear the same as checking out an SVN repository, but they don't actually copy any files until you make changes. In this way the view is available immediately, but it obviously cannot be worked with if the main clearcase server is unavailable, and is unpleasant to work with over a high-latency connection. They also have the convenience of being able to be mounted as a network drive on any machine with access to the server on which they were created, so if your windows workstation dies, you can just log onto another one, mount your view, and get back to work, since all the files are stonetworking either in the VOB server (for files you haven't modified on this branch), or the view_server (for files you have created or modified just in this view).

Also, and this deserves its' own paragraph….clearmerge is nearly worth the price of admission alone. It's hands down the best merge tool that I've ever used in my life. I firmly believe a lot of bad practice in SCM has developed because of a lack of high-quality merge tools, so CVS users never learned to use branches properly and this fear of branching has propagated to the current day for no particularly good reason.

Ok, all that being said, if you're looking for reasons not to use ClearCase, they're not hard to find, although I think that's the wrong way to go about it. Really you should need to come up with good reasons TO use ClearCase, not reasons for NOT using ClearCase. You should come into any SCM situation assuming that ClearCase is too much tool or too complicated a tool for the job, and then see if you have some situation that encourages you to use it anyhow. Having IBM or Rational logos is not a good reason.. 🙂

I would not even consider ClearCase unless you could say yes to all the following statements:

  • You do now, or will eventually have, more than 50 developers working on the same codebase.
  • Most of those developers are centrally located, or have high-throughput low-latency connections to a central location.
  • You have a set of SCM policies and can identify how to use ClearCase to enforce those policies (really you should consider this for any tool)
  • Money really is no object

My experience is mostly limited by CC, CVS and SVN. In principle, CC is technologically capable, enterprise ready and comparable by features with any modern VCS. But it has several flaws that make it unusable in any people-oriented environment. For process oriented environments it is probably more appropriate, though I doubt that such environments are appropriate by themselves. Maybe, in military, cosmic or medical software, I don't know. Anyway, I believe that even for these domains there are appropriate and still more friendly tools.

Beside being technically capable VCS, CC has several distinctive advantages:

  • Dynamic views
  • Nice version tree
  • Triggers
  • Good merge versioning, including renames

In my opinion, their use is limited excepting last one; and they don't compensate flaws. Dynamic view nice in theory, but not always available in practice. Version tree has much less use in other VCS, while necessary in CC because of proliferation of branches (see 6). Triggers, as I know, very detailed and capable, but I think that for most practical tasks SVN hooks are good enough. And now about disadvantages that mostly concerns usability:

  • CC totally fails in sense of usability for main user group: for developers. And that is the main reason why I think that it should never be used in any environment, be it enterprise or not. Even if it were free, it would nevertheless suck your company's money by wasting time of your developers and frustrating them. This point is composed from:
    1. "Check out-Check In" with strict locking approach – it is counter-productive, refactoring unfriendly, and dangerous in repository organizations with single development branch for multiple developers. Meanwhile, the advantages of strict locking are negligible.
    2. Poor performance and high load
    3. It effectively cannot be used remotely without multi-site (due to 2). Multisite is expensive too. ClearCase Remote client is very limited. It don't even have cleartool (before version 7.1), leaving alone dynamic views.
    4. It can hardly be used offline. Dynamic views are just not work. Snapshot views are effectively read only, because you cannot check out without access to repository (see 1). Hijack is poor option which in fact means that CC gives up any responsibility for hijacked file. And CC cannot show you difference with previous revision when offline. SVN is able to show difference with previous revision even being offline.
    5. Overly complicated model, especially with UCM: VOBs, PVOBs, Projects, streams, branches, views, deliver, update, load, restre, rebase, merge, baseline, check in, check out. I think that half of this concepts are just superfluous and doesn't add value, while increasing both technical and conceptual complexity. Few developers understand even basic stuff about CC.
    6. Proliferation of branches. For example, repository often organized with stream per developer (due to 1). It just has no sense in SVN or most other VCSs.
    7. No repository wide revisions. Well, there are such revisions as understand, they called baselines. But when I see some file revision and want to get repository snapshot at the moment of that file revision, I will get some problems. I will need to do black magic with config spec to create a snapshot view, or find somehow through dynamic view if it is available.
    8. Crappy user GUI. Version tree, even being nice, has mediocre usability. Merge tool is just a pity. Other "features": not resizeable windows, absence of incremental search in some places, mouse-centric interface, look and feel in 1995 style, strange work flow distributed between Client and Project Explorer etc.
    9. CC provokes rare and vast check ins. You all know, that check ins must be small and frequent. But developers usually refrains from additional interactions with CC, hijack files and work in local VCS or even without VCS at all (which is more often, unfortunately). And then, after two weeks of development they begin commit comlex feature that adds 20 files and affects another 20 files. It lasts for a day or two, because they hijacked files and now need to perform manual merge with all new changes from repo and resolve all conflicts and discrepancies. During that process, code lies not comstackble, because several files successfully got checked in and others do not. And after that it still lies not comstackble because they forgot to add another 2 files to CC.
  • It is very expensive
  • It is very complex in terms of infrastructure and requires dedicated administrators

ClearCase seems extremely powerful, from the outside. But really, it's just that the number of commands and options you need to use for basic workflow is so high that these get hidden behind a few aliases or scripts, and you end up with something less powerful than CVS, with the usability of Visual Source Safe. And any time you want to do something a little more complicated than your scripts allow, you get a sick feeling in your stomach.

Compare this with Git, which seems complicated from the outside, but after a week working with it you feel completely in control. The repository model is simple to understand, and incnetworkingibly powerful. Because it's easy to get at the nuts and bolts, it's actually enjoyable to dig below the surface of your daily workflow.

For example, figuring out a trivial task such as how to just view a non-HEAD version of a file in a snapshot view took me a couple of hours and what I ended up with was a complete hack . Not the enjoyable sort of hack either.

But in Git, figuring out a seemingly complicated task such as how to interactively commit only some changes, (and leave the rest for later) was great fun, and all the time I have the feeling that the VCS is allowing me to organise code and history in a way that suits me, rather than history being an accident of how we used the VCS. "Git means never having to say 'you should have'" .

At my work, I use Git for all sorts of lightweight tasks, even within ClearCase. For instance, I do TDD, and I commit to Git whenever a bunch of tests pass and I'm about to refactor. When the task's eventually done, I check in to ClearCase, and Git helps me review exactly what I'm changing. Just try to get ClearCase to produce a diff across a couple of files – it can't! Use Google to find out the various hacks people have tried to work around this. This is something version control should do out of the box, and it should be easy! CVS has had this for decades!

  • Nightmare to administer in secure environments
  • Outdated technology
  • Non-intuitive GUI
  • Costoso
  • Resource monster
  • Sellout to Microsoft

In my opinion? Only reason to have it? If you are religiously following RUP.

The support is terrible. We've had tickets open for years. Our eclipse guru actually fixed a bug in their eclipse plugin locally in about 30 minutes by disassembling the java file. But the ticket still hasn't got past level one support. Every so often they either try to sneakily close it or ping it back to us 'to try on the latest version' (even though we sent them a reproduction recipe which they could try for themselves.).

Do not touch with a barge pole.

Actuación.

ClearCase is powerful, stable (IF properly maintained and supervised) but it's slow. Geological sometimes.

Dynamic views views lead to horrible build times, snapshot views can take ages to update (lunch break for large projects) or checkout (go home for the day).

  • The developers will spend 1/2 their time figuring out clearcase before doing any work and once they've figunetworking it out they'll install git locally and only push to the clearcase repo as needed.

  • You'll have to employ a dedicated Clearcase admin.

I would suggest SVN for toolset and Git for scaling/workflow. I'd also suggest avoiding CC where possible. (Not counting money, the fact it is such a pain to use that is requires a full time admin is a total joke)

I recently had to wrangle with a similar situation. Maybe you can learn from my story.

The team I was newly assigned to was using a heavyweight tool in an convoluted, error-prone manner. I first attempted to sell them on my tools and processes of choice. This attempt failed miserably. I was flabbergasted that they would pick such a burdensome environment over one that was both easier and more effective. Turns out that they wanted to be disciplined, and using a painful process felt disciplined to them. It sounds wierd, but it's true. They had a lot of other misconceptions too. After I figunetworking out what they were after, we actually stuck with the same tool suite (Serena), but massively changed how it was configunetworking.

My advice to you is to figure out what matters to your team. Ripping on ClearCase won't get you anywhere unless you speak to their interests. Also, find out why they don't want to use alternatives. Basically do a little requirements gathering and fit your tool choices to your needs. Depending on your options, who knows, Clear Case may end up being the best option after all.

I'm not totally against ClearCase ( it does have it's advantages ), but to list out the disadvantages:

  • License Limitations – I can't easily work from home, because I don't have access to the license server. Even with a snapshot view on my laptop I have to play tricks because I can't get a license. There is a special remote client, but adds tons of its own limitations to the mix
  • License Limitations again – Only so many seats to go around, and then no one can use it.
  • Unix tools out of date – ClearCase seems to run best on Unix systems, but the GUI tools suck there. Windows/Unix integration of ClearCase introduces all sorts of its own pains.

The biggest downfall for me is both the performance (especially if your VOB is multisite or offsite), and potentially lengthy downtimes.

If you're like me and work in a relatively small office as part of a large company (with no onsite IT), Clearcase servers going down can cost you the better part of a workday in non-productivity as well as getting the right people to get it fixed.

Bottom line, use it only if you really need it for what you are doing and make sure you have a beefy IT budget to maintain it.

ClearCase is perfectly usable if your willing to also use another version control system on top of it! personally I find using mercurial ontop of CC to work quite well.

  1. no atomic checkins

As of the new version of version 7.1 CC provides atomic checkin as functionality IF you like that. Personally I would really not want it but apparently some people see that as "an essential feature". I NEVER would want one big bulk in one go as a sort of massive version. Then again… if you want it just turn it on.

so… no longer an argument.

We used UCM ClearCase integrated with ClearQuest (DR Tracking/change request system) for the last 4 years with more than 50 developers. We have over 50 UCM projects over thousand of streams that handled over 35K DRs and change requests. During this period we have officially made over 600 integration deliveries and while having up to 6 concurrent development and release efforts.

I am the main CM/ClearCase guy with a backup who is able to perform the regular delivery/merge and integration builds. The network and servers are supported by the IT team. All I can say is we have had virtually no problems coming from the CM side of this huge development effort and were never a show stopper. Our developers where trained with just the basic stuff and a simple steps were given to them whenever a new project (branch) was created at the request from the project management.

Too many developer complained about ClearCase because they lack the proper CM/IT/ClearCase/Process/Management support. Developers should focus on development not SCM or be a tool specialist. For a large software development, at least 5-7% of the budget should be spent on CM and tool support.

Running a JDK from a VOB in Linux.

Try it, you need to play with the LD_PRELOAD variable (I know!)

the point of "it needs a dedicated person" and "it is complicated" etc….

The core issue here with finding this a problem is that you have to define if you want to have configuration management performed in your organization (which is NOT version management). Configuration Management is like Project Management: even without a tool you still can do project managment and without a tool you can do Configuration Management. Lots of people have a hard time understanding this and lots of people think Configuration Management is equal to a tool which versions sources of software or something…… (therefore comparisons with subversions or other VERSION management systems)

ClearCase is a solution that is build for usage in a Configuration Management environment ERGO: there is a configuration manager (just like "there is a project manager").

So… if in your perception that dedicated person is there to manage a tool I think there is something very wrong. In my perception there is a dedicated person who does configuration management who from an end-user perpective only shows up when there is a problem with the tool but regards this as only 1% of his job.

So what you need to do (like in any other software project) go back to your requirements and put a list of requirements together on what your organisation wants with configuration management. AND YES like in any other software project you will have users (like eg developers) who totally not agree with other users (like eg management) on certain requirements. There lies the key imho on some reactions I read here.

And IMHO if you have the organization list of requirements AND a configuration manager in the mix…. the choice is pretty clear (see also the forum on http://www.cmcrossroads.com)

ClearCase is not a tool only for end-users entering their sources under version control like subversion or git. That is only 1% of why a configuration manager really wants a mature configuration management tool.

And… I think the choice of a CM system should never lay with developers equal to choosing the right project management tool or the right CRM system. Developers are end-users of a certain part of the functionality of the tool.

I will be maybe alone here, but ClearCase is not that bad as everyone says. It can handle huge repositeories. Dynamic view are pretty cool and powerful feature too. It is reliable, can be customized by adding triggers and constraints on a pef file basis, permissions, etc.

Unfortunatelly, it comes with a price, big price. It is costly, and to operate properly needs to be properly configunetworking and maintained by dedicated IT team. It makes it really good for BigCo, but not so wise choice for SmallFirm.

I'm a big fan of DVCS and git, but can understand why would BigCo choose ClearCase over SVN and Git. What I can't understand why would anyone choose SVN over Git ;>

Dynamic Views. Must admire a fully functional translucent file system.

One big benefit is that the Intellectual Property is always in the corporate network. A laptop can be lost/stolen and no source code in jeopardy.

Another is the instant access to source code and changed files, no time is ever spent downloading anything.

It serves well for the purpose it has.