SVN: ramas personales para cada desarrollador?

Question

Seré honesto, las ramas de SVN me asustan. El último proyecto en el que trabajé y que los usé extensamente, parecía pasar la mitad del tiempo probando que mi sucursal funcionaba, haciendo una combinación ficticia en el tronco, haciendo una fusión real, solo para encontrar a alguien más que acababa de comprometerse mientras lo hacía y Tuve que actualizar y comenzar de nuevo.

En ese proyecto en particular, la bifurcación se realizó por desarrollador ... había un tronco y luego tenía su rama personal, trabajó en una tarea y volvió a fusionar el rango de revisiones. Parecía horrible ya que tenía que verifique cada vez que la última revisión en su sucursal fue la que se fusionó.

¿Es este paradigma realmente bueno, y simplemente no lo obtuve ya que no estoy acostumbrado al uso de línea de comandos SVN? ¿O fue un sistema terrible?

Answer 1

Para ser sincero, probablemente quieras algo más, como git.

http://git-scm.com/

Answer 2

nunca he usado rama por desarrollador. La idea no tiene sentido para mí.

Para empezar, debe alinear su equipo de desarrollo para que la gente tienda a trabajar en diferentes partes del código fuente. Si todos editan constantemente los mismos archivos, ninguna tecnología realmente ayudará a mantener a todos coordinados.

SVN hace un gran trabajo al fusionar ediciones de personas diferentes para aquellas ocasiones en que las personas trabajan en los mismos archivos. Escriba pruebas unitarias para ayudar a garantizar que el producto del código fusionado aún funcione.

Utilizo las ramas para mantener la versión actual del código mientras desarrollo la próxima versión.

Answer 3

El problema con las ramas de desarrollador no son las sucursales en sí mismas sino (como usted mismo lo escribió) la fusión. Lamentablemente, la fusión sigue siendo un problema con svn. Si bien las ramas de desarrollador sí tienen sentido, la herramienta es el problema. Estoy usando git (con git svn) desde hace un tiempo y las ramas de desarrolladores simplemente se vuelven naturales porque el soporte para la fusión es manera mejor - solo puedes fusionar, y mientras continúen los conflictos de fusión, son (según mi experiencia) sucediendo mucho menos y son mucho menos dolorosos.

Answer 4

Parecía horrible ya que tenía que comprobar cada vez que la última revisión en su bifurcación fue la que se fusionó.

Solo quería señalar que ya no tiene que hacer esto: SVN 1.5.0 y soporte de seguimiento de fusión de soporte.

Answer 5

Por ramas de desarrollador son un paradigma válido. El principal beneficio que encontré fue que te permiten verificar el trabajo en progreso y, por lo tanto, obtener una copia de seguridad, a la que acceden otros en caso de que estés mal, etc. sin molestar al tronco principal.

Las sucursales mismas no son realmente un problema, los problemas son la gestión de las fusiones. Lo que hice en el pasado es usar un token de combinación (el juguete suave o la figura de acción funciona bien; el que tiene el token puede fusionarse con el baúl) o tener cola de fusión en el wiki del desarrollador, básicamente solo tiene un desarrollador que se fusiona tronco a la vez.

Answer 6

He estado trabajando con CVS y SVN durante casi 10 años y el uso de la rama por desarrollador también me asusta :).

Todos los equipos en los que trabajaba usaban el tronco para el desarrollo diario y las ramas para la versión congelada/beta/versión (a veces se implementaron nuevas características independientes en la rama separada).

Las ramas se fusionaron de nuevo en el tronco por uno de los desarrolladores (SVN) o por el autor (CVS).

Y como fusionarse como práctica diaria desde Subversion 1.5 es fácil, no debería haber ningún problema para hacer una fusión.

Answer 7

El beneficio principal, como yo lo veo, de tener una sucursal por desarrollador es que puede establecer una política de registros frecuentes, sin duda teniendo a todos registrando el código cada noche, independientemente del estado de su código, ya que no lo harán romper la construcción de los demás, y mucho menos la línea de desarrollo principal.

