¿Qué hace SVN mejor que Git? [cerrado]

293

No hay duda de que la mayoría de los debates sobre las herramientas de programación destilan a la elección personal (por parte del usuario) o al énfasis en el diseño , es decir , optimizar el diseño de acuerdo con los casos de uso particulares (por parte del creador de herramientas). Los editores de texto son probablemente el ejemplo más destacado: un codificador que trabaja en Windows en el trabajo y codifica en Haskell en la Mac en casa, valora la integración multiplataforma y compilador y elige Emacs en lugar de TextMate , etc.

Es menos común que una tecnología recientemente introducida sea genuina, demostrablemente superior a las opciones existentes.

¿Es este el caso de los sistemas de control de versiones (VCS), en particular, VCS centralizado ( CVS y SVN ) versus VCS distribuido ( Git y Mercurial )?

Usé SVN durante unos cinco años, y SVN se usa actualmente donde trabajo. Hace poco menos de tres años, cambié a Git (y GitHub) para todos mis proyectos personales.

Puedo pensar en una serie de ventajas de Git sobre Subversion (y que en su mayor parte resumen las ventajas de distribuir sobre VCS centralizado), pero no puedo pensar en un contraejemplo: alguna tarea (que es relevante y surge en un programador habitual flujo de trabajo) que Subversion funciona mejor que Git.

La única conclusión que he sacado de esto es que no tengo ningún dato, no es que Git sea mejor, etc.

Supongo que existen tales contraejemplos, de ahí esta pregunta.

doug
fuente
3
@jokoon: ¿Eficiente en términos de qué? Seguramente no la velocidad ya que incluso Ethernet rápido es lento en comparación con las operaciones locales.
maaartinus
44
Siempre he pensado que Git era muy sobreestimado. Es una moda, y los programadores no son inmunes a las modas, a pesar de las muchas oposiciones a este pensamiento. Como todos los demás en este mundo, todos quieren el nuevo juguete brillante (Git). Git puede ser bueno, o incluso excelente para algunas personas, pero nunca ha sido mejor que SVN cuando se piensa objetivamente.
compró777 el
3
Pensé que SVN todavía era bueno de usar, la curva de aprendizaje es buena entonces GIT.
Cheung el
55
Esta pregunta se suspendió recientemente debido principalmente a la opinión. Esa clasificación es incorrecta; tenga en cuenta que la pregunta estuvo abierta durante mucho tiempo; que hay muchas preguntas sobre las virtudes de DVCS, y que la pregunta no pregunta si es mejor (opinión), sino qué hace mejor. Las diferencias no son la opinión, sino si el producto en general lo es, eso es complicado (pero no es el punto de esta pregunta).
Eamon Nerbonne

Respuestas:

207

Subversion es un repositorio central

Si bien muchas personas querrán tener repositorios distribuidos para los beneficios obvios de la velocidad y las copias múltiples, hay situaciones en las que un repositorio central es más deseable. Por ejemplo, si tienes algún código crítico al que no quieres que acceda nadie, probablemente no quieras ponerlo bajo Git. Muchas corporaciones quieren mantener su código centralizado, y (supongo) que todos los proyectos gubernamentales (serios) están bajo repositorios centrales.

La subversión es la sabiduría convencional.

Esto quiere decir que muchas personas (especialmente gerentes y jefes) tienen la forma habitual de numerar las versiones y ver el desarrollo como una "línea única" a lo largo del tiempo codificada en su cerebro. Sin ofender, pero la liberalidad de Git no es fácil de tragar. El primer capítulo de cualquier libro de Git te dice que borres todos los ideales convencionales de tu mente y comiences de nuevo.

Subversion lo hace de una manera, y nada más

SVN es un sistema de control de versiones. Tiene una forma de hacer su trabajo y todos lo hacen de la misma manera. Período. Esto facilita la transición a / desde SVN desde / a otro VCS centralizado. Git NO es ni siquiera un VCS puro: es un sistema de archivos, tiene muchas topologías sobre cómo configurar repositorios en diferentes situaciones, y no hay ningún estándar. Eso hace que sea más difícil elegir uno.

