2010-12-01 13 views
7

He escuchado mucho sobre cómo Git ha rediseñado cómo funciona la bifurcación y cómo el modelo de bifurcación de SVN está estropeado.¿Por qué la bifurcación en SVN no es lo suficientemente buena?

No he usado mucho SVN, así que no tengo ideas preconcebidas sobre cómo debería ser una rama. Primero miré las ramas de git, y lo "conseguí".

¿Cuáles son los inconvenientes prácticos de las ramas de SVN?

Se recomiendan las respuestas del punto de vista del flujo de trabajo, la estrategia de bifurcación y el rendimiento de la sucursal (en términos de tiempo de confirmación/salida/cambio).

Gracias, JRH

+3

No consumo Git o cualquier otro DVCS, pero esto http://hginit.com/00.html y este http://kiln.stackexchange.com/questions/892/how-will-mercurial-be-better-than-subversion-when-one-user-refactors-code y año podría ser útil para usted. – sharptooth

+0

Al menos - SVN no ha diseñado originalmente "ramas" como entidad separada. Y aún ahora, no hay sucursales, solo hay una copia de directorios/archivos y maneja las revisiones que se fusionaron. Simplemente trate de trabajar con mercurial o git y sorprenda lo simple que puede ser el trabajo con ramas. – zerkms

+0

No sé mucho sobre el funcionamiento interno, pero creo que la bifurcación en SVN es una cuestión de "copiar" todos los archivos a otra ubicación y en Git se trata de etiquetar el código – jab

Respuesta

4

Algunas cosas vienen a la mente

  1. Todas las ramas se almacenan en el repositorio central. Si no está conectado a ese servidor, o su conexión es lenta, entonces no podrá acceder a ellos rápidamente.
  2. Todas las ramas se almacenan en el repositorio central. Esto significa que son públicos, cualquiera en el equipo puede verlos. No hay forma de mantener una sucursal privada a la que nadie más tiene acceso.
  3. El DAG de confirmaciones contiene suficiente información para que pueda averiguar qué cambios se incluyen en su versión actual del código, incluidos los cambios de cualquier número de ramas. En svn, IIRC, esto se hace usando una propiedad svn:mergeinfo, que es más complicada en mi humilde opinión, y es propensa a errores porque alguien podría olvidar comprometer la propiedad modificada.
0

El problema principal es que Subversion hace un mal trabajo rastreando los cambios y fusionando información (por ejemplo, los directorios no son objetos de primera clase y no hay verdadero soporte de cambio de nombre). Tan pronto como intenta cambiar los puertos entre las ramas, comienza a tener conflictos. Algunos conflictos son razonables (la misma línea fue editada en ambas ramas) pero otros tienen poca explicación.

Si están pidiendo incluso está claro que no está mintiendo y no se ha usado Subversion demasiado, porque estos conflictos aparecen casi de inmediato :)

Cuestiones relacionadas