El mejor sistema de control de fuente para mantener diferentes versiones

Question

Necesitamos ser capaces de mantener simultáneamente un conjunto de diferentes versiones de nuestro sistema. Supongo que esto se hace mejor usando ramificación. Actualmente usamos TFS2008 para control de fuente, elementos de trabajo y compilaciones automáticas.

¿Cuál es la mejor solución de control de versiones para esta tarea? Nuestra organización está en proceso de fusionarse con TFS2010. ¿Nos dará TFS2010 la funcionalidad que necesitamos para administrar fácilmente una serie de sucursales por versión del sistema? Necesitamos ser capaces de mantener cada versión aislada de las demás, de modo que podamos hacer pruebas e implementarlas para cada versión.

Nuestro equipo de desarrollo consta de 5 desarrolladores .net y dos desarrolladores de Flash.

He oído hablar mucho de GIT. ¿Deberíamos considerar usar GIT en lugar de TFS para control de fuente? ¿Es posible usar TFS2010 junto con GIT? ¿Alguien tiene configuraciones similares que funcionan bien?

¡Cualquier sugerencia es apreciada!

Gracias,

Kjetil.

Answer 1

La razón principal por la que debe tener en cuenta Git (o Mercurial) es para:

• su Distributed nature
• su facilidad de fusión (una consecuencia, en realidad, de ser distribuido)
0.

Si su equipo está ubicado en un sitio, y si su proceso de desarrollo es lo suficientemente lineal (flujo de trabajo de combinación simple), basta con un VCS centralizado.

A partir de ahí, TFS2010 ha hecho algunas evoluciones interesantes, especialmente en su branching model, y sus otras características integradas (jerarquía de elementos de trabajo, compilación con "Gated Check-in" y basado en una "Workflow Foundation") hace es un mejor candidato que una herramienta limitada al aspecto de VCS.

Answer 2

TFS 2010 - Indiscutiblemente. No por ser un gran sistema de contrrol de versión, sino por todo lo demás que hace. GIT lo dejará abierto para seleccionar el seguimiento de elementos de trabajo, integración continua nuevamente. Mantener el número de proveedores (tecnologías bajas es un núcleo para una mejor administración.

Answer 3

Mercurial también hará el trabajo.

Aquí es un excelente tutorial en él.

Answer 4

Actualmente existen principalmente dos tipos de sistemas de control de versiones (VCS), los llamados VCS distribuidos y los sistemas de depósito central.

Los VCS "distribuidos" más populares en la actualidad son git y mercurial. Los sistemas de repositorio central más populares son Subversion y SourceSafe de Microsoft. La introducción http://hginit.com explica la superioridad del VCS "distribuido" sobre el sistema central.

Con un VCS distribuido, cada desarrollador tiene su propio repositorio local. Generalmente se usa con un depósito central compartido que contiene el lanzamiento oficial. Pero esto es solo una organización de repositorio. Los VCS "distribuidos" son superiores a los VCS puramente centralizados en cuanto a su capacidad para gestionar la fusión.

Answer 5

Subversion !!!

me gusta Subversion, + + TortiseSVN VisualSVN

http://subversion.tigris.org/
http://tortoisesvn.tigris.org/
http://www.visualsvn.com/

Subversion y Tortise son libres !, y VisualSVN es de sólo $ 50 por licencia (pero usted no tiene que utilizar Visual-SVN, es solo la integración de VS .... no es necesario en lo que a mí respecta.)

Aquí hay un tutorial y una guía de instalación para los tres productos.
http://www.west-wind.com/presentations/subversion/

y otro ...
http://www.dev102.com/2008/10/07/how-to-use-the-svn-client-and-start-working-with-your-subversion-version-control/

Answer 6

Todos los requisitos que necesita están incluidos en TFS 2010. La ramificación, y mantener las ramas aisladas.

TFS es más como un sistema de control de versiones. También es un sistema de control de errores/trabajo y tiene herramientas para compilación integrada. Si los necesita y ya tiene una licencia para TFS 2010, no pierda su tiempo en otros sistemas.

OK, TFS no se distribuye, pero en realidad, cuando trabajo me gusta que TFS no se distribuya. Tan pronto como revise el material (en mi sucursal personal) estará en la copia de seguridad diaria, y está disponible para que otros lo puedan ver. (Para mi casa/hobby/cosas personales uso mercurial).

Para todos los demás sistemas hay herramientas disponibles que le proporcionan la construcción y el seguimiento de errores, por lo que no es un problema para otras herramientas que no están disponibles, simplemente toma tiempo seleccionar las que coinciden con sus necesidades.

Answer 7

Me encanta git y se está integrando también en muchas otras aplicaciones, como Eclipse, Trac. quién tiene que pagar un VCS cuando tienes Git.

El hecho de que el desarrollo del kernel de Linux use git, lo sé porque Linus lo dijo :), que no es un proyecto pequeño, habla por sí mismo.