Otras ventajas son:

  • SVN admite directorios vacíos
  • SVN tiene mejor soporte de Windows
  • SVN puede verificar / clonar un subárbol
  • SVN admite un control de acceso exclusivo svn lockque es útil para archivos difíciles de combinar.
  • SVN admite archivos binarios y archivos grandes con mayor facilidad (y no requiere copiar versiones antiguas en todas partes).
  • Agregar un commit implica una cantidad considerablemente menor de pasos ya que no hay ningún pull / push y sus cambios locales siempre se basan implícitamente svn update.
codificador de árbol
fuente
55
"Subversion lo hace de una manera" - Yo también lo pensé, hasta que comencé mi trabajo actual. En mi trabajo actual, mi jefe, que afirma no tener problemas de confianza, configuró el servidor para que requiera bloqueo. No se produce fusión en nuestro sistema. Los archivos están bloqueados en el repositorio y nadie más puede escribirlos sin el bloqueo. El control de arriba hacia abajo, para aquellos cuyas constituciones lo exigen, es definitivamente algo que svn hace mejor que git.
Dan Ray
14
Una ventaja del repositorio central es la facilidad de las copias de seguridad. Si todo el código registrado está en un lugar, y ese lugar tiene respaldo externo, no perderá todo si su oficina se incendia. Con un DVCS, a menos que haga copias de seguridad fuera del sitio de las máquinas del desarrollador, perderá todo lo que no se haya enviado al servidor que está respaldado fuera del sitio.
Paul Tomblin
94
¿Por qué no se puede usar git de manera centralizada? Solo tiene un repositorio central, y sus desarrolladores pueden clonar y tirar y empujar como si estuvieran pagando, actualizando y confirmando.
David Thornley
29
@PaulTomblin: según el flujo de trabajo, Git puede proporcionar mejores copias de seguridad. Por ejemplo, usamos repositorios privados de github y frecuentemente empujo mi código hacia arriba para presentar ramas. Si mis compañeros de trabajo lo hacen git fetch origin, cada uno de ellos tiene una copia de seguridad de mi código, junto con cualquier copia de seguridad que Github proporcione. (Podamos regularmente ramas fusionadas, tanto localmente como en Github.)
Nathan Long
52
Parece implicar que central es más seguro para grandes empresas o trabajo gubernamental. Esto simplemente no es cierto. Si tiene una copia del código en su computadora, tiene una copia del código. No importa si proviene de un servidor central o de un sistema de archivos central con un repositorio DVCS.
John Fisher
131

Uno de los beneficios de Subversion sobre Git puede ser que Subversion solo permite ver subárboles. Con Git, todo el repositorio es una unidad, solo puede obtener todo o nada. Con el código modular, esto puede ser bastante bueno en comparación con los submódulos de Git. (Si bien los submódulos de Git también tienen su lugar, obviamente).

Y un pequeño beneficio: Subversion puede rastrear directorios vacíos. Git rastrea el contenido del archivo, por lo que no aparecerá un directorio sin ningún archivo.

johannes
fuente
11
Trabajar con subárboles es, en mi humilde opinión, lo único que SVN tiene sobre GIT. Punto tomado, los directorios vacíos son agradables, pero tampoco son necesarios (y se pueden solucionar). Si los submódulos git y el subárbol git fueran menos confusos, no habría nada que impidiera a muchas personas migrar a GIT. Las otras ventajas que algunas personas mencionaron se reducen a la mentalidad (de desarrollador). Por ejemplo, si necesita de arriba a abajo, está bien. Sin embargo, no tendría ningún trabajo para ti.
Hasta el
3
Es curioso cómo estos son los únicos tipos de cosas que pueden discutirse a favor de SVN (y otros controles de versión centralizados)
dukeofgaming
1
¿Por qué es gracioso? - Los sistemas más nuevos aprenden de los sistemas más antiguos. Incluso hay un beneficio con RCS sobre git: los archivos de historial se pueden editar fácilmente a mano y puede tener ramas por archivo. Pero eolution implica que las características se pierden ...
Johannes
3
Escuché de una compañía de juegos que usa SVN sobre GIT exactamente por esta razón: cuando hablas de un repositorio de muchos GB, ¡de repente se vuelve importante!
James
18
A partir de la versión 1.8.0 de git, ahora puede usar el git subtreecomando para lograr exactamente esto. La última ventaja de subversión muerde el polvo :) Detalles aquí: github.com/gitster/git/blob/… Nota: Aunque este es un enlace a un proyecto github, git-subtree ahora es parte de la distribución central de git.
Carl
51

