2009-08-10 38 views
24

Estamos pensando en cambiar a SVN en mi trabajo, por lo que me preguntaba sobre los complementos SVN para VS2008 (y 2010 cuando se publique). Después de un poco de investigación encontré AnkhSVN y VisualSVN, los 2 que parecían más dominantes. (Estoy al tanto de TortoiseSVN y usaré el complemento junto con él).AnkhSVN vs VisualSVN

Soy consciente de que esto ha sido askedbefore, pero estas preguntas fueron formuladas hace casi un año y todos sabemos que muchas cosas pueden cambiar en un año.

La pregunta: Según su experiencia, ¿cuál es mejor y por qué?

Respuesta

23

De acuerdo, ha pasado un año desde que utilicé cada producto cabeza a cabeza, pero mi preferencia actual es AnkhSVN. Aunque la gente se quejó de las primeras versiones de AnkhSVN, el 2.0 era casi una reescritura del original y ahora es un paquete completo de integración de proveedores de control de código fuente en lugar de un complemento de Visual Studio. Con el respaldo comercial de CollabNet y el renovado entusiasmo de las fuentes abiertas, AnkhSVN 2.0 merece una oportunidad.

Mis dos características favoritas de AnkhSVN son que es gratis y me encanta la ventana de Cambios pendientes.

En cuanto a VisualSVN, me parece que es lento y creo que aprovecha TortoiseSVN en lugar de manejar la administración de archivos con demasiada frecuencia. Y cuesta dinero (aunque sea una pequeña cantidad)

De nuevo, esto se basa en mi última prueba directa, que fue hace aproximadamente 1 año.Como ya se dijo, TortoiseSVN es excelente por sí solo, pero si realmente quieres conectarte al VS IDE, dale un giro a AnkhSVN antes de VisualSVN. La mejor de las suertes.

+4

AnkhSVN es definitivamente mejor desde 2.0, vale la pena intentarlo. –

+1

+1 ¡Intentaré probar 2.0! –

8

He intentado ambos plugins de VS ... después de varios meses de uso ¡rápidamente me di cuenta de que pasaba TODO mi tiempo en Tortoise! Los complementos no reciben todos mis elementos relacionados con el tronco. Solo funcionan con elementos que son parte de la solución y que VS reconoce. Por esta razón, pasé casi todo mi tiempo en Tortoise ... y eventualmente todo mi tiempo. No hay razón para pagar complementos cuando Toroise es gratuito y se actualiza casi a diario.

Stick with Tortoise y aprende a usarlo. Serás más feliz al final.

respuestas:

@jeroenh: "... No es realmente una ventaja de utilizar un (debidamente integrado) VS plug-in, es decir, al mover/renombrar archivos en su solución ...."

Acepto que renombrar/mover archivos en Tortoise es torpe. Y VisualSVN hace esto más fácil.

@Darko Z: "a nivel personal estoy de acuerdo, pero a nivel organizativo No tenemos algunas personas aquí que necesitan VS integración Sí, es tonto, pero lo suficientemente :) justo".

Sí, tengo varias personas así en mi equipo actual. ¡Y entrenarlos para que se acostumbren a Tortoise ha sido un oso! Ellos son la razón por la que obtuvimos algunas licencias para VisualSVN ... pero también se quejaron de eso.

+0

a nivel personal Estoy de acuerdo, pero a nivel organizacional no lo hago. Tenemos algunas personas aquí que * NECESITAN * integración VS. Sí, es tonto pero justo :) –

+16

No estoy de acuerdo. Realmente existe la ventaja de utilizar un complemento VS (integrado correctamente), concretamente al mover/cambiar el nombre de los archivos en su solución.Si no usa AnkhSVN o VisualSVN, tendrá que hacer esto a través de TortoiseSVN y sincronizar su archivo de solución posteriormente, o hacerlo en Visual Studio y corregir el cambio de nombre/movimiento con TortoiseSVN. De cualquier manera, torpe, propenso a errores y lento. – jeroenh

4

Uso VisualSVN por el momento, y es genial, ya que agrega automáticamente nuevos archivos al SVN y permite revertir fácilmente y diff sin tener que abrir una ventana del explorador. Sin embargo, aún necesitará usar TortoiseSVN para archivos que no estén en su solución de Visual Studio.

