Véndeme control de revisión distribuido

Conozco miles de temas similares que circulan por ahí. Leí al menos 5 hilos aquí en SO, pero ¿por qué todavía no estoy convencido acerca de DVCS?

Solo tengo las siguientes preguntas (tenga en cuenta que solo estoy preocupado egoístamente por los proyectos Java)

• ¿Cuál es la ventaja o el valor de comprometerse localmente? ¿Qué? ¿en realidad? ¿Todos los IDE 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 fallo mi disco duro? ¿A dónde fue mi repositorio local? (Entonces, ¿qué tiene de interesante en comparación con registrarse en un repositorio central?)
• Trabajar fuera de línea o en un avión. ¿Cuál es el problema? Para poder crear una versión con mis cambios, eventualmente debo conectarme al repositorio central. Hasta entonces, no importa cómo realice el seguimiento de mis cambios localmente.
• Ok, Linus Torvalds entrega su vida a Git y odia todo lo demás. ¿Es eso suficiente para cantar alabanzas a ciegas? ¿Linus vive en un mundo diferente en comparación con los desarrolladores offshore en mi proyecto de tamaño mediano?

¡Ponme!

Apr 02 '10 04:04 ring bearer

Fiabilidad

Si su disco duro comienza a corromper datos silenciosamente, es muy importante que lo sepa. Git toma hashes SHA1 de todo lo que confirmas. Tiene 1 repositorio central con SVN y si sus bits son modificados silenciosamente por un controlador HDD defectuoso, no lo sabrá hasta que sea demasiado tarde.

Y como tiene 1 repositorio central, acaba de desperdiciar su único salvavidas .

Con git, todos tienen un repositorio idéntico, completo con historial de cambios, y se puede confiar plenamente en su contenido debido al SHA1 de su imagen completa. Entonces, si realiza una copia de seguridad de su SHA1 de 20 bytes de su HEAD, puede estar seguro de que cuando clone desde algún espejo que no sea de confianza, tendrá exactamente el mismo repositorio que perdió.

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

Cuando utilizas un repositorio centralizado, todas las sucursales están ahí para que el mundo las vea. No puedes hacer sucursales privadas. Tienes que crear alguna rama que no colisione con algún otro nombre global.

" test123- Maldita sea, ya hay un test123. Intentémoslo test124".

Y todo el mundo tiene que ver todas estas ramas con nombres estúpidos. Tienes que sucumbir a la política de la empresa que podría ir en la línea de "no crear sucursales a menos que realmente lo necesites", lo que impide muchas de las libertades que obtienes con git.

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

Con git no tienes ninguna tontería. Ramifica y confirma localmente todo lo que quieras. Cuando esté listo para exponer sus cambios al resto del mundo, pídales que los retiren de usted o los envíe a algún repositorio de git "principal".

Actuación

Dado que su repositorio es local, todas las operaciones de VCS son rápidas y no requieren viajes de ida y vuelta ni transferencias desde el servidor central. git logNo es necesario navegar por la red para encontrar un historial de cambios. SVN lo hace. Lo mismo ocurre con todos los demás comandos, ya que todo lo importante se almacena en una ubicación .

Mire la charla de Linus para conocer estos y otros beneficios sobre SVN.

Apr 03 '2010 09:04 Alex Budovski

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

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

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

Las confirmaciones locales le brindan la opción de preparar su "historia" localmente antes de enviarla para su revisión. A menudo trabajo en algunos cambios que involucran de 2 a 5 confirmaciones. Después de realizar la confirmación 4, podría regresar y modificar ligeramente la confirmación 2 (tal vez vi un error en la confirmación 2 después de realizar la confirmación 4). De esa manera estaré trabajando no solo en el código más reciente, sino también en las últimas dos confirmaciones. Esto es trivialmente posible cuando todo es local, pero se vuelve más complicado si necesitas sincronizar con un servidor central.

• ¿Qué pasa si fallo mi disco duro? [...] entonces, ¿qué tiene de interesante en comparación con registrarse en un repositorio central?

¡No es nada genial! :-)

Sin embargo, incluso con un repositorio central, todavía tienes que preocuparte por los datos no comprometidos. en la copia de trabajo. Por lo tanto, diría que debería contar con una solución de respaldo de todos modos.

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