Se me ocurren tres. Primero, es un poco más fácil de asimilar, especialmente para los que no son desarrolladores. Conceptualmente es mucho más simple que las opciones DCVS . El segundo es la madurez, especialmente TortoiseSVN en Windows. Sin embargo, TortoiseHg se está poniendo al día rápidamente. En tercer lugar, la naturaleza de la bestia, solo una imagen de un sistema de archivos donde puede ver cosas desde cualquier nivel del árbol, puede ser muy útil en algunos escenarios, como el versionado de una variedad de archivos de configuración muy diferentes en docenas de servidores sin docenas de repositorios.

Esto no quiere decir que no estamos trasladando todo el desarrollo a Mercurial.

Peter Mortensen
fuente
25
Ser más fácil de asimilar es una ventaja importante, ya que hace que sea más probable que se use. Sin duda, SVN es mucho mejor que ningún control de versión, y si alguien es terco con respecto a las viejas formas, entonces tal vez SVN sea la mejor opción para ellos.
jhocking
12
@jhocking: No me encanta SVN, pero si alguien me dice "No me gustan estas cosas nuevas de DVCS, entonces me quedaré con CVS", entonces definitivamente lo recomendaré: es el camino fácil al menos VCS parcialmente sano ;-)
Joachim Sauer
44
@jhocking Las nuevas formas no siempre son las mejores para cada circunstancia. Me recuerda la vieja historia sobre que la NASA gastó millones de dólares desarrollando una pluma que puede escribir en 0 g. Los cosmonautas, por otro lado, se hicieron con lápices. A veces las viejas formas son mejores, ¡AHORA SALE DE MI CÉSPED!
maple_shaft
25
@maple_shaft, y a veces no lo son. snopes.com/business/genius/spacepen.asp
Peter Taylor
3
Fácilmente asimilado es muy subjetivo y se basa en gran medida en cómo intentas adaptar el nuevo conocimiento a lo que ya puedes saber. También hace una gran diferencia cuál es su fuente de aprendizaje. Si va por páginas de manual, buena suerte. Si te está enseñando un buen maestro que ya lo entiende, lo tienes hecho. Descubrí que git tenía mucho sentido después de ver varios buenos videos en YouTube. Si obtiene su comprensión de alguien que ya lo ha destilado al núcleo simple, entonces cualquier cosa es más fácil de entender.
WarrenT
32
  • Los repositorios SVN son más manejables desde el punto de vista del administrador y del administrador ( ACL + métodos de autenticación + hotcopy + mirrors + dumps)
  • Los ganchos SVN * son más fáciles de implementar y soportar
  • svn:external tiene más potencia y flexibilidad que los submódulos
  • Los árboles de repositorio basados ​​en el sistema de archivos son más fáciles de usar que los repositorios monolíticos con separación solo lógica.
  • SVN tiene más herramientas de cliente diferentes
  • SVN tiene interfaces web utilizables por terceros, mucho mejores que las de Git
  • SVN no te rompe el cerebro
Lazy Badger
fuente
23
¿No te rompe el cerebro? ¿Quieres enseñarme cómo combinar fácilmente ramas con conflictos en SVN?
WarrenT
44
"Mejores" herramientas / front-end, ese es un objetivo en movimiento. Las herramientas mejoran en ambos lados. Ninguno de nosotros sabe qué herramientas estarán disponibles dentro de varios años. Esa evaluación de hace 10 meses podría cambiar fácilmente con el tiempo y podría estar obsoleta ahora. Preferiría ver respuestas sustantivas.
WarrenT
66
¿Conflictos de árboles? Cheque. ¿Sí o no a todas las opciones? No. Svn está diseñado para enfurecer. ¿Comando de copia de trabajo limpio? No. Revertir no puede limpiar archivos no versionados.
Warren P
1
Eliminar todo y volver a pagar eliminará los archivos no versionados.
jgmjgm
Me encanta tu última idea, Git me rompió el cerebro: '(
Lucas
24

Escribí esto como un comentario sobre la respuesta de otra persona, pero supongo que merece ser una respuesta en sí misma.

La configuración cuidadosamente elegida de mi empresa para SVN requiere el bloqueo de nivel de archivo para editar contenido, y nunca utiliza la combinación. Como resultado, múltiples desarrolladores compiten por bloqueos, y puede ser un gran cuello de botella, y nunca existe la posibilidad de un conflicto de fusión.

