Argumentos para convencer a cambiar de CVS a SVN

Question

El departamento de UNIX de mi empresa actualmente utiliza CVS como sistema de control de versión de origen. Lo usan de manera muy extraña : diferentes repositorios para código de desarrollo/prueba/producción (para el mismo proyecto), nadie etiqueta nada, arquitectura de directorio extraño, etc.

El sistema se ha configurado por años pero ahora, tengo la oportunidad de organizar una reunión en la que tengo que sugerir cambios. Me gustaría hacerles cambiar de CVS a SVN (Mercurial o Git pueden ser incluso mejores, sin embargo, no puedo realmente recomendar utilizar un sistema que no conozco bien, y cambiar a SVN ya será un gran paso adelante).

no tengo mucha experiencia con CVS, así que no puedo comparar de manera eficiente: sólo sé que no es compatible operaciones atómicas y que es DEPRECATED.

¿Qué asesino argumentos usaría para convencer a mis colegas para que hagan el cambio?

Muchas gracias.

Answer 1

Hmm, esta configuración suena como un VCS distribuido, por lo que Mercurial o Git pueden coincidir muy bien. Multi-repository-setup es su especialidad. Personalmente prefiero Subversion, pero en tu caso deberías echarles un vistazo, hginit puede ser una buena introducción a Mercurial.

De todas formas, los argumentos para el cambio:

• compromete atómicas
• mejor manejo de archivos binarios
• control de versiones de directorios (solamente SVN)
• propiedades de archivos y directorios (solamente SVN)

Answer 2

Para ser honesto, si tiene que esforzarse mucho para convencerlos, entonces es probable que esperen que falle (aunque sea de manera inconsciente) y que su esfuerzo sea mejor empleado en otro lado.

Comenzaría a usar hg, git u otro DVCS localmente (confirmando los repositorios CVS del departamento) para que pueda familiarizarse con ellos. Debido a su naturaleza distribuida, puede comenzar a darse cuenta de los beneficios, comenzar a mostrar los beneficios a los colegas individualmente, y eventualmente hacer una buena defensa de la conversión respaldada por la experiencia real dentro de sus proyectos.

Answer 3

En realidad, los compromisos atómicos son un factor decisivo, no una característica sabrosa. Por ejemplo, desea confirmar 50 archivos modificados. Con SVN, usted svn commit y sucede que la red falla en el medio de la confirmación: su confirmación será ignorada. Con CVS tendrá la mitad del compromiso en el repositorio, por lo que ahora todo el mundo se actualizará al código dañado y se volverá infeliz, y la compilación diaria puede fallar y hacer que todos estén aún más descontentos. Con svn, o bien tienes un commit exitoso, o parece que nunca has pensado en el commit - el repositorio está siempre intacto.

Answer 4

La pregunta es: ¿qué problemas específicos se experimentan con la configuración actual de CVS? Sus razones para el cambio deberían abordarlas. Pero si no experimentan ningún problema, cambiar por causa del cambio no es una buena idea. CVS realmente hará el trabajo en muchos casos. Y si son chicos de UNIX de antaño, probablemente recuerden algunos de los sistemas de control de versiones realmente horribles del pasado, ¡y piensen que CVS es bastante limpio!

Answer 5

Cambio de nombre de archivo/mudanza! Tomado solo, dudo que esta sea una razón de peso para cambiar, pero sí tuvo serias implicaciones en un proyecto en el que estuve una vez.

Ver, CVS no le permite renombrar/mover archivos. Si cambia el nombre o mueve un archivo, CVS piensa que el antiguo desapareció y apareció el nuevo, y que no hay conexión entre ellos. Aunque no hay real pérdida de historial de revisión, debe saber que "Archivo X" en realidad era "Archivo Y" si retrocede antes de cierta fecha. Ah, y todos los números de versión se reinician.

El proyecto en el que estaba trabajando era una aplicación Java de código abierto que acababa de empezar pequeña y crecía y crecía, por lo que todo estaba en el paquete "core. *". Cuando llegó el momento de volver a factorizar y colocar cosas en una buena jerarquía de paquetes ... bueno, CVS restableció toda la información de la versión porque, en lo que respecta a , habíamos eliminado toda la carpeta "core /" y creado un montón de archivos nuevos de la nada.

Supuestamente, SVN es aware de los archivos que se mueven/renombrados, por lo que no se rompe el linaje de la versión. No sé si Git hace esto.