Los cambios a menudo no se confirman porque:

1. Realmente no están terminados. Puede haber declaraciones de impresión de depuración en el código, puede haber funciones incompletas, etc.

2. Comprometerse sería trunkpeligroso en un sistema centralizado, ya que afecta a todos los demás.

3. La confirmación requeriría que primero se fusione con el repositorio central. Esa combinación puede resultar intimidante si sabe que se han realizado otros cambios conflictivos en el código. La fusión puede ser simplemente molesta porque es posible que no haya terminado con los cambios y prefiera trabajar desde un estado en buen estado.

4. La confirmación puede ser lenta cuando tienes que hablar con un servidor central sobrecargado. Si se encuentra en una ubicación offshore, las confirmaciones son aún más lentas.

Tienes toda la razón si cree que lo anterior no es realmente una cuestión de control de versiones centralizado versus distribuido. Con un CVCS, las personas pueden trabajar en ramas separadas y así evitar trivialmente los puntos 2 y 3 anteriores. Con una rama desechable separada, también puedo comprometer todo lo que quiera, ya que puedo crear otra rama donde realizo cambios más pulidos (resolviendo 1). Sin embargo, las confirmaciones aún pueden ser lentas, por lo que aún se pueden aplicar 4.

Las personas que usan DVCS a menudo envían sus confirmaciones "locales" a un servidor remoto de todos modos como una solución de respaldo para los pobres. No envían al servidor principal donde está trabajando el resto del equipo, sino a otro servidor (posiblemente privado). De esa manera, pueden trabajar de forma aislada y seguir manteniendo copias de seguridad fuera del sitio.

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

Sí, a mí tampoco me gustó ese argumento. Tengo buena conectividad 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 que está desconectado. Más precisamente, que puede trabajar de forma aislada sin tener que enviar sus cambios a un repositorio central inmediatamente.

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

• Fusionar ramas se convierte en algo natural. Cuando las personas pueden trabajar en paralelo, naturalmente se producirán bifurcaciones 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 fusionar !

  Git, Mercurial y otras herramientas DVCS se combinan mejor porque han tenido más pruebas en esta área, no directamente porque estén distribuidas.

• Más flexibilidad. Con un DVCS, tiene la libertad de enviar o retirar cambios entre repositorios arbitrarios. A menudo hago push/pull entre las computadoras de mi casa y del trabajo, sin usar ningún servidor central real. Cuando las cosas están listas para su publicación, las envío a un lugar como Bitbucket.

  La sincronización multisitio ya no es una "función empresarial", es una función incorporada. Entonces, si tiene una ubicación en el extranjero, pueden configurar un repositorio central local y usarlo entre ellos. Luego puede sincronizar el horario de los centros locales, diariamente o cuando le convenga. Esto no requiere más que un cronjob que se ejecuta hg pulla git fetchintervalos regulares.

• Mejor escalabilidad ya que hay más lógica del lado del cliente. Esto significa menos mantenimiento en el servidor central y herramientas del lado del cliente más potentes.

  Con un DVCS, espero poder realizar una búsqueda de palabras clave mediante revisiones del código (no solo los mensajes de confirmación). Con una herramienta centralizada, normalmente necesitas configurar una herramienta de indexación adicional.

Apr 12 '2014 10:04 Martin Geisler

DVCS es muy interesante para mí ya que:

• Agrega una dimensión completamente nueva al proceso de control de fuentes : la publicación .
  No solo tiene un flujo de trabajo de fusión , también tiene un flujo de trabajo de publicación (a qué repositorio enviará o extraerá), y eso puede tener muchas implicaciones en términos de:

  • ciclo de vida de desarrollo (con repositorios creados solo para un cierto tipo de confirmaciones, como el que se realiza para ser lanzado en profunciones, con fines de implementación)
  • 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 proyecto del equipo B finalmente se comprometa con el repositorio central, puede recurrir a pedirle a B que "pase" un desarrollo intermedio como un archivo zip adjunto en un correo. Ahora, todos lo que A tiene que hacer es agregar el repositorio B 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 las que se extraen activamente de su repositorio las verán en sus ramas)
  • una forma activa de consumir revisiones de otros (agregando su repositorio como remoto y obteniendo/fusionando lo que necesita de ellos).

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

Apr 01 '2010 21:04 VonC