SVN definitivamente hace un control administrativo de arriba hacia abajo mejor que Git. En mi migración de Skunkworks a Git (pidiendo perdón en lugar de permiso) muchas veces aterroricé a mi gerente con la idea de que no hay ningún servidor de control maestro central forzado por software en el que todos somos esclavos.

Dan Ray
fuente
La centralidad es una cuestión de mito, no de hecho. Nadie puede evitar que cambie nada. Con un cvcs pueden evitar que cambie algo centralmente. Lo mismo en un dvcs. La palabra commit en cvcs combina commit y push.
Warren P
@JonathanHenson: esa definitivamente no es la única razón por la que Torvalds odia a SVN. SVN puede estar centralizado y puede ser un mejor CVS, pero eso difícilmente lo convierte en un buen software. Torvalds odia CVS / SVN no porque estén centralizados sino porque considera que son un software patéticamente malo. Si tiene razón o no, depende de usted decidir, pero vio el inmenso éxito tanto de Linux (como de Android), que se ejecuta en miles de millones de dispositivos, y de Git, que está tomando al mundo por sorpresa ... Lo pensaría dos veces antes de estar en desacuerdo con él. La conferencia que Torvalds dio en Google en Git hace años es increíble.
Cedric Martin
jajaja Su gerente tiene razón en estar aterrorizado de que no haya un sistema de respaldo adecuado. Solo decir "pero es DVCS para que alguien tenga una copia" no vuela. Lo sé, cuando vi que git se usaba en mi último lugar, literalmente no tenían copias de algunos repositorios. Eso sí, el bloqueo puede ser bueno para algunas situaciones y git falla a este respecto, a menos que tenga una herramienta mágica de fusión para imágenes u otros archivos binarios. git solo funciona realmente para archivos de texto.
gbjbaanb
22

Mis razones:

  • madurez: tanto el servidor como las herramientas (por ejemplo, TortoiseSVN)
  • simplicidad: menos pasos involucrados, un commit es un commit. DVCS como Git y Mercurial implican commit, luego push.
  • manejo binario: SVN maneja ejecutables binarios e imágenes mejor que Git / Hg. Especialmente útil con proyectos .NET ya que me gusta verificar las herramientas relacionadas con la compilación en el control de código fuente.
  • numeración: SVN tiene un esquema de numeración de confirmación legible, que usa solo dígitos, más fácil de rastrear números de revisión. Git y Hg hacen esto de manera muy diferente.
Grant Palin
fuente
1
El "esquema de numeración de compromiso" solo es posible si tiene troncales canónicos. De lo contrario, ¿cuál obtiene la numeración principal?
1
+1 el entumecimiento en svn. Este número es único. existen herramientas para usar este número como parte del número de versión de la aplicación xx.yy.zz.12882 donde 12882 es el número de versión svn. Si hay un problema de producción, puede preguntar por el número de versión y tiene la svn-revision exacta donde se compiló el software
k3b
22

Le agradezco que esté buscando buena información, pero este tipo de pregunta simplemente invita, "¡Creo que Git es mucho ganador, y svn teh suxorz!" respuestas

Lo intenté y personalmente encontré a Git demasiado para mi pequeño equipo. Parecía que sería genial para un gran equipo distribuido o un grupo de equipos que están dispersos geográficamente. Entiendo mucho los beneficios de Git, pero el control de fuente en mi opinión no es algo que me mantenga despierto por la noche.

Soy un cazador de ciervos, y cuando mis amigos y yo salimos están armados hasta los dientes, erizados de munición y equipo de alta tecnología. Me presento con un solo rifle, siete balas y un cuchillo. Si necesito más de siete rondas, entonces estoy haciendo algo mal, y lo hago tan bien como cualquier otra persona.

El punto que estoy tratando de hacer es que si eres un equipo pequeño que trabaja en un proyecto de mediano a pequeño y ya estás familiarizado con SVN, entonces úsalo. Sin duda, es mejor que CVS o (estremecimiento) SourceSafe , y no me lleva más de cinco minutos configurar un repositorio. Git a veces puede ser excesivo.

