svn - entre - Para proyectos en el hogar, ¿Mercurial o Git(u otro DVCS) pueden ofrecer más ventajas que Subversion?

subversion vs (9)

Además de los detalles acerca de las muchas características maravillosas de hg, git, darcs, bzr y amigos (sin sarcasmo, soy un gran fan), los elementos esenciales están aquí:

Con svn , debe elegir entre almacenar su repositorio externo y almacenarlo en el sitio. Onsite significa que si su disco falla su proyecto es tostado. Offsite significa que no puede comprometerse desde un avión u otras situaciones desconectadas, y cuando la conectividad de la red es mala, las confirmaciones pueden ser lentas.
Con cualquier VCS distribuido, es trivial crear uno o más "clones" de su "repo". Puede confirmar cambios localmente en cualquier momento, rápido y luego enviar esos cambios a un repositorio remoto cuando la conectividad esté disponible.

git, hg y otros están cargados con características (y características erróneas) que los hacen diferentes de svn y cvs. Pero esos son los esenciales.

¿Qué sistema de control de fuente libre es más preferible con motivo de los proyectos y documentos del hogar?

Estoy pensando en usar Subversion (ya que estoy familiarizado con esto).

Característica del proyecto casero:

Lo más probable es que una sola persona esté cometiendo cambios. (Puede ser un día (no ahora), es posible que comparta un proyecto con mi amigo que está en otra ciudad)
Me gustaría almacenar otros documentos (archivos que no sean de programación)

¿Mercurial o GIT (sistema de control de versiones distribuidas) puede darme más ventaja sobre la subversión en los proyectos domésticos?

Compartir proyectos es mucho más fácil con dvcs porque no necesita darles a otros acceso a su computadora de repositorio central. Puede hacer que cree una copia y no le permita hacer ningún commit en ningún lado si lo desea. Si quiere sus cambios, puede sacarlos de su computadora donde quiera, en lugar de permitir que los empuje. De esta manera, si lo desea, puede verificar primero los cambios. Usted tiene el control total (si lo desea).

¡El principal beneficio es que usted lleva todo el repositorio en su computadora portátil! Puede tomar un tiempo para apreciar lo que realmente significa cuando estás acostumbrado a repositorios centrales masivos y todas las complicaciones que lo acompañan. Por supuesto, en muchas situaciones es beneficioso tener uno pero, una vez más, puedes controlar quién tiene y qué tipo de acceso tiene. Con los vcs centralizados no permitiéndole a alguien comprometerse directamente con el repositorio central, se requiere mucho trabajo extra de algún desgraciado. Los commits tendrían que hacerse más o menos a mano, mientras que con los dvcs, el responsable de verificar el código comprometido puede comprometerlos de la misma manera que lo haría con su propio código.

Hay formas de facilitar lo anterior en vcs pero aún requieren mantenimiento adicional (crear componentes / vistas / lo que sea control de acceso y permitir commits a esto solamente). En git / mercurial realmente no hay nada de esto por encima.

Yo diría que cuanto más se hace el trabajo fuera de la red de su empresa, más dvcs beneficiosos son. Si todos tienen acceso rápido al repositorio central y se puede confiar en que todos sus cambios se realizarán allí, las principales fortalezas de los dvcs no son tan importantes (aunque todavía hay algunas, pero en este momento están equilibradas con la interfaz de usuario pobre disponible) .

Eche un vistazo a la parte sobre control de versiones para un solo desarrollador en mi respuesta a la pregunta " Diferencia entre GIT y CVS " aquí en . Algunos de esos problemas todavía se aplican también a Subversion versus Git (u otro VCS distribuido: Mercurial, Bazaar, o menos conocido: Monotone, Darcs), incluso si Subversion mejora respecto a CVS.

DESCARGO DE RESPONSABILIDAD: Yo uso Git (entonces soy parcial), y conozco Subversion solo de la documentación (y otros recursos), nunca la he usado yo misma. Es posible que me equivoque sobre las capacidades de Subversion.

A continuación hay una lista de diferencias entre Git y Subversion para un único desarrollador, en una sola máquina (cuenta única):

