control clearquest based version-control clearcase

version-control - clearquest - rational clearcase wiki



Ventajas/desventajas de ClearCase (30)

  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.

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.

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 recuerda las decisiones que tomaste, es solo una diferencia glorificada.

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

  3. Utilizo BitKeeper en el trabajo (supongamos que Git) y fusionar dos repositorios incluso si hay conflictos es tan trivial y fácil de usar incluso con línea de comandos, mientras que ClearCase tiene toneladas de herramientas GUI es un proceso 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 archivo requiere una conexión de alta velocidad. Por lo tanto, al hacer clic derecho en la herramienta ClearCase en un archivo 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 red.

  5. Alguien puede estropear completamente el repositorio o los registros si hacen que sus especificaciones de vista sean diferentes a las del equipo. Lo cual es una locura que nadie puede verificar alguna rama; 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 tiempo 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 copiarlas 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 tiempo. 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 camino 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 hormigas. Cada hormiga es solo un pequeño inconveniente en el mejor de los casos, pero la infestación te volverá loco.

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 de las que tengo conocimiento que usan ClearCase parecen tener al menos 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 tiempo completo también es preocupante.

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 solicitudes 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 plazo. 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 exportación mínima que hicimos tomó suficiente tiempo).

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

Estoy tratando de 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 te presento 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 documentación, 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 servidor VOB. Puede tener muchos servidores 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 archivos o versiones de repositorios? Esta es una pregunta bastante importante, y que necesariamente filtrará un conjunto completo de herramientas, facilitando su trabajo. Repository versioning has a lot of advantages (and it''s not "new", like some posters claimed - commercial tools like Perforce have been around for more than a dozen years, and there may have been tools that did repository versioning even before Perforce), but it isn''t a panacea.
  • With a sufficiently large installation of any source control system, you''re going to need help. 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 stored 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

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

A veces hacemos un directorio completamente nuevo lleno de archivos 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 archivos.

ClearCase posee los archivos y las carpetas, por lo que no puede modificar nada a menos que lo haya comprobado primero. El plugin Eclipse quita muchas molestias aquí. No puedo decirte cuántas veces abrí un archivo 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 conjuntos de cambios. Cuando actualiza con una vista de instantánea, cada archivo se actualiza, no solo los archivos modificados. Trabajé en un proyecto con más de 20,000 archivos. 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 menos 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ó archivos 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 eventos divertidos o equipos nuevos ( sillas, monitores, etc.). IBM recomienda tener personal para mantener en marcha ClearCase. ¿Por qué no rediseñ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á tiempo 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 migración será dolorosa
  • 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 conjuntos 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 resto es ramificar archivos individuales, mientras mantiene a los demás en la misma pista que otra rama.

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 documentación 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 comando ClearCase en un shell de UNIX, el comando "cd" falló con un mensaje de error.

La tarea básica de un sistema de control de versiones es realmente bastante simple. Honestamente, creo que media docena de comandos deberían ser suficientes, usando un esquema de archivos que funciona bien con otros. Para mí, ClearCase parece el resultado de un ejecutivo de marketing que complica deliberadamente las cosas para hacer 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 servicios de un experto. De fábrica, es como una navaja suiza motorizada.

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 compilaciones 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 duplicados de todo. Buen trabajo Rational / IBM. Manera de capturar la parte más importante del control de fuente, confiabilidad. Muere lento.

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 centradas en archivo

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

Las operaciones de archivo por archivo 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 cuenta es su aspecto centralizado (aunque puede ser "distribuido" con su función VOB replicada de múltiples sitios)
Si la red no permite el acceso a los VOB, los desarrolladores pueden:

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

Opción VCS distribuida costosa