maple_shaft
fuente
3
De Verdad? Entonces te sugiero que eches un vistazo a los fósiles .
Spencer Rathbun
77
no hagamos sonar la alarma ante la más mínima posibilidad de controversia. Los temas importantes son a menudo los más controvertidos y los que tienen más probabilidades de invocar opiniones muy arraigadas. Entonces, "este tipo de pregunta" es importante y la posibilidad de una respuesta fuera de los límites no es plausible para no publicarla. Asumo que los usuarios en este sitio son adultos. Lo que es más, la forma en que se formuló mi Q era, si no era neutral, deferente para la gente de subversión: las respuestas receptivas a mi Q tendrán que recitar las ventajas de la subversión sobre git, y no al revés.
doug
@SpencerRathbun, ¡Gracias! Tendré que echarle un vistazo a eso. No es tanto que ame svn, sino que tengo disgusto por git.
maple_shaft
10
@Spencer - Por el contrario, como usuario de ambos gity hg, sugeriría mercurial para cualquiera que piense que gites demasiado. TortoiseHG sería muy familiar para cualquiera que esté acostumbrado a TortoiseSVN (incluso comparte las mismas superposiciones de Explorer en Windows). Ciertamente es mucho más fácil que VSS y me sorprendería si tomara más de unos segundos configurar un repositorio hg, confirmar el estado inicial y clonarlo en una unidad compartida.
Mark Booth
@ MarkBooth Como se indicó en la pregunta original, creo que es una cuestión de deseos y necesidades. En mi lugar de trabajo actual, no había repositorio antes de llegar allí. Necesitaba algo que tuviera todas, o la mayoría, las herramientas del proyecto que quería agrupar, era fácil de usar, guardaba todo en lugar de deltas y funcionaría distribuido para equipos de 1 o 2 personas en múltiples máquinas.
Spencer Rathbun
20

Todo esto es relativo, y como dijo maple_shaft, si uno funciona para usted, ¡no cambie!

Pero si realmente quieres algo , diría que quizás sea mejor para diseñadores, programadores web y demás : maneja las imágenes y los archivos binarios un poco mejor.

Torre
fuente
2
¿Cómo los maneja mejor SVN? Git considera cada archivo como un BLOB.
WarrenT
44
@WarrenT debido a los flujos de trabajo, con git estás ramificando y fusionando mucho (o por qué molestarse en usarlo) y simplemente no puedes fusionar de forma realista los binarios. Por lo tanto, a menudo coloca la propiedad "necesita bloqueo" en archivos binarios en SVN.
gbjbaanb
1
Algunos archivos binarios pueden (teóricamente) fusionarse, por ejemplo, un documento ODT.
Donal Fellows
18

Usabilidad. No es realmente el mérito de Subversion sino más bien TortoiseSVN .. TortoiseGit existe, pero todavía tiene un largo camino por recorrer para igualar TortoiseSVN.

Si preguntaras qué hace Git mejor que SVN, respondería GitHub . Es curioso cómo las herramientas de terceros marcan una gran diferencia.

Peter Mortensen
fuente
1
Assembla (para cualquier SCM compatible - SVN en la lista) es mejor que github, creo
Lazy Badger
ahora también hay smartgit, GitXL, etc., programas que simplifican el uso de git
wirrbel
@LazyBadger, nunca he oído hablar de eso.
Pacerier
16

Cuando no necesita bifurcar y fusionar , SVN (con TortoiseSVN en Windows) es muy fácil de entender y usar. Git es demasiado complejo para los casos simples, ya que trata de facilitar la ramificación / fusión.

(Muchos proyectos pequeños nunca tienen que ramificarse si se gestionan bien. Git está dirigido a los casos complejos; por lo tanto, la mayoría de la documentación de Git supone que debe realizar operaciones complejas como ramificar y fusionar).

Ian
fuente
8
El uso de la gitramificación y la fusión no son operaciones complejas. Incluso uso ramas en un proyecto de un solo hombre, incluso cuando no hay requisitos para la versión múltiple. Mantener el trabajo que no puede continuar en este momento en una sucursal, bifurcarse cuando descubre que probar otra solución puede ser mucho mejor ... Sin embargo, estoy de acuerdo en que gites un poco más difícil de aprender.
maaartinus
Cada vez que necesite hacer correcciones de errores en versiones antiguas, necesita ramificar y fusionar.
1
¿Por qué la gente no considera la idea de que mercurial es más fácil que svn o git?
Warren P
Creo que parte de esto es que, como SVN hasta hace poco no había soportado la ramificación y la fusión sin un costo muy alto, ha permitido que el programador se enfrente más a los gerentes cuando querían seguir cambiando lo que alguien está trabajando. Una herramienta tiene que funcionar dentro de las políticas de una empresa y también ayuda a dar forma a las políticas de una empresa.
Ian
14

