2010-02-18 21 views
7

Las ventajas de usar git-svn sobre git son obvias (compatibilidad con svn), pero ¿cuáles son las ventajas de git over git-svn?¿Cuáles son las ventajas de git over git-svn?

+5

El acceso a svn no es una "ventaja de git-svn over git". El propósito de git-svn es darte las ventajas de git sobre svn. No puede usar git-svn sin usar git. –

Respuesta

5

Simplemente significa que tiene menos VCS para administrar en su cadena de desarrollo (svn).
En términos de administración:

  • que se quedan con repositorios distribuidos gestionados por Git, cada uno autónoma con su historial completo de
  • que no tiene que mantener una conexión a una central de repo SVN.
  • puede organizar sus copias de seguridad de forma diferente (empujando sus datos a un acuerdo de recompra desnuda copia de seguridad remota, o exportar tu repositorio Git a través git bundle)

Y, por supuesto, puede gestionar toda la advantages of Git over SVN.

+0

¿Puede ser más detallado en términos de uso real (es decir, velocidad, funcionalidad)? – Mike

+1

@Mike: He completado mi respuesta. – VonC

3

git-svn y git comparten la misma funcionalidad mientras trabajan localmente. La diferencia aparece cuando uno envía o recibe modificaciones del repositorio remoto.

  1. Push vs. dcommit.

    ¿Por qué git-svn necesita este comando por separado dcommit?

    Porque el repositorio de Subversion se comporta de forma diferente al repositorio remoto de Git: SVN siempre intenta combinar los cambios entrantes en el nivel de los directorios. Si uno modifica un archivo que fue modificado simultáneamente por otro usuario, SVN rechaza las modificaciones entrantes con el error obsoleto. De lo contrario, commit/dcommit pasa.

    En oposición a eso, Git push devuelve obsoleto error cuando se modifica la misma rama/etiqueta, sin importar qué archivos se tocaron.

    Como resultado, git-svn dcommit tiene que asegurarse de que la versión que acaba de confirmar es la misma que espera (algunos directorios podrían fusionarse automáticamente durante dcommit). Eso significa que git-svn siempre tira/recupera los cambios que acaba de enviar al repositorio SVN.

  2. El archivo ignora.

    Cuando uno ignora ciertos archivos en un árbol de trabajo y confirma esta modificación, no hay forma de enviar esta modificación con git-svn dcommit. Por lo tanto, no hay forma de compartir ignores con otros usuarios de repositorio SVN.

  3. Atributos de Git.

    Tanto Subversion como Git tienen ciertos metadatos asociados con archivos y directorios. Al igual que en .gitignore, no hay forma de compartir .gitattributes con compañeros de trabajo.

  4. Merge commits.

    Finalmente, cuando se intenta dcommit una fusión se cometen, existe la posibilidad de que ciertas confirmaciones no se envíen al repositorio SVN en absoluto.Eso sucede cuando todas las confirmaciones de una sucursal fusionada aún no se habían comprometido al repositorio SVN.

La mayoría de estos problemas de git-svn son difíciles o incluso imposibles de solucionar. Puede considerar SubGit - una alternativa del lado del servidor a git-svn que corrige la mayoría de ellos. Para obtener más información, consulte SubGit documentation y SubGit vs. git-svn comparison.

Cuestiones relacionadas