Suponiendo que está limitado a los dos sistemas de control de versiones (VCSS) que usted ha mencionado, Subversion (SVN) se sea más claro, más fácil y esté mejor respaldado en casi todos los aspectos, hasta llegar al punto en el que debe admitir múltiples ramas.
Cuando necesite combinar código (por ejemplo, corrección de errores) en múltiples versiones, soporte el desarrollo paralelo de cualquier característica de tamaño significativo o por un equipo un poco más grande de desarrolladores que ClearCase y más específicamente la capacidad de desarrollar en sucursales y fusionarlas juntos fácilmente, valdrá la pena todo el dolor adicional y la complicación, especialmente si ClearCase ya está siendo administrado para usted.
Experiencia
que he usado con ClearCase entre una persona (yo) y más de 400 personas, tiene muchas molestias del día a día, problemas de usabilidad y fallos pero siempre nos permite obtener trabajo hecho juntos. En todo momento, la instalación de ClearCase tenía administradores dedicados de tiempo completo.
He usado Subversion solo y con otra persona, y funciona muy bien día a día (sin administradores, excepto para mí) pero muy ocasionalmente pero consistentemente se convierte en una importante fuente de frustración debido al hecho no puede manejar ninguna situación significativa de ramificación y fusión.
¿Por qué SVN es deficiente para soportar el desarrollo paralelo y la ramificación?
SVN no admite el soporte de líneas de desarrollo paralelas porque tiene un soporte automatizado muy débil para fusionar ramas juntas. En contraste, todos los otros VCS sobre los que escribo tienen un buen soporte para fusionar ramas; para los casos comunes, es una operación de cero esfuerzo.
La ramificación es la forma en que los sistemas de control de versiones simulan la concurrencia en la vida humana (por ejemplo, dos desarrolladores trabajan en dos temas diferentes en paralelo o un desarrollador que tiene múltiples problemas abiertos al mismo tiempo). ¡Pero la ramificación es inútil si no puedes combinar fácilmente el trabajo de todos en un todo coherente!
La ramificación puede realizarse explícitamente (en el sentido de que el VCS la llama y entiende) o implícitamente (como una copia normal de los archivos o una salida). SVN es compatible con ambos, pero en SVN la bifurcación generalmente se realiza de forma implícita y limitada. Cada comprobación es una sucursal, pero todas las sucursales están obligadas a sincronizarse en cada confirmación/actualización. Esto sucede porque SVN no admite la fusión fácil de ramas explícitas y, por lo tanto, rara vez se crean ramas explícitas.
Como se ve obligado a sincronizar entre sí en cada compromiso, esto disminuye el paralelismo potencial dentro del equipo. También conduce a algunas prácticas de desarrollo menos que ideales, ya que no puede usar de manera efectiva el sistema de control de versiones para sus propias necesidades de desarrollo cotidiano. Termina siendo muy difícil probar diferentes ideas en sus ramas personales y no puede realizar varias confirmaciones mientras refina una función. También es más probable que se comprometa demasiado temprano y termine rompiendo el trabajo de todos los demás hasta que solucione el problema en su último compromiso.
El otro problema importante es que, como la fusión de las ramas explícitas no está bien soportada, SVN hace un mal trabajo ayudándolo a mover los cambios de código entre personas y entre sucursales. Imagine intentar solucionar un error tanto en la rama de lanzamiento como en la rama de desarrollo; alternativamente, imaginemos que dos desarrolladores están trabajando en una función relacionada y ambos necesitan cambios el uno del otro, pero solo en puntos controlados. Al usar SVN puede realizar estas tareas, pero el VCS hace muy poco para ayudarlo y debe estar preparado para preparar y mantener parches manualmente o enviar los archivos.
En los otros VCS, puede solicitar al VCS que combine una bifurcación que contenga una corrección de errores o una característica en varias otras ramas. Al final del día, todas estas ramas (que a su vez contienen el contenido de otras ramas) pueden fusionarse de nuevo en la rama principal. En la mayoría de los casos, la mayoría de esto será manejado de manera automática y correcta por el VCS, mientras que SVN tiene este tipo de flexibilidad automática y paralelismo es casi inimaginable.
Los equipos grandes realizan su trabajo sin un fuerte respaldo para la fusión automática, pero esto supone una carga mayor tanto para los individuos como para la organización del equipo, la comunicación y el proceso.
Por otro lado, la desventaja de la fácil bifurcación y fusión es que debe ser organizado y riguroso para fusionar los cambios a intervalos regulares, ya que ya no sucede automáticamente.
Otras opciones
Ahora bien, si damos un paso atrás y considerar otros sistemas, asumiendo su repositorio es principalmente basado en texto y relativamente pequeño (menos de unos pocos cientos de MBs), sugeriría que considerar seriamente el uso de BZR. BZR es al menos tan fácil de usar como SVN, especialmente si ya conoces SVN. También es al menos tan poderoso como ClearCase en todos los aspectos importantes desde la perspectiva de un desarrollador; admite múltiples flujos (ramas) de desarrollo y tiene un buen soporte para fusionarlos de nuevo. Al mismo tiempo, puede apoyar un estilo de desarrollo centralizado según sea necesario.
Aunque no tengo experiencia con él, también debo mencionar que puede usar la herramienta BZR para acceder a un servidor SVN con bzr-svn y esto le puede brindar muchos de los beneficios y funciones de combinación de BZR sin dejar de tener la ventaja de ser su código en la plataforma SVN ampliamente conocida.
Aunque recién sugerí BZR, en el mundo de los sistemas de control de versiones distribuidas (DVCS) de código abierto muchas personas parecen estar yendo con GIT. No sugerí esto, ya que obliga a una curva de aprendizaje mucho más pronunciada a los usuarios procedentes de SVN y creo que muchos equipos prefieren el mejor soporte de Windows y la facilidad de uso de BZR por encima de los beneficios de escalabilidad y velocidad de GIT. .
Si opta por un DVCS como BZR o GIT, probablemente no tenga que preocuparse demasiado por qué DVCS empiece a usar. Los sistemas ampliamente utilizados soportan exportar e importar entre sí y todos pueden al menos importar desde SVN.
¿Por qué siente que Subversion no es bueno para escenarios en los que necesitaría desarrollo paralelo y ramificación? – Manoj
Manoj: He actualizado mi respuesta para tratar de cubrir su pregunta. – Jared
'svn copy' se puede usar para bifurcar explícitamente y se pueden nombrar como se desee. 'svn merge' puede fusionar ramas nuevamente (no es que haga un gran trabajo). Aunque estoy en gran medida de acuerdo con su evaluación, SVN no facilita la fusión y el desarrollo paralelo, tengo que discrepar con "las ramas explícitas no están bien respaldadas" y las afirmaciones relacionadas como errores reales que desvirtúan su punto principal. No soy fanático, pero estoy trabajando en una rama de SVN en este momento, y otro equipo aquí comúnmente codifica en sucursales personales y se fusionan de nuevo al tronco cuando termina. –