▷Diferencia entre GIT y CVS ✔️ Foro Ayuda 【 2024 】

Solución:

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

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

Configurar repositorio. Git almacena el repositorio en .git directorio en el directorio superior de su proyecto; CVS requiere configurar 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 importar fuentes existentes al 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 en su 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 deshaga) o deshacer entero cambio; Otra consecuencia es que en CVS es fácil realizar comprobaciones parciales, mientras que actualmente es casi imposible en Git. El hecho de que los cambios sean por archivo, agrupados llevó a la invención del formato GNU Changelog para los mensajes de confirmación en CVS; Los usuarios de Git usan (y algunas herramientas de Git esperan) una convención diferente, con una sola línea que describe (resume) el cambio, seguida de 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 archivos: números de versión (como puede ver a veces en expansión de palabras clave, ver más abajo) como 1.4 refleja cuántas veces se ha cambiado el archivo dado. En Git, cada versión de un proyecto como un todo (cada confirmación) tiene su nombre único dado por el id SHA-1; por lo general, los primeros 7-8 caracteres son suficientes para identificar una confirmación (no puede usar un esquema de numeración simple para las versiones en el sistema de control de versiones distribuido, que requiere autoridad central de numeración). En CVS, para tener un número de versión o un nombre simbólico que se refiera al estado del proyecto en su conjunto, se 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. En mi opinión, las sucursales en CVS son demasiado complicadas y difíciles de manejar. Debe etiquetar las ramas para tener un nombre para una rama completa del repositorio (e incluso eso puede fallar en algunos casos, si mal no recuerdo, debido al manejo por archivo). Agregue a eso el hecho de que CVS no tiene seguimiento de fusión, por lo que debe recordar o etiquetar manualmente las fusiones y los puntos de ramificación, y proporcionar manualmente la información correcta para “cvs update -j” para fusionar las ramificaciones, lo que hace que la ramificación sea innecesariamente difícil de usar. En Git, crear y fusionar ramas es muy fácil; Git recuerda toda la información requerida por sí mismo (por lo que fusionar una rama es tan fácil como “git merge nombre de rama“) … tenía que hacerlo, porque el desarrollo distribuido conduce naturalmente a múltiples ramas.

Esto significa que puede utilizar ramas temáticas, es decir, desarrollar una característica separada en varios pasos en una rama de característica separada.
Cambiar el nombre (y copiar) del seguimiento. Los cambios de nombre de archivos no son compatibles con CVS, y el cambio de nombre manual puede dividir el historial en dos o generar un historial no válido en el que no se puede recuperar correctamente el estado de un proyecto antes de cambiar el nombre. Git utiliza la detección de cambio de nombre heurística, 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:
- al examinar la confirmación especificada, obtendría información de que se cambió el nombre de algún archivo,
- la combinación correcta tiene en cuenta los cambios de nombre (por ejemplo, si el archivo se renombró solo en una rama)
- “git blame”, el (mejor) equivalente de “cvs annotate”, una herramienta para mostrar el historial de líneas del contenido de un archivo, puede seguir el movimiento del código también a través de los cambios de nombre
Archivos binarios. CVS solo tiene un soporte muy limitado para archivos binarios (por ejemplo, imágenes), lo que requiere que los usuarios marquen los archivos binarios explícitamente al agregarlos (o más tarde usando “cvs admin”, o mediante envoltorios para hacerlo automáticamente según el nombre del archivo), para evitar alterar los archivos. archivo binario mediante conversión de final de línea y expansión de palabras clave. Git detecta automáticamente archivos binarios en función del contenido de la misma manera que lo hacen CNU diff y otras herramientas; puede anular esta detección utilizando el mecanismo gitattributes. Además, los archivos binarios están a salvo contra alteraciones irrecuperables gracias al valor predeterminado de ‘safecrlf’ (y al hecho de que debe solicitar la conversión de fin de línea, aunque esto podría estar activado de forma predeterminada según la distribución), y esa palabra clave (limitada) La expansión es una ‘suscripción voluntaria’ estricta en Git.
Expansión de palabras clave. Git ofrece un conjunto muy, muy limitado de palabras clave 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 archivos que no cambiaron al cambiar a otra rama o rebobinar a otro punto del historial. Si desea incrustar el número de revisión usando Git, debe hacerlo usando su sistema de compilación, por ejemplo, siguiendo el ejemplo del script GIT-VERSION-GEN en las fuentes del kernel de Linux y en las fuentes de Git.
Modificación de confirmaciones. Porque en VCS distribuido como Git act de publicación es independiente de la creación de una confirmación, se puede cambiar (editar, reescribir) una parte no publicada del historial 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 una gran piratería) 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 usar 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 colabora con al menos otro desarrollador, también encontrará las siguientes diferencias entre Git y CVS:

Comprometerse antes de fusionar Usos de Git confirmar antes de fusionar en lugar de, como CVS, fusionar antes de comprometerse (o actualizar-luego-confirmar). Si mientras estaba editando archivos, preparándose 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 lo obliga a actualizar primero su directorio de trabajo y resolver los conflictos antes de permitirle realizar la confirmación. Este no es el caso de Git. Primero se compromete, guardando su estado en el control de versiones, luego fusiona otros cambios del desarrollador. También puede pedirle al otro desarrollador que realice la fusión y resuelva los conflictos.