Configurando el repositorio. Git almacena el repositorio en .git directorio .git en .git directorio superior de su proyecto. Comenzar un nuevo proyecto desde un árbol de archivos no versionado es tan fácil como hacer "git init" en un directorio superior de su proyecto (y luego, por supuesto, "git add." Para agregar archivos, y por ejemplo "git commit -m ''Initial commit'' "para crear el primer compromiso".
En Subversion (en cualquier sistema de control de versiones centralizado) necesita configurar el repositorio central (a menos que lo haya hecho antes) usando "svnadmin create" (bueno, solo necesita hacer eso una vez). Luego debe importar archivos a Subversion usando "svn import" (o "svn add") ... Pero tenga en cuenta que una vez que la importación finaliza, el árbol original no se convierte en una copia de trabajo. Para comenzar a trabajar, aún necesita "svn checkout" una nueva copia de trabajo del árbol.
Metadatos de repositorio y repositorio. Git almacena tanto el repositorio (es decir, información sobre revisiones y sucursales, etc.) como los metadatos del repositorio (por ejemplo, su identidad, lista de archivos ignorados, qué rama está actualmente desprotegida) en .git directorio .git en .git directorio superior de sus proyectos.
Subversion almacena el repositorio en un área separada que tiene que poner para ese propósito, y almacena los metadatos del repositorio (por ejemplo, donde repositorio central está, identidad utilizada para contactar repositorio central, y creo que también propiedades como svn:ignore ) se almacenan en el directorio .svn en cada directorio de tu proyecto (Tenga en cuenta que Subversion almacena una copia prístina de su pago, para tener un "estado svn" rápido y "svn diff")
Nombrar revisiones / números de versión. Subversion utiliza identificadores de revisión globales en forma de revisión de especificación de número único (por lo que puede consultar, por ejemplo, r344, revisión 344). Subversion también admite algunos especificadores de revisión simbólicos: HEAD, BASE, COMITTED, PREV.
En Git, cada versión de un proyecto (cada commit) tiene su nombre único dado por 40 id hexadecimal 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). Pero Git ofrece también otros tipos de especificadores de revisión, por ejemplo HEAD^ significa parent de un commit actual, master~5 significa antecesores de revisión 5 atrás (en primera línea recta padre) desde commit superior en una rama ''master'', v1.6.3-rc2 podría significar revisión etiquetada v1.6.3-rc2 .
Ver también muchos tipos diferentes de especificadores de revisión publicación de blog por Elijah Newren.
Fácil ramificación y fusión. 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 "git merge branchname") ... tenía que hacerlo, porque el desarrollo distribuido naturalmente lleva a múltiples ramas. Git utiliza la detección de renombrado basada en la similitud heurística, por lo que, al fusionarse, puede tratar el caso en el que un archivo renombrado por un lado (y otros casos similares relacionados con el cambio de nombre). Esto significa que puede usar el flujo de trabajo de las ramas temáticas , es decir, desarrollar una función separada en varios pasos en una rama de funciones separada.
Las sucursales tienen una implementación inusual en Subversion; se manejan mediante una convención de espacios de nombres: una rama es la combinación de revisiones dentro del repositorio global que existe dentro de un cierto espacio de nombres. La creación de una nueva rama se hace copiando un conjunto existente de archivos de un espacio de nombres a otro, registrado como una revisión en sí misma. Subversion facilitó la creación de una nueva sucursal ... pero hasta la versión 1.5, tenía que usar herramientas adicionales, como las extensiones SVK o svnmerge, para poder fusionarse fácilmente. Subversion 1.5 introdujo la propiedad svn:mergeinfo , pero incluso entonces la fusión es un poco más complicada que en Git; también necesita usar opciones adicionales para mostrar y hacer uso de la información de seguimiento de fusión en herramientas como "svn log" y "svn culpa". He oído que no funciona correctamente en situaciones más complicadas (fusión entrecruzada), y que no puede tratar actualmente con cambiar el nombre (incluso hay posibilidad de corrupción silenciosa en tal caso). Ver también (por ejemplo) esta publicación en la lista de correo de git por Dmitry Potapov, explicando el caso de uso previsto para svn:mergeinfo y sus limitaciones (actuales).
Etiquetado Las etiquetas de Git son inmutables , pueden tener comentarios asociados con ellas y se pueden firmar con la firma de PGP / GPG (y verificadas). Se hacen usando "etiqueta git". Puede consultar la revisión utilizando el nombre de la etiqueta.
En las etiquetas de Subversion, use la misma convención de espacio de nombres similar a path_info como branches (la convención recomendada es svnroot/project/tags/tagname ), y no están protegidas contra el cambio. Se hacen usando "svn copy". Pueden tener comentarios asociados con [la confirmación creando una etiqueta].
Expansión de palabras clave Git ofrece un conjunto de palabras clave muy, muy limitado en comparación con Subversion (de manera predeterminada). 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 reajustar 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, por ejemplo, siguiendo el guión anterior de GIT-VERSION-GEN en las fuentes del kernel de Linux y en las fuentes de Git. También hay un atributo ''ident'' gitattribute que permite la expansión de la palabra clave "$ Id $" al identificador SHA-1 del contenido del archivo (no el identificador de una confirmación).
Tanto Git como Subversion hacen la expansión de palabras clave solo bajo pedido.
Archivos binarios Tanto Git como Subversion manejan correctamente los archivos binarios. Git realiza la detección de archivos binarios utilizando un algoritmo similar al utilizado por, por ejemplo, GNU diff, a menos que se modifique por ruta usando gitattributes. Subversion lo hace de una manera ligeramente diferente, detectando el tipo de archivo durante la adición de archivos y configurando la propiedad svn:mime-type , que luego puede modificar. Tanto Git como Subversion pueden realizar conversiones de caracteres de final de línea bajo demanda; Git tiene, además, la opción de configuración core.safecrlf que previene y previene el cambio irreversible (todos los CR a todos los CRLF son reversibles, CR mixto y CRLF no reversibles).
Ignorando archivos. Las tiendas de Git ignoran los patrones usando el archivo .gitignore en el árbol, que puede ponerse bajo control de versión y distribuirse; generalmente contiene patrones para productos de compilación y otros archivos generados, y en el archivo .git/info/excludes , que generalmente contiene patrones de ignorar específicos del usuario o del sistema, por ejemplo, ignorar patrones para los archivos de respaldo de su editor. Los patrones de Git se aplican recursivamente, a menos que el patrón contenga el delimitador de directorio, es decir, el carácter de barra diagonal ''/'', luego está anclado al directorio. .gitignore archivo de nombre de .gitignore es; to dir superior para .git/info/excludes . (También existe la variable de configuración core.excludesfile , esta variable puede existir en el archivo de configuración ~/.gitconfig por usuario y apuntar a un archivo de ignorar por usuario).
Subversion utiliza global-ignores opción de configuración de tiempo de ejecución global-ignores (que generalmente se aplica a una computadora particular o por un usuario particular de una computadora), y la propiedad " svn:ignore " en los directorios versionados por SVN. Sin embargo, a diferencia de la opción global-ignores (y en .gitignore ), los patrones encontrados en la propiedad " svn:ignore " se aplican solo al directorio en el que se establece esa propiedad, y no a ninguno de sus subdirectorios. Además, Subversion no reconoce el uso de ! prefijo al patrón como mecanismo de excepción.
Enmendando confirmaciones VCS distribuidos, como el acto de publicación de Git, es independiente de la creación de un compromiso; uno 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". (Nota: técnicamente está recreando una confirmación, no cambiando la confirmación existente, la confirmación modificada tiene un identificador diferente) .
Subversion solo permite modificar el mensaje de confirmación después del hecho, cambiando la propiedad apropiada.
Herramientas. Por un lado, Git ofrece un conjunto de comandos más completo. 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.
Por otro lado, Subversion porque existe más tiempo, tiene quizás un conjunto más amplio de herramientas de terceros, y soporte de Subversion en herramientas, que Git. O al menos más maduro. Especialmente en MS Windows.