Esto significa que usted tiene una copia de seguridad nocturna del trabajo de las personas, y es más fácil para el desarrollador volver a una versión (parcialmente) de trabajo de su desarrollo si se equivocan o si presentan un problema con la implementación de un algoritmo.

También se asegurará de que solo el código completamente aprobado y probado (suponiendo que esté haciendo revisiones de código y pruebas de unidades) se compruebe en la línea principal.

Estoy de acuerdo en que la fusión puede ser onerosa, pero si todos constantemente (al menos un par de veces a la semana, preferiblemente una vez al día) integran desde la línea principal a su sucursal el impacto de la fusión del desarrollador la rama debe ser mínima.

Answer 8

Si realmente necesita hacer sucursales por desarrollador, realmente debería usar Git, está diseñado desde cero para administrar la "copia de trabajo" de cada desarrollador como un repositorio propio y la fusión está integrada en el núcleo de eso.

Answer 9

Pruebe usar Mercurial. No tiene repositorio central por diseño.

No hay conflictos de compromiso también, porque no hay empuje.

Answer 10

He utilizado una estrategia de sucursal similar en SVN en mis últimos equipos (equipos pequeños: actual es de 4 desarrolladores) y he adoptado el enfoque en TFS en mi equipo actual.

Sucursal por elemento de trabajo de seguimiento de fallos.

Esta estrategia proporciona el beneficio de rama por desarrollador de un entorno de control de fuente aislado para el desarrollador donde puede eliminar el código, revertir, etc. usando los lujos que SVN proporciona pero nunca permite que el desarrollador se desvíe demasiado lejos de la línea principal en el maletero. El desarrollo de características de larga data fuera del tronco está bastante desaconsejado. La idea se refuerza al enfatizar que el alcance previsto + la duración de un elemento de trabajo de seguimiento de errores no debe exceder significativamente un día hábil.

En la práctica, he encontrado que esto se traduce en pequeños conjuntos de cambios que se fusionan en el tronco con bastante frecuencia. Dada la naturaleza pequeña de mis equipos, rara vez pisamos los pies de los demás para obtener una fusión, por lo que los conflictos no suelen ser problemáticos.

Diré, este sistema era bastante cómodo en SVN: menos en TFS, que no parece manejar fusiones tan elegantemente como SVN 1.4 incluso, y mucho menos 1.5+.

Answer 11

de subversión, yo uso "rama de trabajo (es)" que son propiedad de un equipo y compartida por todos los miembros del equipo, como se describe en la gran Version Control for Multiple Agile Teams artículo y se ilustra a continuación:

Recomiendo encarecidamente leer el documento completo, realmente vale la pena leerlo.

Con algo más que Subversion, puedo considerar el uso de "ramas de características" pero, para ser honesto, no veo el sentido de las ramas personales por desarrollador (y no tiene sentido para mí ir más allá del granularidad de una característica).

Answer 12

He utilizado una práctica similar en el pasado.

Si varios desarrolladores están actualizando los mismos archivos de código, puede que no sea un problema de control de versiones. No sé nada sobre tu código, pero ¿podría ser que sea demasiado monolítico y no lo suficientemente modular? De esta forma, cuando las asignaciones se distribuyen, los desarrolladores no siempre se ponen en función de los cambios de los demás.

Answer 13

Su paradigma debe ajustarse a la afinidad de la herramienta. Subversion es la herramienta incorrecta para ese paradigma porque la fusión en Subversion es un PITA. Cambie su paradigma o cambie a Git o Mercurial.

Answer 14

Utilizamos una única rama de desarrollo para la mayoría de las operaciones cotidianas. A través de la experiencia, hemos aprendido que cuando un desarrollador está trabajando en un proyecto realmente grande que expande múltiples módulos, debe crear su propia rama y trabajar a partir de eso. De lo contrario, no hemos tenido ningún problema al ejecutar desde una única rama svn, y esto simplifica enormemente las cosas. Advertencia, tenemos un pequeño equipo de 3 desarrolladores + el contratista ocasional.