Si prefiere tener un historial lineal y evitar fusiones, siempre puede usar comprometerse-fusionar-volver a comprometer flujo de trabajo a través de “git rebase” (y “git pull –rebase”), que es similar a CVS en el sentido de que reproduce los cambios además del estado actualizado. Pero siempre te comprometes primero.
Sin necesidad de repositorio central Con Git no es necesario tener un lugar central único donde realizar los cambios. Cada desarrollador puede tener su propio repositorio (o mejores repositorios: uno privado en el que realiza el desarrollo y uno público desnudo donde publica la parte que está lista), y pueden extraer / recuperar de los demás repositorios, en moda simétrica. Por otro lado, es común que los proyectos más grandes tengan socialmente repositorio central definido / nominado del que todos extraen (obtienen cambios).

Finalmente, Git ofrece muchas más posibilidades cuando se necesita la colaboración de 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 control de versiones usando CVS o Git):

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

Git admite aquí anónimo no autenticado acceso de solo lectura a través de eficiente personalizado git://protocolo, o si está detrás del bloqueo de firewall DEFAULT_GIT_PORT (9418) puede utilizar HTTP sin formato.

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 contraseña vacía. Las credenciales se almacenan de forma predeterminada 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 molestia.
desarrollador marginal (colaborador de hojas). Una forma de propagar sus cambios en OSS es enviar parches por correo electrónico. Esta es la solución más común si es (más o menos) un desarrollador accidental, envía un solo cambio o una única corrección de errores. POR CIERTO. El envío de parches puede realizarse a través del 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 el remitente (cliente) como para el mantenedor (servidor). Para las personas que desean enviar sus cambios por correo electrónico, existe la herramienta “git rebase” (o “git pull –rebase”) para reproducir sus propios cambios en la parte superior de la versión actual, por lo que sus cambios están en la parte superior de la versión actual (son nuevos ) y “git format-patch” para crear un correo electrónico con mensaje de confirmación (y autoría), cambio en forma de formato de diferencia unificado (extendido) (más diffstat para una revisión más fácil). El encargado de mantenimiento puede convertir dicho correo electrónico directamente en un compromiso conservando toda la información (incluido el mensaje de confirmación) utilizando “git am”.

CVS no ofrece tales herramientas: puede usar “cvs diff” https://foroayuda.es/ “cvs rdiff” para generar cambios, y usar el parche GNU para aplicar cambios, pero hasta donde yo sé, no hay forma de automatizar la aplicación. cometer mensaje. CVS estaba destinado a ser utilizado en la moda cliente <-> servidor …
teniente. Si es responsable de una parte separada de un proyecto (subsistema), o si el desarrollo de su proyecto sigue el flujo de trabajo de “red de confianza” utilizado en el desarrollo del kernel de Linux … o simplemente si tiene su 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 esta forma de colaboración. Incluso hay una herramienta llamada “git request-pull” que ayuda a preparar el correo electrónico para enviarlo al mantenedor con una solicitud para extraerlo de su repositorio. Gracias a “git bundle” puedes usar este mecanismo incluso sin tener un repositorio público, mediante el envío de paquetes de cambios por correo electrónico o sneakernet. Algunos de los sitios de alojamiento de Git, como GitHub, tienen 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 una especie 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 distribuidos, ya que tener varios desarrolladores con acceso de escritura al repositorio central no solo es un flujo de trabajo posible (puede tener un único responsable de mantenimiento que empuja cambios en el repositorio canónico, un conjunto de tenientes / mantenedores de subsistemas de los que se extrae, y una amplia gama de desarrolladores hoja que envían parches por correo, ya sea a la lista de correo del mantenedor / proyecto, oa uno de los tenientes / submaintainers).

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

Con CVS existe la posibilidad de elegir entre 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 significa confirmar sus cambios (crear confirmaciones). Bueno, también puedes tunelizar el protocolo ‘pserver’ usando SSH, y hay herramientas de terceros que automatizan esto … pero no creo que esto sea tan fácil como, por ejemplo, la gitosis.

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

Karl Fogel en Producing Open Source Software en la sección sobre control de versiones afirma que es mejor no proporcionar controles demasiado estrictos, rígidos y rigurosos en á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 distribuidos reducen eso en mi humilde opinión aún más …

HTH (Espero que ayude)

El sitio web de Git probablemente lo explica mejor.

Mi función de mascota es poder realizar confirmaciones cuando no estoy conectado. Y la velocidad, la enorme velocidad a la que ocurre 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 repositorio central está retrasado). gitk es un visor de historia suficientemente bueno; git gui es una herramienta de confirmación suficientemente buena; con colorización de salida, git add -i, git add -p, git rebase -i son interfaces interactivas suficientemente buenas; git daemon y git instaweb son lo suficientemente buenos para la colaboración ad-hoc si no quiere o no puede jugar con su repositorio central.

Git es un DVCS, a diferencia de CVS que es centralizado. La descripción simplista será: obtienes todos los beneficios del control de versiones cuando no estás conectado a alguna de múltiples repositorios posibles, además de que las operaciones son más rápidas.

¡Haz clic para puntuar esta entrada!

(Votos: 0 Promedio: 0)

Diferencia entre GIT y CVS

Solución:

Utiliza Nuestro Buscador

Preguntas Relacionadas: