tortoise - svn vs git

Véndeme control de revisión distribuido (10)

Sé miles de temas similares flotando alrededor. Leí por lo menos 5 hilos aquí en SO Pero, ¿por qué todavía no estoy convencido de DVCS?

Solo tengo las siguientes preguntas (nótese que estoy egoístamente preocupado solo por los proyectos de Java)

¿Cuál es la ventaja o el valor de comprometerse localmente? ¿Qué? ¿De Verdad? ¿Todos los IDEs modernos le permiten realizar un seguimiento de sus cambios? y si es necesario, puede restaurar un cambio en particular. Además, tienen una función para etiquetar sus cambios / versiones a nivel IDE !?
¿Qué pasa si bloqueo mi disco duro? ¿A dónde fue mi repositorio local? (Entonces, ¿cómo es genial en comparación con el registro en un repositorio central?)
Trabajando fuera de línea o en un avión. ¿Cuál es el problema? Para poder crear una versión con mis cambios, eventualmente me conectaré con el repositorio central. Hasta entonces, no importa cómo sigo mis cambios localmente.
Ok, Linus Torvalds le da su vida a Git y odia todo lo demás. ¿Es eso suficiente para cantar a ciegas las alabanzas? Linus vive en un mundo diferente en comparación con los desarrolladores offshore en mi proyecto de tamaño mediano.

¡Hablame!

Confiabilidad

Si su disco duro comienza a corromper datos en forma silenciosa, definitivamente querrá saberlo. Git toma SHA1 hash de todo lo que cometes. Usted tiene 1 repo central con SVN y si sus bits se modifican silenciosamente por un controlador de disco duro defectuoso, no lo sabrá hasta que sea demasiado tarde.

Y dado que tienes 1 repo central, acabas de arruinar tu único salvavidas .

Con git, todos tienen un repositorio idéntico, completo con historial de cambios, y su contenido puede ser completamente confiable debido a SHA1 de su imagen completa. Entonces, si haces una copia de seguridad de tu SHA1 de 20 bytes de tu CABEZA, puedes estar seguro de que al clonar desde un espejo que no es de confianza, ¡tienes el mismo informe que perdiste!

Ramificación (y contaminación del espacio de nombres)

Cuando utiliza un repositorio centralizado, todas las ramas están ahí para que el mundo las vea. No puedes hacer ramas privadas. Debes crear una rama que no colisione con otro nombre global.

" test123 - maldición, ya hay una test123 . Vamos a probar test124 ".

Y todos deben ver todas estas ramas con nombres estúpidos. Tienes que sucumbir a la política de la compañía que puede ir por la línea de "no hacer ramas a menos que realmente lo necesites", lo que impide muchas libertades que obtienes con git.

Lo mismo con comprometerse. Cuando te comprometes, es mejor que estés realmente seguro de que tu código funciona. De lo contrario, rompes la construcción. Sin compromisos intermedios. Porque todos van al repositorio central.

Con git no tienes nada de esto sin sentido. Rama y cometer localmente todo lo que quieras. Cuando esté listo para exponer sus cambios al resto del mundo, le pedirá que se distancie de usted, o lo empujará a un repositorio "principal" de git repo.

Actuación

Como su repositorio es local, todas las operaciones de VCS son rápidas y no requieren viajes de ida y vuelta desde el servidor central. git log no tiene que pasar por la red para encontrar un historial de cambios. SVN lo hace. ¡Lo mismo con todos los demás comandos, ya que todas las cosas importantes se almacenan en una sola ubicación !

Mire la charla de Linus sobre estos y otros beneficios a través de SVN.

DVCS es muy interesante para mí, ya que:

agrega una dimensión completamente nueva al proceso de control de origen : publicación .
No solo tiene un flujo de trabajo de fusión , sino que también tiene un flujo de trabajo de publicación (a qué repositorio va a presionar / extraer), y eso puede tener muchas implicaciones en términos de:
- ciclo de vida del desarrollo (con repositorios hechos solo para un cierto tipo de commits, como el hecho para ser lanzado en profuctions, para propósitos de despliegue)
- tareas individuales (puede enviar y actualizar un repositorio de respaldo, incluso en forma de un solo archivo )
- proyecto de interdependencias (cuando un equipo del proyecto A está esperando que el poryecto de equipo B se comprometa finalmente con el repositorio central, puede recurrir a pedir a B que "pase" un desarrollo intermedio como un archivo zip adjunto en un correo. que A tiene que hacer es agregar B repo como posible control remoto, buscarlo y echar un vistazo)
trae una nueva forma de producir / consumir revisiones con:
- una forma pasiva de producir nuevas revisiones (solo la que está sacando activamente de su repos las verá en sus sucursales)
- una forma activa de consumir revisiones de otros (agregando su repositorio como remoto y buscando / fusionando lo que necesita de ellos).

Eso significa que no depende de que otro entregue su trabajo a un repositorio central, sino que puede tener una relación más directa con los diferentes actores y sus repositorios.

He estado donde estás ahora, escéptico de los usos del control de versión distribuida. Había leído todos los artículos y conocía los argumentos teóricos, pero no estaba convencido.

Hasta que, un día, escribí git init y de repente me encontré dentro de un repositorio git.

Te sugiero que hagas lo mismo, simplemente pruébalo. Comienza con un pequeño proyecto de hobby, solo para entenderlo. Luego, decida si vale la pena usar algo más grande.

Interesante pregunta.

No soy un usuario experimentado de DVCS, pero mi exposición limitada se ha sentido muy positiva.

Me encanta poder comprometerme en 2 pasos. Me queda.

Algunas ventajas que vienen a la mente:

Mejor fusión de soporte. Branch-Merge se siente más como un ciudadano de primera clase en DVCS, mientras que en mi experiencia de soluciones centralizadas, he encontrado que es doloroso y truculento. El seguimiento de combinación ya está disponible en svn, pero todavía es lento y engorroso.
Grandes equipos DVCS no es solo para confirmaciones de usuario único. Puede empujar y tirar las confirmaciones entre los equipos antes de contribuir de nuevo al repositorio principal (o no). Esto es invaluable para ciertos sabores de colaboración.
cuando se trabaja en la funcionalidad experimental, tiene sentido comprometerse con frecuencia, pero solo a corto plazo. No quiero siempre ramificar la base de código principal, así que es agradable poder jugar y volver a grabar. Del mismo modo, puedo ver que es útil cuando se trabaja con integración continua. Si estoy trabajando durante días en los esfuerzos de refactorización, puedo romper las compilaciones por un período de tiempo inaceptable, pero aún quiero hacer un seguimiento de mis cambios.

Tenga en cuenta que mi experiencia DVCS es más con Mercurial que con Git. Viniendo de un fondo CVS / SVN, he encontrado la curva de aprendizaje mucho más fácil con Mercurial (Hg). El soporte de Google Code recientemente agregado para Mercurial también es una gran ayuda. ... Incluso llegaré a decir que mi respuesta inicial a Git fue negativa, pero más desde una perspectiva de usabilidad que cualquier otra cosa relacionada con DVCS

Lo más probable es que nadie te venda nada aquí. Si necesitas las características de git, solo git init . Si no le queda, simplemente no lo haga.

Si aún no conoce las características de git, escriba git vs (observe el espacio de finalización) en la búsqueda de Google y vea los resultados de la función de autocompletar.

Preferí Notepad sobre IDE hasta que necesité las características de Netbeans. Parece que este es el mismo caso aquí.

Como saben, hubo muchos proyectos exitosos sin VCS en absoluto.

PD. ¡Vender git infringe su licencia! ;)

Puede ser interesante observar que Subversion probablemente obtendrá cosas como commit offline en el futuro. Por supuesto, no podemos comparar esas características con las que están disponibles hoy en día, pero podría ser una muy buena forma de "usar DVCS de manera centralizada" como se describe en otras respuestas aquí.

Otra publicación reciente afirma que Subversion no está tratando de convertirse en un DVCS

Estas cosas probablemente significarán que el repositorio aún está centralizado, lo que significa que no puede hacer una bifurcación desconectada, que difiere de versiones antiguas, pero puede poner en cola las confirmaciones.

Si no ves el valor de la historia local o las compilaciones locales, entonces no estoy seguro de que cualquier cantidad de preguntas y respuestas te haga cambiar de opinión.

Las características de historial de IDE son limitadas y torpes. No se parecen en nada a la función completa.

Un buen ejemplo de cómo se usa este material es en varios proyectos de Apache. Puedo sincronizar un repo de git con el repositorio svn de Apache. Entonces puedo trabajar por una semana en una sucursal privada. Puedo reducir los cambios del repositorio. Puedo informar sobre mis cambios, venta al por menor o al por mayor. Y cuando termine, puedo empaquetarlos como una confirmación.

Soy un desarrollador de Mercurial y he trabajado como consultor de Mercurial. Así que encuentro sus preguntas muy interesantes y espero responderlas:

¿Cuál es la ventaja o el valor de comprometerse localmente? [...]