Puede tener alguna característica 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 buscar líneas de base, no puede buscar 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 proceso de instalación es bastante complicado (aunque el último Administrador de instalación 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 coherencia

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 red sin tener que copiarlos 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:

Políticas limitadas con Base ClearCase

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

  • crear una rama (de lo contrario, cualquier persona puede crear cualquier rama, y ​​usted termina con un gazillon de ellos, con una pesadilla de flujo de trabajo de fusión)
  • ponga etiquetas (de lo contrario, se olvida de etiquetar algunos archivos, o coloca una etiqueta donde no se suponía que debía hacerlo, o "mueve" (jadea) una etiqueta de una versión a otra: al menos 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 reducido 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 servicio de TI para que se registren correctamente.
Agregue a eso un entorno heterogéneo (usuarios en Windows y servidor en Unix), y necesita registrar su usuario en Unix y en Windows. (con el mismo nombre de inicio de sesión / grupo). A menos 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 comandos 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 directorios 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 solicitud de red al proceso view_server que gestiona su servidor 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 servidor centralizado: eso significa que todo el proceso 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 servidor. Se puede hacer si la infraestructura es "correcta" (LAN especial de alta velocidad, servidor dedicado, monitoreo constante), pero en la práctica, su LAN no admitirá este modo.

El primer modo significa: debe hacer una copia de seguridad de su trabajo en progreso (archivos privados o archivos desprotegidos)
El segundo modo significa: su estación de trabajo puede no estar disponible, puede simplemente iniciar sesión en otra y recuperar sus vistas (a excepción de los archivos 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 rama para lograr el aislamiento verdadero del código (se necesitarán fusiones en algún momento, lo que ClearCase maneja muy bien, aunque lentamente, archivo por archivo)

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 " ramas de tareas para aislar un pequeño esfuerzo de desarrollo por rama: de ese modo un" pequeño equipo "(un subconjunto de su gran equipo) ) puede trabajar eficientemente, compartiendo rápidamente su trabajo entre sus miembros.
Si usa vistas dinámicas en una rama "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 archivos (puede usar una vista dinámica para modificar sus especificaciones de configuración hasta que vea lo que desea y luego copiarlas) reglas en su vista de instantánea habitual)
  • una vista lateral para hacer 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 configuración"), para evitar tener una fusión fallida debido a los archivos 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 archivos (no pagados) se leen a través de la red .
Eso significa que se accederá a la dll, jar o exe que necesita su IDE a través de la red, lo que puede ralentizar considerablemente el proceso de compilación.
Soluciones posibles:

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

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

He usado SVN, CVS, Clearcase y Mercurial.

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 red no funciona, no podrá acceder a su copia 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 archivos "secuestrados" todo el tiempo, por lo que los archivos en su copia de trabajo nunca son exactamente los mismos que en el repositorio 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 tiempo 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 iconos bonitos (?), La GUI es muy pobre , ¡hasta cosas como no poder cambiar el tamaño de Windows para ver rutas de archivos completas!
  • Su personal de soporte es bastante reacio a arreglar cualquier cosa. Su primera respuesta es siempre " esto es por diseño " 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.

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.

Sin compromisos atómicos

Una vez que haya registrado los archivos, es muy difícil revertir a un estado determinado, porque las confirmaciones atómicas no son compatibles. Al registrar múltiples archivos, cada archivo recibe una nueva revisión (similar a CVS) y no el registro mismo. Creo que esta es una característica crucial, ya que difícilmente se desea revertir archivos individuales, sino completar acciones de confirmación (que deben mapear tareas). Con ClearCase, solo puede volver a ciertos estados mediante el uso de etiquetas. En la práctica, el uso de etiquetas de ClearCase para cada registro 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 comando cleartool utilizada con cygwin es mucho mejor, pero todavía hay algunas cosas que no están disponibles, como añadir recursivamente nuevos archivos / 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 archivos frescos para su vista de instantánea toma alrededor 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 archivos y quieres registrarlos o actualizarlos. Check-out, check-in y agregar a los ciclos de control de fuente toman alrededor de 10-15 segundos, lo cual es obviamente una pesadilla. Se vuelve muy molesto cuando estás refabricando cambiar el nombre / mover tipos o métodos (muchos archivos 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 archivo / carpeta) requiere que esté conectado a la red. Aquí podría usar la opción de secuestro, pero esto es más bien una solución alternativa (básicamente, desbloquea el archivo en el sistema de archivos). Si sus sitios de desarrollo están muy lejos de su servidor ClearCase, la latencia de check-in / check-out puede incluso aumentar 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/

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.

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 incredibly 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!

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 figured out what they were after, we actually stuck with the same tool suite (Serena), but massively changed how it was configured.

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 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 configured and maintained by dedicated IT team. It makes it really good for BigCo, but not so wise choice for SmallFirm.

Soy un gran admirador de DVCS y git, pero puedo entender por qué BigCo elegiría ClearCase sobre SVN y Git. Lo que no puedo entender es por qué alguien elegiría SVN en vez de Git;>

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''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.

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
  • Disparadores
  • 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, restore, 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 compilable, because several files successfully got checked in and others do not. And after that it still lies not compilable 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

Performance.

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).

Running a JDK from a VOB in Linux.

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

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.

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.

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.

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 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.

Vistas dinámicas. Debe admirar un sistema de archivos translúcido completamente funcional.

Un gran beneficio es que la propiedad intelectual siempre está en la red corporativa. Se puede perder / robar una computadora portátil y no hay código fuente en peligro.

Otro es el acceso instantáneo al código fuente y los archivos cambiados, nunca se pierde tiempo descargando nada.

Sirve bien para el propósito que tiene.

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

¿En mi opinión? Only reason to have it? If you are religiously following RUP.

  • The developers will spend 1/2 their time figuring out clearcase before doing any work and once they''ve figured 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.