Y hay otro problema, que podría ser bastante importante más adelante:

Repositorio de publicación. Si (¿cuándo?) En algún momento quisieras compartir tu repositorio, convirtiéndolo del proyecto de una persona desarrollado en una sola computadora doméstica, a algo que contribuya, con Git es tan simple como crear un repositorio vacío en el servidor o en uno de Sitios de hospedaje git existentes / sitios de alojamiento de software con soporte git (como http://repo.or.cz , GitHub , Gitorious , InDefero, más - también para otros DVCS - se enumeran en esa respuesta ), y luego presionando su proyecto a este repositorio público.
Supongo que es más complicado con Subversion, si no comienzas en el sitio de alojamiento de software con soporte de Subversion (como SourceForge) desde el principio, a menos que no quieras conservar el historial de revisiones existente. Por otro lado, por ejemplo, Google Code sugiere usar la herramienta svnsync (parte de la distribución estándar de Subversion), como se explica en el artículo Productos de Google> Alojamiento de proyectos (Frente de liberación de datos) .

Eche un vistazo también en el sitio http://whygitisbetterthanx.com/ .

No sé sobre mercurial, pero mi actividad favorita en git, que es imposible en subversión, es editar la historia. Por ejemplo, puedes:

edita confirmaciones anteriores para realizar cambios en la lista de archivos que se modificaron
cambiar el orden de las confirmaciones anteriores
eliminar confirmaciones de la historia en conjunto
fusionar dos o más confirmaciones juntas
dividir se compromete aparte
añadir cambios posteriores a confirmaciones anteriores

En resumen, si crees que deberías poder hacerlo, probablemente puedas. Esto es muy poderoso, una vez que se da cuenta de esta capacidad y es probablemente más importante en muchos aspectos que solo la ventaja distribuida.

Quiero enfatizar que Mercurial y GIT lo inician con el control de fuente sin necesidad de un servidor y facilita el traslado de su repositorio a otro servidor cuando sea necesario.

Otras ventajas han sido cubiertas en las otras respuestas.

Solía tener un servidor de subversión para la sincronización de inicio. Algunos años, he estado ejecutando git, pero ahora me estoy mudando a hg. La razón es principalmente simplicidad. Debería ser capaz de "dominar" git, pero aun así, no lo hago.

Aquí hay un gran tutorial de Joel (una de las mentes maestras de ) en hg.

Un beneficio obvio: puedes desarrollar cuando estás lejos del servidor. Por ejemplo, puede tener una computadora portátil con su propio repositorio git local y enviarla a su servidor (o github). Ahora supongamos que fue a un lugar sin conexión a Internet ... en Subversion tendría que arreglárselas sin ningún compromiso hasta que vuelva a conectarse. Con un DVCS puedes comprometer localmente (y revertir, rama, etc.) y luego volver a enviar esos commits cuando llegues a casa.

Una gran ventaja de git y mercurial en un entorno de ''proyecto de origen'' es que un nuevo repositorio es de configuración trivial. En git simplemente haces git init en la raíz de tu árbol de códigos y tienes un nuevo repositorio.

Luego puede agregar, comprometer, bifurcar, etc. directamente. svn tiene un costo mayor de configurar ya que necesita una ubicación de repositorio y url separados antes de poder crear una copia de trabajo e iniciar sus operaciones de VCS habituales.

Almacenar documentos no es un problema en git o mercurial, pero sin duda con git (no estoy seguro acerca de hg). Aconsejaría no almacenar archivos de medios grandes (desde 100M hacia arriba) ya que tiende a no funcionar muy bien en algunas operaciones.

Uso git en proyectos personales para "colaborar conmigo mismo". Tengo repositorios en un linux box en mi red doméstica a la que se puede acceder a través de un túnel desde cualquier lugar. Luego lo clonaré en el escritorio de mi casa, mi computadora portátil, tal vez una máquina en el trabajo, y puedo verlo o trabajar en él en cualquier lugar que vaya. Puedo enviar cambios, obtener lo último y tener copias de seguridad en varios lugares. Es muy agradable la facilidad y velocidad con que git te permite cambiar de rama. Encontrado un error? Cambia a ''maestro'', arréglelo, comprométalo, presiona y luego vuelve a lo que estás haciendo. Más fácil y más rápido que cvs o subversión.

Además, uso git mucho para directorios pequeños que ni siquiera son proyectos. El directorio config para el servidor apache que hospeda mi sitio web es git''d, y también el directorio de configuración de tomcat para el mismo sitio web.

Lo uso en el trabajo para todo, aunque en el trabajo estamos en CVS moviéndonos a Subversion. No uso git-cvs o git-svn, solo uso git junto a cualquier producto, y mantengo mis sucursales locales. Muy útil para poder cambiar a la última confirmación de otro desarrollador, verificar algo, luego volver atrás.

Entonces, por supuesto, hay bisección, que puede ser de gran ayuda para proyectos de trabajo o de hogar.

Además, si en el trabajo todavía usan tarjetas perforadas, cvs o subversión, entonces usar git en casa es una excelente manera de mantenerse actualizado y descubrir por ti mismo el impacto que puede tener.

No me entusiasman las tecnologías a menos que traigan algo realmente nuevo a la mesa. Git lo hace. Soy un fan. Probablemente ya te hayas dado cuenta de eso.