Bueno, mi abuelo podría usar SVN en su computadora con Windows XP, pero tendría problemas para usar Git. Tal vez esto sea más un logro de TortoiseSVN sobre TortoiseGit , pero creo que está bastante relacionado con el hecho de que Git es inherentemente más poderoso y, por lo tanto, más complejo, y sería inútil reducirlo al mismo nivel.

Ahora realmente no importa para mi abuelo, porque últimamente no ha hecho ninguna programación. Sin embargo, una vez estuve en un equipo, donde nuestros artistas gráficos también usaban nuestro control de fuente.

Y esas son personas que simplemente esperan que sus herramientas funcionen (yo también, pero tengo una oportunidad realista de hacer que funcionen en caso de falla) y sean intuitivas. Aparte del hecho de que hubiera sido un gran esfuerzo lograr que se llevaran bien con un DVCS , había poco que ganar. Y con solo dos programadores en el equipo, tenía sentido para nosotros también seguir con SVN.

Peter Mortensen
fuente
git es el enfoque más "filosófico" para el control de versiones. comienzas a pensar en la semántica de commits, ramas, etc. Por lo tanto, las personas que desean usar un VCS como una "copia de seguridad" y herramienta de distribución tienen más dificultades, pero git no es mucho más difícil
wirrbel
11

En el trabajo no podía cambiar los desarrolladores de SVN a ningún DVCS por dos razones:

  • Pagos parciales (como solo tres carpetas de diferentes profundidades en el árbol del proyecto)
  • Bloqueo de archivos (informes en formato binario)
alexandrul
fuente
8
  • Sentido de seguridad al hacer un 'svn commit'. Dado que las confirmaciones van al servidor, no hay ningún posible error que pueda hacer que borre mis cambios después de que se confirmen. En git, los commits son locales, así que hasta que presiono, un 'rm -rf' perdido y todo ha terminado.
  • Los commits se autentican. Por defecto en git, puedo decir que me estoy comprometiendo como cualquiera.
  • Menos comandos para aprender para el uso diario. 'svn checkout', 'svn up' y 'svn commit' te llevarán bastante lejos.
  • Los pagos compartidos funcionan mucho mejor. Cuando va a comprometerse, le pide su nombre de usuario / contraseña, no tiene que recordar pasar ciertos argumentos de línea de comando. A veces, en el trabajo, tenemos una máquina compartida con un pago compartido de algún proyecto. Alguien podría decir "Bob, ¿puedes ver esto en esta máquina?", Y él puede, y puede confirmar sus cambios como su usuario sin ningún problema.
  • Diseño de repositorio. Puede tener un proyecto general y subproyectos y elegir qué revisar cuando.
  • Los números de revisión son enteros incrementales.
  • Diseñado para el flujo de trabajo del repositorio central.
Tim
fuente
+1 para el problema de autenticación. Las confirmaciones de Git deben firmarse, y las firmas deben verificarse, lo cual es difícil.
Christian
6

Otras personas han publicado algunas respuestas bastante buenas, pero ¿qué pasa con los permisos? Usando Subversion sobre SSH, puede crear una cuenta separada en su servidor para SVN. A los diferentes desarrolladores se les puede dar acceso diferente a diferentes partes del repositorio. ¿Puede GIT hacer eso? Supongo que hay gitolita, pero simplemente no me parece tan flexible o robusta, ni conozco a nadie que realmente la esté usando.

GlenPeterson
fuente
2
Otros han tocado esto al mencionar el "control de gestión de arriba hacia abajo". Este es un elemento clave para mi entorno: tenemos ciertas áreas de nuestros repositorios que deben bloquearse para solo lectura o incluso no lectura para algunos grupos de usuarios. También necesitamos tener una única ubicación a la que podamos señalar y decir "esta es la copia maestra autorizada, si su copia no coincide con lo que está aquí, no es oficial".
alroc
1
El bendito repositorio del líder del proyecto y los tenientes está dando control sobre quién puede comprometerse. El repositorio de Git publicado en el servidor habilitado para http-auth (que usa los mismos módulos de apache que svn hace) realiza la autenticación y dice quién puede clonar / verificar qué. Claro, no es tan granular como svn por permisos de directorio, pero para mí se parece más a la microgestión que a la necesidad real.
Hubert Kario
@HubertKario: esto plantea la pregunta: "¿Deberían sus mejores programadores pasar su tiempo revisando el código de otras personas?" En realidad, estoy tan interesado en la respuesta a esta pregunta, que la
publiqué
5