La última vez que utilicé AnkhSVN no funcionó muy bien y arruiné mi verificación de SVN (pero esto fue hace un par de años).

+3

¿qué voto? – Lodle

6

Tuve el mismo dilema también hace unos meses, y finalmente decidí irme con VisualSVN. Lo hemos estado usando durante 4 meses para el desarrollo de aplicaciones web internas de C# y nuestra experiencia ha sido positiva.

En primer lugar, la parte del servidor se integra con Active Directory y ofrece un control MMC fácil de usar para administrar los repositorios.

En segundo lugar, la parte del cliente se integra con VS2008, no ralentiza los tiempos de carga de Visual Studio y funciona con códigos de color bastante triviales (verde para archivos intactos, amarillo para archivos cambiados). Cuenta con diff de revisión completa, puede comentar cada revisión.

Un inconveniente es que sus soportes para ganchos (como los ganchos post-commit) son muy rudimentarios.

Puede ver estadísticas como quién realizó la mayoría de las confirmaciones, etc. Admite sucursales, aunque no las utilizamos. Toda la comunicación cliente-servidor se realiza a través de SSL (las claves y los certificados se configuran automáticamente).

les hizo una pregunta en algún momento acerca de cómo eliminar el historial rama del Estudio Visual desplegable, y su apoyo respondió que simplemente tenía que eliminar el archivo .suo (servicio al cliente eficiente)

Por último, mi experiencia al trabajar con VisualSVN: simple y directa para nuestro equipo relativamente pequeño. (somos 5 programadores, pero estoy bastante seguro de que esto se escala mucho más que eso).

+1

El servidor VisualSVN es una elección independiente del cliente. (Y no es una opción para los desarrolladores). –

+3

No entiendo el voto a la baja. Pensé que sería útil compartir algo de la experiencia de la vida real aquí. La parte del servidor es independiente del cliente. –

0

Esa pregunta que usted hace se reduce a las preferencias personales, pero le aconsejaría que tenga ADEMÁS del al cliente ide, ya sea Tortoise SVN o el cliente de línea de comando. A menudo se lo forzará a posiciones en las que el cliente IDE no puede realizar la tarea que necesita.

+5

Ya he indicado que lo usaré junto con TortoiseSVN –

3

He usado ambos y prefiero Visual SVN (a partir de v3.0.4) debido a su integración con Tortoise SVN que ya uso y estoy bastante familiarizado. Debido a esta familiaridad y la integración de VisualSVN con él, lo prefiero un poco más.

Creo que no hay argumento de que AnkhSVN (a partir de v2.4.11610) tiene más características integradas en VS.NET, pero está trabajando con sus propias ventanas de diálogo y mensajes que son no difícil acostumbrarse, pero Nuevamente me gustó la funcionalidad y la familiaridad de Tortoise SVN.

Además, dado que toda mi tienda utiliza Tortoise SVN a través de Windows Explorer, la transición a Visual SVN no es tan importante aparte de agregar la integración agradable directamente en VS.NET. No sufrí ninguna de las trampas comentadas en los otros mensajes aquí (la mayoría son de hace 3-4 años parece) cuando utilicé VisualSVN en los últimos 30 días.

Así que aquí está lo que digo: si usted es un usuario importante de Tortoise SVN y le gusta cómo funciona, vaya con VisualSVN. Si eres nuevo en Subversion y realmente no te importa, entonces ir con gratis AnkhSVN con sus características integradas adicionales es probablemente el camino a seguir.

+0

* Hm. ¿Qué tiene AnkhSVN que VisualSVN no tiene? Me refiero a las "características integradas adicionales" que ha mencionado. * Tenga en cuenta que a partir de la versión VisualSVN 3.0 hay una Licencia de comunidad gratuita que se puede activar en máquinas que no son de dominio. – bahrep

+1

Creo que los cambios pendientes y las capacidades de seguimiento de fusión podrían ser un poco más robustos. Sin embargo, para una mirada completa a la (2) mira las características de VisualSVN aquí: http://www.visualsvn.com/visualsvn/features/ y AnkhSVN aquí: http://ankhsvn.open.collab.net/ankhsvn/ caracteristicas – atconway

Cuestiones relacionadas