Answer 8

Un buen sistema de control de revisiones me ayudará cuando estoy trabajando de forma dispersa. No porque me gusta estar disperso, sino porque las demandas diarias de tienen una forma de dispersar cómo se trabaja. La dispersión se agrava cuando un grupo está trabajando en paralelo en un proyecto de tamaño decente.

La persona A está trabajando en la característica 1. La persona B está trabajando en la característica 2. La persona C está trabajando en la reparación de errores reportados en la versión publicada.

Mientras A hace su trabajo, observa un error en el código y lo arregla en el lugar para no pasarlo por alto, y continúa. La persona C hace 3 correcciones.

A, B y C tienen chat y B siente que necesita las correcciones de errores C ha hecho de inmediato, así como la corrección de errores que A ha hecho, pero no la función A. C quiere una corrección de errores de A. A quiere las correcciones de errores de C. Y así sucesivamente.

Boss decide que queremos una versión con la característica 1, otra versión con la función 2, y una versión con ambas funciones, y una versión con ninguno de los dos lanzados y mantenidos.

¿En qué medida el soporte de herramientas que en estas actividades? ¿Cuánto te obstruye la herramienta en estas actividades?

estoy muy feliz con darcs ''.

He intentado con muchos sistemas de control de revisiones. No he encontrado ninguno mejor.

Es simple, es rigurosamente correcta.

Debido a que es rigurosa es fiable y predecible. Porque es simple, es útil y no se interpone en su camino.

Mi segunda opción sería Git.

Git es bastante bueno, pero no tan riguroso, obliga un pedido en usted en algunas ocasiones cuando el orden no importa. Git es mejor conocido por lo que un mejor curriculum vitae.

http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

Answer 9

Basado en mi experiencia, si usted está buscando un DVCS, Git o Mercurial (Hg) es el camino a seguir. Decidir entre Git y Hg es una tarea más difícil, sin embargo.

¿Está utilizando principalmente Windows? Si es así, Hg es probablemente tu amigo. Combinado con TortoiseHg, es una herramienta muy buena y versátil, que es fácil de usar en comparación con Git. Es un poco menos complejo, pero maneja la mayoría de las cosas que Git puede manejar, incluso si no es tan fácil como sin problemas.

Si está usando Linux o Unix una concha, Git sería mi elección. Yo personalmente uso Git en Windows, usando la utilidad git shell. (también funciona bien en Cygwin, si lo prefiere) He descubierto que Git maneja mis proyectos mucho mejor que Mercurial. Sin embargo, si no eres un experto con una línea de comandos, he encontrado que TortoiseGit es un poco más complicado (y complicado) que TortoiseHg. Pero como estoy familiarizado con bash, definitivamente git es mi preferencia. Es simplemente más rápido, más delgado y más versátil que Hg, en mi tiempo con los dos. Es simplemente un poco más complicado, por lo que la curva de aprendizaje es más alta y desde el principio puede ser propenso a cometer errores con ella, como lo estuve por un corto tiempo.

Así que en mi opinión, las preguntas reales son:

de Windows (Hg) o Unix (Git)

y

gráfica (TortoiseHg) o de línea de comandos (Git cáscara)