Pregunta Diferencia entre GIT y CVS


¿Cuál es la diferencia entre los sistemas de control de versiones de Git y CVS?

He estado felizmente usando CVS por más de 10 años, y ahora me han dicho que Git está mucho mejor. ¿Podría alguien explicar por favor cuál es la diferencia entre los dos y por qué uno es mejor que el otro?


108
2018-04-29 14:19


origen


Respuestas:


La principal diferencia es que (como ya se dijo en otras respuestas) CVS es (antigua) sistema de control de versiones centralizado, mientras que Git se distribuye.

Pero incluso si usa el control de versiones para un único desarrollador, en una sola máquina (cuenta única), existen algunas diferencias entre Git y CVS:

  • Configurando el repositorio. Git almacena el repositorio en .git directorio en el directorio superior de su proyecto; CVS requiere la configuración de CVSROOT, un lugar central para almacenar información de control de versiones para diferentes proyectos (módulos). La consecuencia de ese diseño para el usuario es que la importación de fuentes existentes en el control de versiones es tan simple como "git init && git add. && git commit" en Git, mientras que es más complicado en CVS.

  • Operaciones atómicas. Debido a que CVS al principio era un conjunto de scripts alrededor del sistema de control de versiones RCS por archivo, las confirmaciones (y otras operaciones) no son atómicas en CVS; si una operación en el repositorio se interrumpe en el medio, el repositorio puede dejarse en un estado inconsistente. En Git todas las operaciones son atómicas: o tienen éxito como conjunto, o fallan sin ningún cambio.

  • Conjuntos de cambios. Los cambios en CVS son por archivo, mientras que los cambios (confirmaciones) en Git siempre se refieren a todo el proyecto. Esto es muy importante cambio de paradigma. Una de las consecuencias de esto es que es muy fácil en Git revertir (crear un cambio que deshace) o deshacer todo cambio; Otra consecuencia es que en CVS es fácil hacer revisiones parciales, mientras que actualmente es casi imposible en Git. El hecho de que los cambios se realicen por archivo y se agrupen dio lugar a la invención del formato de registro de cambios de GNU para los mensajes de compromiso en CVS; Los usuarios de Git usan (y algunas herramientas de Git esperan) diferentes convenciones, con una sola línea que describe (resume) el cambio, seguido por una línea vacía, seguida de una descripción más detallada de los cambios.

  • Nombrar revisiones / números de versión. Hay otro problema relacionado con el hecho de que en CVS los cambios son por archivo: números de versión (como se puede ver a veces en expansión de palabra clave, ver abajo) como 1.4 refleja la cantidad de tiempo que se ha cambiado el archivo. En Git cada versión de un proyecto como un todo (cada compromiso) tiene su nombre único dado por SHA-1 id; por lo general, los primeros 7-8 caracteres son suficientes para identificar una confirmación (no se puede usar un esquema de numeración simple para las versiones en el sistema de control de versiones distribuidas, que requiere autorización de numeración central). En CVS para tener un número de versión o un nombre simbólico que se refiera al estado del proyecto como un todo que usted usa etiquetas; lo mismo es cierto en Git si desea usar un nombre como 'v1.5.6-rc2' para alguna versión de un proyecto ... pero las etiquetas en Git son mucho más fáciles de usar.

  • Fácil ramificación. Las ramas en CVS son, en mi opinión, demasiado complicadas y difíciles de tratar. Debe etiquetar las ramas para tener un nombre para una rama de repositorio completa (e incluso eso puede fallar en algunos casos, si no recuerdo mal, debido al manejo por archivo). Agregue a eso el hecho de que CVS no tiene fusionar seguimiento, por lo que debe recordar o etiquetar manualmente los puntos de fusión y bifurcación, y proporcionar manualmente la información correcta para "cvs update -j" para fusionar las ramas, y hace que la bifurcación sea innecesariamente difícil de usar. En Git crear y fusionar sucursales es muy fácil; Git recuerda toda la información requerida por sí misma (por lo que fusionar una rama es tan fácil como "fusionar git" nombre de rama") ... tenía que hacerlo, porque el desarrollo distribuido naturalmente conduce a múltiples ramas.

    Esto significa que puedes usar ramas de tema, es decir, desarrollar una función separada en varios pasos en una rama de funciones separada.

  • Renombrar (y copiar) el seguimiento. Los cambios de nombre de archivo no son compatibles en CVS, y el cambio de nombre manual puede dividir el historial en dos, o llevar a un historial no válido donde no se puede recuperar correctamente el estado de un proyecto antes de cambiar el nombre. Git utiliza la detección heurística de redenominación, basada en la similitud de contenido y nombre de archivo (esta solución funciona bien en la práctica). También puede solicitar la detección de copia de archivos. Esto significa que:

    • cuando se examina la confirmación especificada, se obtiene información de que se renombró un archivo,
    • fusionarse correctamente lleva a cambiar el nombre de la cuenta (por ejemplo, si el archivo fue renombrado solo en una rama)
    • "git blame", el equivalente (mejor) de "cvs annotate", una herramienta para mostrar el historial de contenido de un archivo en línea, puede seguir el movimiento del código también a través de cambios de nombre
  • Archivos binarios. CVS tiene solo un soporte muy limitado para archivos binarios (por ejemplo, imágenes), requiriendo que los usuarios marquen archivos binarios explícitamente al agregar (o más tarde usando "cvs admin", o mediante envoltorios para hacer eso automáticamente basándose en el nombre del archivo), para evitar archivo binario mediante conversión al final de línea y expansión de palabra clave. Git detecta automáticamente el archivo binario basado en los contenidos de la misma manera que lo hace el diff de CNU y otras herramientas; puede anular esta detección usando el mecanismo de gitattributes. Además, los archivos binarios son seguros contra el mapeo irrecuperable gracias al valor predeterminado de 'safecrlf' (y al hecho de que debe solicitar la conversión al final de la línea, aunque esto podría activarse de manera predeterminada según la distribución), y esa palabra clave (limitada) la expansión es un estricto 'opt-in' en Git.

  • Expansión de palabras clave. Git ofrece un conjunto de palabras clave muy, muy limitado en comparación con CVS (por defecto). Esto se debe a dos hechos: los cambios en Git son por repositorio y no por archivo, y Git evita modificar los archivos que no cambiaron al cambiar a otra rama o rebobinar a otro punto en el historial. Si desea incrustar el número de revisión con Git, debe hacerlo utilizando su sistema de compilación, p. siguiente ejemplo de secuencia de comandos GIT-VERSION-GEN en fuentes de kernel de Linux y en fuentes de Git.

  • Enmendando confirma. Porque en VCS distribuidos como Git act of publicación es independiente de la creación de una confirmación, se puede cambiar (editar, reescribir) una parte inédita de la historia sin molestar a otros usuarios. En particular, si observa un error tipográfico (u otro error) en el mensaje de confirmación, o un error en la confirmación, simplemente puede usar "git commit --amend". Esto no es posible (al menos no sin hackers pesados) en CVS.

  • Más herramientas. Git ofrece muchas más herramientas que CVS. Uno de los más importantes es "git bisect"que se puede utilizar para encontrar una confirmación (revisión) que introdujo un error, si sus confirmaciones son pequeñas y autónomas debería ser bastante fácil descubrir dónde está el error.


Si colaboras con al menos otro desarrollador, también encontrarás las siguientes diferencias entre Git y CVS:

  • Comprometerse antes de fusionarse Git usa commit-before-merge en lugar de, como CVS, fusionar antes de comprometer (o update-then-commit) Si mientras editabas archivos, preparándote para crear una nueva confirmación (nueva revisión), alguien más creó una nueva confirmación en la misma rama y ahora está en el repositorio, CVS te obliga a actualizar primero tu directorio de trabajo y resolver conflictos antes de permitirte comprometer. Este no es el caso con Git. Primero se compromete, guardando su estado en control de versiones, luego combina otros cambios de desarrollador. También puede pedirle al otro desarrollador que realice la combinación y resuelva los conflictos.

    Si prefiere tener un historial lineal y evitar las fusiones, siempre puede usar commit-merge-recommit flujo de trabajo a través de "git rebase" (y "git pull - rebase"), que es similar a CVS en que se reproducen los cambios en la parte superior del estado actualizado. Pero siempre te comprometes primero.

  • No es necesario un repositorio central Con Git no hay necesidad de tener un solo lugar central donde comprometer sus cambios. Cada desarrollador puede tener su propio repositorio (o mejores repositorios: uno privado en el que él / ella hace el desarrollo, y el público en el que publica la parte que está lista), y puede extraer / buscar de otros repositorios, en moda simétrica. Por otro lado, es común que un proyecto más grande tenga socialmente repositorio central definido / nominado del que todos extraen (obtienen cambios).


Finalmente, Git ofrece muchas más posibilidades cuando se necesita colaboración con un gran número de desarrolladores. A continuación hay diferencias entre CVS en Git para diferentes etapas de interés y posición en un proyecto (bajo el control de versión usando CVS o Git):

  • mirón. Si solo está interesado en obtener los últimos cambios de un proyecto, (sin propagación de sus cambios), o haciendo privado desarrollo (sin contribuir a proyectos originales); o utiliza proyectos en el extranjero como base de su propio proyecto (los cambios son locales y no tiene sentido publicarlos).

    Git es compatible aquí anonimato no autenticado acceso de solo lectura a través de una eficiente personalizada git://protocolo, o si está detrás del bloqueo de firewall DEFAULT_GIT_PORT (9418) puede usar HTTP simple.

    Para CVS, la solución más común (según tengo entendido) para el acceso de solo lectura es Cuenta de invitado para el protocolo 'pserver' en CVS_AUTH_PORT (2401), generalmente llamado "anónimo" y con una contraseña vacía. Las credenciales se almacenan por defecto en $HOME/.cvspass archivo, por lo que debe proporcionarlo solo una vez; aún así, esto es un poco de barrera (debe saber el nombre de la cuenta de invitado, o prestar atención a los mensajes del servidor CVS) y la molestia.

  • desarrollador de franjas (colaborador de hojas). Una forma de propagar sus cambios en OSS es enviando parches por correo electrónico. Esta es la solución más común si usted es (más o menos) un desarrollador accidental, envía un cambio único o una sola corrección de errores. Por cierto. el envío de parches puede realizarse a través de un panel de revisión (sistema de revisión de parches) o medios similares, no solo por correo electrónico.

    Git ofrece aquí herramientas que ayudan en este mecanismo de propagación (publicación) tanto para remitente (cliente) como para mantenedor (servidor). Para las personas que desean enviar sus cambios por correo electrónico, existe "git rebase"(o" git pull --rebase ") herramienta para reproducir sus propios cambios sobre la versión actual de upstream, por lo que sus cambios se encuentran en la parte superior de la versión actual (son nuevos), y"git formato-parche"para crear un correo electrónico con mensaje de confirmación (y autoría), cambio en forma de formato unificado (extendido) (más diffstat para una revisión más fácil). El mantenedor puede convertir dicho correo electrónico directamente en confirmación conservando toda la información (incluido el mensaje de confirmación) usando"git am".

    CVS no ofrece tales herramientas: puede usar "cvs diff" / "cvs rdiff" para generar cambios y usar el parche de GNU para aplicar cambios, pero hasta donde yo sé, no hay forma de automatizar la aplicación del mensaje de confirmación. CVS estaba destinado a ser utilizado en la forma de cliente <-> servidor ...

  • teniente. Si eres mantenedor de una parte separada de un proyecto (subsistema), o si el desarrollo de tu proyecto sigue el flujo de trabajo de "red de confianza" utilizado en el desarrollo del kernel de Linux ... o solo si tienes tu propio repositorio público, y los cambios desea publicar son demasiado grandes para enviar por correo electrónico como serie de parches, puedes enviar solicitud de extracción al mantenedor (principal) del proyecto.

    Esta es una solución específica para repartido sistemas de control de versiones, por lo que, por supuesto, CVS no admite esa forma de colaboración. Incluso hay una herramienta llamada "git request-pull" que ayuda a preparar el correo electrónico para enviar al mantenedor con la solicitud de extracción de su repositorio. Gracias al "paquete de git" puede usar este mecanismo incluso sin tener un repositorio público, enviando paquetes de cambios por correo electrónico o sneakernet. Algunos de los sitios de alojamiento de Git como GitHub tener soporte para notificar que alguien está trabajando (publicó algún trabajo) en su proyecto (siempre que use el mismo sitio de alojamiento de Git), y para PM-ing tipo de solicitud de extracción.

  • desarrollador principal, es decir, alguien que publicar directamente sus cambios (al repositorio principal / canónico). Esta categoría es más amplia para los sistemas de control de versiones distribuidas, ya que tener múltiples desarrolladores con acceso de escritura al repositorio central no solo es un flujo de trabajo posible (puede tener un solo responsable que empuja cambios en el repositorio canónico, un conjunto de tenientes / mantenedores de subsistemas de los que extrae, y una amplia gama de desarrolladores de hojas que envían parches por correo electrónico a la lista de correo del desarrollador / proyecto, oa uno de los tenientes / submaintadores).

    Con Git tienes la opción de usar Protocolo SSH (protocolo git incluido en SSH) para publicar cambios, con herramientas como "git shell" (para ayudar a la seguridad, limitando el acceso de las cuentas shell) o Gitosis (para administrar el acceso sin requerir cuentas shell separadas), y HTTPS con WebDAV, con autenticación HTTP común.

    Con CVS hay una opción entre personalizado sin cifrar (texto sin formato)  pserver protocolo, o usando shell remoto (donde realmente deberías usar SSH) para publicar sus cambios, que para centralizado El sistema de control de versiones implica la realización de sus cambios (creación de compromisos). Bueno, también puede tunelizar el protocolo 'pserver' usando SSH, y hay tres herramientas de partido que lo automatizan ... pero no creo que sea tan fácil como, por ejemplo, Gitosis.

En general, los sistemas de control de versiones distribuidas, como Git, ofrecen una selección mucho más amplia de posibles flujos de trabajo. Con los sistemas de control de versiones centralizadas, como CVS, por necesidad debe distinguir entre las personas con acceso de commit al repositorio, y aquellos sin ... y CVS no ofrece ninguna herramienta para ayudar a aceptar contribuciones (a través de parches) de personas sin comprometer el acceso

Karl Fogel en Produciendo software de código abierto en la sección sobre control de versiones se afirma que es mejor no proporcionar controles demasiado estrictos, rígidos y rigurosos en las áreas donde se permite realizar cambios en el repositorio público; es mucho mejor confiar (para esto) en las restricciones sociales (como la revisión del código) que en las restricciones técnicas; Los sistemas de control de versiones distribuidas reducen aún más mi humildad ...

HTH (Espero que ayude)


298
2018-05-05 10:20



Esta charla de Linus (el autor original de git) lo resume bastante bien.

Google Tech Talks: Linus Torvalds en Git

Atención: Charla altamente dogmática.


14
2018-04-29 14:37



Git es un DVCS, en lugar de que CVS sea centralizado. La descripción simplificada será: usted obtiene todos los beneficios del control de versión cuando no está conectado a alguna de múltiples repositorios posibles, además las operaciones son más rápidas.


4
2018-04-29 14:23



El sitio web de Git explica esto mejor probablemente.

La característica de mi mascota es poder hacer commits fuera de línea. Y la velocidad, la velocidad absoluta a la que sucede todo, excepto empujar y tirar. (Y estas operaciones son, por diseño, no destructivas, por lo que puede empujar / tirar cuando vaya a tomar un café si su repo central está rezagado). Otra cosa buena es que viene con baterías incluidas: la batería incorporada gitkes un buen espectador de historia; git gui es una herramienta de compromiso lo suficientemente buena; con colorización de salida, git add -i, git add -p, git rebase -i son interfaces interactivas lo suficientemente buenas; git daemon y git instaweb son lo suficientemente buenos para una colaboración ad-hoc si no quieres / no puedes jugar con tu repositorio central.


3
2018-04-29 14:22



También soy un usuario mayor de 10 años de cvs, aunque también me gusta git, y con el tiempo llegaré a preferirlo, aunque la mayoría de los proyectos en los que trabajo actualmente usan cvs, o svn, y no podemos parecerlo. hacer que la burocracia en la que trabajo convenza para dejarnos perforar un agujero en el firewall.

Un par de cosas que hacen que los cvs sean más agradables de lo que podrían ser de otra manera son cvsps, y otro son los guiones de parches de Andrew Morton o colcha. Cvsps le permite reconstituir los múltiples archivos de una confirmación en un solo parche (y así extraer "conjuntos de cambios" de CVS) mientras que el parche o los scripts de Andrew Morton le permiten realizar "conjuntos de cambios" sensibles en cvs de manera fácil y cómoda, permitiéndole trabaje en múltiples cosas al mismo tiempo mientras las mantiene separadas antes de comprometerse. CVS tiene sus peculiaridades, pero estoy acostumbrado a la mayoría de ellos.


3
2018-05-16 01:38



"Usar feliz CVS por más de x años", es una idea interesante :-) Es un gran paso adelante por mantener muchas copias, pero ...

Supongo que te has acostumbrado a todos sus caprichos, o no haces muchas ramificaciones y uniones. Hay una posibilidad peor;

Las personas de su organización se han acostumbrado a las limitaciones de los cvs y sus prácticas laborales se han adaptado en consecuencia;

por ejemplo, nunca tener más de un desarrollador trabajando en un paquete a la vez, solo usando derivaciones en emergencias, etc.

El principio básico es que cuanto más difícil es algo, menos gente lo hace.


2
2018-05-05 10:59



Preguntas populares