Advertencia: desde esta publicación he encontrado Mercurial y me encanta mucho mejor que SVN. Entonces, esta publicación está un poco desactualizada con los comentarios de Pro SVN y el anti-DVCS general, pero el material anti-git sigue siendo relevante
Soy fanático de SVN sobre Git.
¿Por qué? Porque SVN fue mucho más fácil para un desarrollador único o un equipo pequeño, y git (específicamente msysgit) me dejó con un mal sabor de boca.
Cuando estaba haciendo una pasantía en una pequeña tienda, me presentaron a git en Windows. Inmediatamente me di cuenta de la cantidad de trabajo que tomó para que funcione con Github. Primero, tuve que generar una clave privada ssh, pegar la clave pública en Github, luego mostrar el concurso y abrir mi clave privada cada vez que quería presionar, lo cual fue extremadamente molesto.
Y nunca me gustó realmente que estaba bajando todo el repositorio. Admitiré que nunca trabajé con nada enorme, pero me daría miedo descargar el repositorio de KDE en Git si todo el repositorio y sus revisiones están en mi HD.
Luego estaba el proceso confuso para hacer un compromiso. TMK, primero tuve que "poner en escena" todos los archivos que quería comprometer (lo cual apestaba cuando tenías muchos archivos, me tomó un tiempo encontrar el comando manual para organizar todo), luego hacer el compromiso, luego empujar a la página principal repositorio (¿por qué es una operación separada?)
También tenía los datos de confirmación no muy útiles (!). Oh mira, esto es commit 14f74433245ae17aeeaa parte del árbol 2167a4934d0a4a7db0de y padre d7042abb4821d3faf600. ¿Qué demonios significa eso? Debería poder resolver las cosas bastante rápido y no tener que consultar alguna documentación extraña.
Hablando de documentación, al menos cuando la estaba usando, parecía que todo estaba en formato de archivo man de Linux, IE confuso e inútil para mí. Raramente pude encontrar mucha ayuda en los documentos y simplemente recurrí a google.
Y con commits, lo único que no me gustó fue la falta de números de versión. Ahora sé que esto se debe al diseño de git, pero cualquier software necesita un número de versión. Todavía recuerdo las confirmaciones de marcador que aparecerían diciendo "Versión modificada a 1.8.6" o algo similar, pero aún no se podían hacer números de compilación. Para mí, tener la versión 1.8.6.5164 (la última parte es el número de revisión) me dice mucho más que simplemente 1.8.6 y una nota que dice que algo menor cambió, pruébalo
Obteniendo software específico, el programa base en Windows es msysgit, que es una interfaz terrible. Me bloqueó varias veces, tenía una interfaz horrible y la integración de CLI-GUI era dudosa en el mejor de los casos. Los adictos a la línea de comando a mi alrededor odiaban la interfaz gráfica aún más.
Ahora veamos SVN. Y como estoy en Windows y tengo una cuenta de Google, específicamente TortoiseSVN y Google Code.
Primero, complete la integración de shell para hacer todo en el repositorio (y para ustedes, Linux, RabbitVCS hace lo mismo), no se necesita una GUI principal. Obtener un repositorio es fácil como pagar, no se necesita SSH (no recuerdo si Github requirió SSH para extracción), y no hay repositorio completo + todas las confirmaciones pasadas en su HD.
Comprometerse es extremadamente fácil, principalmente porque no se requiere SSH o puesta en escena. Simplemente marque todos los archivos que desee utilizando la muy útil opción Seleccionar todo que en mi versión de msysgit no estaba disponible, escriba un mensaje de confirmación y presione confirmar. Luego, Google Code le solicita su información de inicio de sesión (que la mayoría de los clientes almacena), y listo. Simple, fácil y sin SSH
Números de versión? Con un código fácil, puede agregar un número de versión y un número de confirmación a todos los pagos, lo que facilita mucho las cosas. También obtiene números de versión utilizables que realmente muestran un cambio, por ejemplo, 1.8.6.5165 es más reciente que 1.8.6.5164.
¿Documentación? Bueno, es difícil de decir. Tortuga está documentada, pero en realidad no me he referido a la documentación oficial en tanto tiempo que no puedo juzgar. Leer una simple guía de introducción fue suficiente para mí.
La fusión es algo más que no puedo comparar. Tuve que hacerlo una vez en Git cuando alguien más cometió un cambio en un archivo en el que estaba trabajando, pero nunca en SVN.
¿Cuál recomendaría? Bueno, en equipos grandes, git tiene sus ventajas, principalmente en su ciclo de desarrollo no lineal. En otro proyecto, vi a 4 programadores comenzar en ramas separadas, luego fusionar todo el código de maneras muy extrañas que de alguna manera se transformaron en la rama maestra final. Github y msysgit tenían una herramienta de visualización realmente agradable para todo el proyecto que realmente me gustó.
Para proyectos de desarrollador único o equipo pequeño, SVN sería el mejor ya que la mayoría de las características de Gits no se usan y solo obtienes sus partes negativas. La simplicidad es algo tan bueno