Velocidad. A veces toma 10 o 15 minutos para clonar un gran repositorio de git, mientras que un repositorio de subversión de tamaño similar toma un par de minutos para verificar.

calum_b
fuente
66
Pero el pago / clonación es una operación rara. En la mayoría de los escenarios, git es más rápido que la subversión.
rds el
55
git clone --depth=1es tu amigo si no te importa la historia
Hubert Kario
4

Publico esto como una respuesta en lugar de un comentario.

Admito que DVCS está bastante de moda en este momento, pero intentaré decir por qué.

Los DVCS son mejores porque, como muchas personas han estado diciendo, "esta es la forma en que deberíamos haber estado trabajando desde el principio". Es cierto, puede hacer con un DVCS lo que solía hacer con SVN, por lo que SVN queda obsoleto.

Sin embargo, no todos los proyectos de software son tan buenos como son:

  • Los proyectos a largo plazo se han beneficiado mucho de DVCS, ya que utiliza menos gastos generales, permite una gestión mucho mejor (ramificación, etc.) y es muy compatible con hosts como google code y github.

  • Esos proyectos no son los únicos, hay otro tipo de proyectos que se están desarrollando en empresas sin ninguna ayuda del mundo exterior o de Internet: todo se hace internamente y, a menudo, a corto plazo. Un buen ejemplo: un videojuego. El código evoluciona rápidamente.

Para el último caso, los desarrolladores realmente no necesitan ramificaciones o funciones sofisticadas que DVCS puede ofrecer, solo quieren compartir el código fuente y los activos. El código que hacen no es probable que se reutilice, porque hay una fecha límite. Confían en SVN en lugar de un DVCS debido a varias razones:

  • Los desarrolladores tienen máquinas que pertenecen a la empresa, y esto podría cambiar rápidamente. Configurar un repositorio es una pérdida de tiempo.
  • Si esos tipos no tienen su propia máquina, es menos probable que trabajen en el mismo código fuente / parte del proyecto. Más uno para los datos centralizados.
  • Las velocidades de red y mucho dinero permiten el uso de un servidor centralizado que se ocupa de todo SVN, es una mala práctica, pero se realizan copias de seguridad, etc.
  • SVN es más simple de usar, incluso si es de la manera incorrecta: sincronizar archivos en pares sin redundancia no es un problema simple, y "hacerlo de la manera correcta" simplemente no puede llegar a tiempo si siempre quiere que sea perfecto.

Piensa en la máquina de la industria del juego y en cómo SVN ahorra tiempo; la gente se comunica mucho más sobre esos proyectos porque los juegos son sobre programación repetitiva y código adaptativo: no hay nada difícil de codificar, pero debe hacerse de la manera correcta, CUANTO ANTES. Los programadores son contratados, codifican su parte, lo compilan, lo prueban un poco, se comprometen, listo, los probadores del juego se encargarán del resto.

Los DVCS están hechos para internet y para proyectos muy complejos. SVN son para proyectos de equipo pequeño, a corto plazo y ajustado. No necesita aprender mucho de SVN, es casi un FTP con una diferencia tonta.

jokoon
fuente
¿Puedes explicar el ejemplo de la industria del juego?
johnny
3

Subversion y Git fomentan enfoques particulares (y muy diferentes) para el desarrollo y la colaboración. Algunas organizaciones obtendrán más de Git y otras obtendrán más de Subversion, dependiendo de su organización y cultura.

Git y Mercurial son excelentes para equipos distribuidos y organizados libremente de programadores profesionales altamente competentes. Ambas herramientas DVCS populares fomentan repositorios pequeños, y la reutilización entre desarrolladores se realiza a través de bibliotecas publicadas con interfaces (relativamente) estables.

