2009-11-19 15 views
5

Estoy a punto de comenzar un proyecto y estaba pensando en utilizar Google Code para alojarlo. Da la opción de usar Mercurial o SVN para el control de versiones. Nunca antes había usado un VCS, y me gustaría saber con cuál es más fácil trabajar.¿Qué VCS debería usar con Google Code?

El proyecto involucra a dos programadores principales, pero algunos otros pueden contribuir pequeñas cantidades. Está principalmente en Python y usamos Emacs como el editor primario. Ambos estamos usando el sistema operativo Windows.

Respuesta

12

Utilice Mercurial.

Ambos sistemas serán fáciles, pero Mercurial será rápido. ¿Quieres comparar las diferencias entre lo que alguien más hizo anoche y lo que hiciste anoche? Con SVN, tomará un par de segundos por archivo mientras habla con los servidores de Google. Con Mercurial será bastante instantáneo.

Un par de segundos por diferencia puede no parecer mucho, pero los beneficios de una interfaz ágil y receptiva se harán evidentes una vez que utilice un sistema que elimine (la mayoría) de esas pausas.

Ah, y la gente puede bifurcar su proyecto sin siendo un gran dolor en el culo. Eso también es genial.

EDITAR: Mercurial tampoco siente la necesidad de colocar una carpeta .svn en cada carpeta de su proyecto. Esas cosas son feas (y no están ocultas por defecto en Windows, como si estuvieran en el sistema * nix). Solo habrá una carpeta .hg en la raíz de su proyecto, que es mucho más limpia.

EDITAR: Una razón más para usar Mercurial: hg bisect. El seguimiento de un error en 10 minutos en lugar de 2 horas porque usted pudo encontrar la revisión exacta que lo causó es impresionante. Parece que hay una herramienta Perl svn-bisect, pero no está en el núcleo, y la lentitud de SVN en la actualización entre revisiones hará que el proceso sea mucho más largo.

+0

Mercurial suena bien para mí. Lo probaré. – Nikwin

+0

Me encanta que pueda crear clones personales de otros proyectos mercuriales en el código de google. –

1

Si nunca antes ha usado un VCS, elija cualquiera. Ambos serán más que suficientes para sus necesidades, y tendrá que aprender de cero.

Mercurial está descentralizado como git, pero no me preocuparía demasiado por un equipo de 2 programadores, que nunca han estado expuestos al control de código fuente.

Elija cualquiera y olvídese de ello.

-1

Bueno, creo que deberías usar SubVersion. No porque SVN sea de alguna manera mejor que Mercurial en términos funcionales, sino porque SVN es muy popular y hay mucha documentación para ello (por ejemplo, un libro electrónico gratuito) y algunos complementos gratuitos muy buenos (AnkHSVN para VS, TortoiseSVN para Windows Explorador). Creo que la documentación lo pondrá rápidamente en funcionamiento, si nunca ha usado un VCS antes ...

HTH!

+4

Hay un libro de Mercurial y TortoiseHg y su popular ... – Murph

+1

De acuerdo ... Solo quería decir que está mejor con SVN, si está iniciando VCS desde cero. Definitivamente tiene las mejores herramientas y documentación disponible, si eres un principiante ... –

1

La respuesta simple es SVN: activa TortoiseSVN y TortoiseHg y verás que el primero está un poco más adelantado que el segundo en términos de estética y usabilidad; sin embargo, no creo que la respuesta simple sea lo suficientemente buena en este caso.

Si va a comenzar a usar el control de versiones por primera vez, me sentiría tentado (por todo lo que actualmente estoy más cómodo con SVN que Hg) de sugerir que Mercurial es la mejor manera de hacerlo. Distributed Version Control (DVCS) actualmente ofrece más flexibilidad que Subversion con su dependencia en un repositorio central. En particular, su capacidad para realizar localmente el código que no está completo antes de enviar los cambios completados a sus colegas. Mercurial tiene un "libro", por lo que tiene un conjunto de pautas para trabajar y tiene una aceptación general como herramienta para que el apoyo entre pares esté disponible.

Mi principal preocupación con DVCS es que considero que el control de versiones está incompleto sin un servidor por separado (o al menos sin un repositorio no en su caja de desarrollo) por varias razones. Sin embargo, en este caso, tendrá un repositorio central ... por lo que ese argumento es menos válido.

Tengo un problema secundario que creo que uno debe tener como objetivo introducir un servidor de integración continua (compilación y prueba) en los proyectos de uno en la primera oportunidad, pero eso es algo que se puede hacer con DVCS compartido repositorio.

todavía creo que SVN tiene muchoque comentar, nuestro repositorio de trabajo es y seguirá siendo SVN para el futuro previsible (en cuenta que yo soy el que puede decidir!), Pero igualmente estoy haciendo mis cosas personales con Mercurial y aprendiendo sobre la marcha.

+1

Yay, voto negativo sin comentarios - siempre útil ... por lo que vale, esto fue escrito hace casi dos años, fue en ese momento - TortoiseHg es significativamente mejor ahora. – Murph

+0

Dos votos a favor * más sin explicación * y, sospecho, sin pensarlo demasiado – Murph

1

Si nunca ha usado un VCS, probablemente le resultará difícil/difícil hacerlo con uno. No creo que haya diferencias de principio en eso. Sin embargo, una diferencia importante entre estos dos es que SVN está centralizado y Mercurial está descentralizado.

Si trabaja desde donde no tiene acceso a la red (aviones, trenes, etc.), un VCS descentralizado le permitirá comprometer sus cambios localmente antes de comenzar nuevos cambios. Más tarde sincronizará con el repositorio central. Esto puede ser útil.

Un VCS centralizado no permite esto. Por supuesto, puede seguir trabajando en su código, pero como no puede verificar los cambios, tendrá que confirmar los cambios acumulados de una vez cuando vuelva a tener acceso al repositorio.