Tiene razón en que los IDE pueden rastrear los cambios locales más allá del simple deshacer / rehacer estos días. Sin embargo, todavía existe un vacío en la funcionalidad entre estas instantáneas de archivos y un sistema de control de versiones completo.

Los compromisos locales le dan la opción de preparar su "historia" localmente antes de enviarla para su revisión. A menudo trabajo en algunos cambios que implican 2-5 commits. Después de hacer cometer 4, podría volver atrás y modificar levemente el commit 2 (tal vez vi un error en commit 2 luego de confirmar 4). De esa manera, estaré trabajando no solo en el último código, sino en los últimos commits. Eso es trivialmente posible cuando todo es local, pero se vuelve más complicado si necesita sincronizar con un servidor central.

¿Qué pasa si bloqueo mi disco duro? [...] Entonces, ¿cómo es genial en comparación con registrarse en un repositorio central?

¡No genial para nada! :-)

Sin embargo, incluso con un repositorio central, aún debe preocuparse por los datos no comprometidos en la copia de trabajo. Por lo tanto, afirmaría que debe tener una solución de respaldo en su lugar de todos modos.

Según mi experiencia, las personas a menudo tienen grandes cantidades de datos no comprometidos en sus copias de trabajo con un sistema centralizado. Los clientes me dijeron cómo intentaban convencer a los desarrolladores para que se comprometieran al menos una vez a la semana .

Los cambios a menudo quedan sin compromiso porque:

No están realmente terminados. Puede haber instrucciones de impresión de depuración en el código, puede haber funciones incompletas, etc.
El compromiso entraría en el trunk y eso es peligroso con un sistema centralizado ya que impacta a todos los demás.
Comprometerse requeriría que primero se fusione con el repositorio central. Esa fusión puede ser intimidante si sabe que ha habido otros cambios conflictivos en el código. La fusión podría ser simplemente molesta porque es posible que no haya terminado con los cambios y que prefiera trabajar desde un estado conocido.
El compromiso puede ser lento cuando tiene que hablar con un servidor central sobrecargado. Si se encuentra en una ubicación extraterritorial, las confirmaciones son incluso más lentas.

Eres absolutamente correcto si crees que lo anterior no es realmente una cuestión de control de versiones centralizado versus distribuido. Con un CVCS, las personas pueden trabajar en sucursales separadas y así evitar trivialmente 2 y 3 arriba. Con una sucursal desechable por separado, también puedo comprometer tanto como quiera, ya que puedo crear otra rama en la que realice más cambios pulidos (solución de 1). Los compromisos aún pueden ser lentos, por lo que 4 pueden aplicarse todavía.

Las personas que usan DVCS a menudo empujarán sus compromisos "locales" a un servidor remoto de todos modos como una solución de copia de seguridad para los pobres. No presionan al servidor principal donde trabaja el resto del equipo, sino a otro servidor (posiblemente privado). De esa forma, pueden trabajar de forma aislada y aún mantener copias de seguridad fuera del sitio.

Trabajando fuera de línea o en un avión. [...]

Sí, nunca me gustó ese argumento tampoco. Tengo una buena conexión a Internet el 99% del tiempo y no vuelo lo suficiente como para que esto sea un problema :-)

Sin embargo, el verdadero argumento no es que estés desconectado, sino que puedes fingir estar desconectado. Más precisamente, puede trabajar de forma aislada sin tener que enviar sus cambios a un repositorio central de inmediato.

Las herramientas DVCS están diseñadas en torno a la idea de que las personas podrían estar trabajando sin conexión. Esto tiene varias consecuencias importantes:

La fusión de ramas se convierte en algo natural. Cuando las personas pueden trabajar en paralelo, las bifurcaciones se producirán naturalmente en el gráfico de confirmación. Por lo tanto, estas herramientas deben ser realmente buenas para fusionar sucursales. ¡Una herramienta como SVN no es muy buena para fusionarse !
Git, Mercurial y otras herramientas DVCS se fusionan mejor porque han tenido más pruebas en esta área, no directamente porque se distribuyen.
Más flexibilidad Con un DVCS, tiene la libertad de impulsar / hacer cambios entre repositorios arbitrarios. A menudo me desplazo / tiré entre mi hogar y mi computadora, sin usar ningún servidor central real. Cuando las cosas están listas para su publicación, las empujo a un lugar como Bitbucket.
La sincronización de múltiples sitios ya no es una "función empresarial", es una característica incorporada. Entonces, si tiene una ubicación en el extranjero, puede configurar un repositorio de concentrador local y usar esto entre ellos. A continuación, puede sincronizar los concentradores locales con las horas, a diario o cuando le convenga. Esto no requiere más que un cronjob que ejecuta hg pull o git fetch a intervalos regulares.
Mejor escalabilidad ya que hay más lógica en el lado del cliente. Esto significa menos mantenimiento en el servidor central y herramientas más potentes para el lado del cliente.
Con un DVCS, espero ser capaz de hacer una búsqueda de palabras clave a través de revisiones del código (no solo los mensajes de confirmación). Con una herramienta centralizada, normalmente necesita configurar una herramienta de indexación adicional.