Subversion, por otro lado, fomenta una estructura de gestión más centralizada y estrechamente acoplada, con más comunicación entre los desarrolladores y un mayor grado de control organizacional sobre las actividades de desarrollo cotidianas. Dentro de estos equipos organizados de manera más compacta, la reutilización entre desarrolladores tiende a realizarse a través de bibliotecas no publicadas con interfaces (relativamente) inestables. TortoiseSVN también permite que Subversion brinde soporte a equipos multidisciplinarios con miembros que no son programadores profesionales (por ejemplo, ingenieros de sistemas, ingenieros de algoritmos u otros especialistas en el área temática).

Si su equipo está distribuido, con miembros que trabajan desde casa o desde muchos sitios internacionales diferentes, o si prefieren trabajar solos y en silencio, con poca comunicación cara a cara, entonces un DVCS como Git o Mercurial será una buena opción. ajuste cultural.

Si, por otro lado, su equipo está ubicado en un solo sitio, con un enfoque de "equipo" activo para el desarrollo y mucha comunicación cara a cara, con un "zumbido" en el aire, entonces SVN puede ser un mejor ajuste cultural, especialmente si tienes muchos equipos interdisciplinarios.

Por supuesto, es posible configurar Git y Hg (potentes y flexibles como son) para que hagan casi lo que quieran, pero definitivamente es más trabajo y definitivamente son más difíciles de usar, particularmente para aquellos miembros del equipo que naturalmente, no estaría inclinado a utilizar ningún tipo de control de versiones.

Finalmente, también encuentro que compartir la funcionalidad usando el desarrollo de bibliotecas "en caliente" bajo Svn (con CI y un enfoque basado en pruebas) permite un ritmo de desarrollo coordinado que es difícil de lograr con un equipo más distribuido y poco acoplado.

William Payne
fuente
1

Hay dos tendencias principales en el control de versiones en este momento; Distribución e Integración .

Git es genial en la descentralización.

SVN tiene muchas herramientas integradas que se integran con él. Es común configurar su servidor SVN para que cuando registre una solución, mencione el número de error en el comentario de registro, y lo configura automáticamente pero en un estado "en prueba", y alerta al probador asignado que necesitan Míralo. Luego puede etiquetar una versión y obtener una lista de todos los errores corregidos en esta versión.

Las herramientas que hacen esto con SVN son maduras y se usan todos los días.

Sean McMillan
fuente
-1

En Subversion, puede editar los mensajes de registro (también llamados "mensajes de confirmación") después de que se realiza la confirmación y se empuja. Para la mayoría de los usos prácticos, esto es imposible por diseño en sistemas descentralizados, incluido git. Por supuesto, en git puedes hacer "git commit --amend", pero eso no te ayuda después de que tu commit haya sido enviado a otra parte. En SVN, cuando edita el mensaje de registro, lo está haciendo en el repositorio central que todos comparten, por lo que todos obtendrán la edición y sin que cambie el identificador de la revisión.

Editar mensajes de registro después del hecho suele ser muy útil. Además de corregir un error u omisión en un mensaje de registro, le permite hacer cosas como actualizar un mensaje de registro para referirse a una confirmación futura (como una revisión que corrige un error o completa el trabajo introducido en la revisión actual) .

Por cierto, no hay peligro de perder información. Los ganchos pre-revprop-change y post-revprop-change pueden guardar un historial de los mensajes antiguos si realmente le preocupa, o enviar correos electrónicos con el mensaje de registro diff (esto es más común, en realidad), para que haya un pista de auditoría.

Karl Fogel
fuente
1
esto también es sencillo de hacer en git; por ejemplo, git --amend; Otra forma de hacerlo es a través de git reset --soft HEAD ^, que simplemente retrocede pero no altera el índice, por lo que puede editar / reescribir el mensaje de confirmación.
doug
Hola doug Sí, puede hacerlo para su repositorio local, pero estoy hablando de una vez que haya empujado el cambio a otra parte: "git commit --amend" no lo ayuda mucho en ese momento. En SVN, puede editar el mensaje de registro en el servidor central, precisamente porque existe un concepto de servidor central. Eso es lo que quise decir con "imposible por diseño en sistemas descentralizados". Editaré mi respuesta para aclarar esto.
Karl Fogel
1
Me encanta cómo "se puede jugar con la historia" es supuestamente una característica . Lo consideraría un error si no fuera intencional.
cHao