Su argumento central sobre el IDE haciendo el seguimiento por usted es falso. La mayoría de los IDE en realidad no tienen ninguna funcionalidad así además de niveles de deshacer ilimitados. Piense en las ramas, las fusiones, los reveses, los mensajes de compromiso (log) y demás, y apuesto a que incluso el IDE al que se refirió se queda corto. Especialmente dudo que haga un seguimiento de sus compromisos, posiblemente en varias ramas diferentes en las que trabaja, y que los empuje adecuadamente al repositorio una vez que se conecte.

Si su IDE realmente hace todo eso, de hecho lo llamaría un sistema de control de versiones distribuidas en sí mismo.

Finalmente, si el repositorio central muere por cualquier razón (su proveedor de servicio se declaró en quiebra, hubo un incendio, un hacker lo corrompió, ...), tiene una copia de seguridad completa en cada máquina que ha retirado el repositorio recientemente.

EDITAR: Puede usar un DVCS como un repositorio centralizado, e incluso lo recomendaría para proyectos pequeños y medianos al menos. Tener un repositorio "autorizado" central que siempre está en línea simplifica muchas cosas. Y cuando esa máquina falla, puede cambiar temporalmente a una de las otras máquinas hasta que el servidor se solucione.

No voy a vender nada aquí.

• ¿Cuál es la ventaja o el valor de comprometerse localmente? ¿Qué? ¿De Verdad? ¿Todos los IDEs modernos le permiten realizar un seguimiento de sus cambios? y si es necesario, puede restaurar un cambio en particular. Además, tienen una función para etiquetar sus cambios / versiones a nivel IDE !?

La única ventaja real es que no necesita tener conectividad con el repositorio central principal. Alguien puede decir que el beneficio de Git es el hecho de que un desarrollador puede comprometerse localmente, preparando un gran conjunto de parches y luego jalándolos al bendito repositorio central, pero esto no es interesante. Un desarrollador puede usar una estantería privada o una sucursal en el repositorio de Subversion para trabajar en su tarea y luego fusionarla con una línea principal (por ejemplo, troncal) u otra rama.

Para mí, la principal desventaja aquí es el hecho de que tengo que descargar y almacenar todo el repositorio de Git en mi máquina. Con un proyecto grande con una larga historia, se convierte en un dolor y ocupa demasiado espacio.

Otro inconveniente de estar centralizado es que Git no puede rastrear técnicamente ni copiar operaciones . Simplemente intenta adivinar si un archivo fue renombrado o copiado según el contenido del archivo . Esto da como resultado casos tan graciosos: la migración de svn a git mantiene el historial del archivo copiado (Guy pregunta por qué el historial de un archivo se ha perdido después de SVN> Migración de Git,).

• ¿Qué pasa si bloqueo mi disco duro? ¿A dónde fue mi repositorio local? (Entonces, ¿cómo es genial en comparación con el registro en un repositorio central?)

Con Git, si bloqueó su dispositivo de almacenamiento local (disco duro, SSD, lo que sea) y tuvo cambios que no fueron retirados o enviados a un repositorio de Git bendecido, entonces no tiene suerte. Acabas de perder tu tiempo y tu código. Además de esto, un bloqueo de un disco duro con su repositorio local de Git puede detener el proceso de desarrollo por algún tiempo: el SSD de Linus Torvald se rompe, detiene el desarrollo del kernel de Linux .

Con el control de origen centralizado como SVN, solo podría perder su último compromiso porque todo su trabajo ya estaba comprometido con el repositorio central en una sucursal, estantería privada o incluso en el maletero. Obviamente, debe asegurarse de que haya una recuperación de desastres y una copia de seguridad implementada para su repositorio central.

• Ok, Linus Torvalds le da su vida a Git y odia todo lo demás. ¿Es eso suficiente para cantar a ciegas las alabanzas? Linus vive en un mundo diferente en comparación con los desarrolladores offshore en mi proyecto de tamaño mediano.

Para un proyecto como Linux Kernel que usó BitKeeper en el pasado, ¡Git es el mejor sistema de control de fuente! Pero diría que Git no se adapta a todos.

¡Elegir sabiamente!