Author Topic: ¿Que estructura conviene usar para el manejo de ramas de subversion?  (Read 5348 times)

mchojrin

  • Newbie
  • *
  • Posts: 1
  • Karma: 0
    • View Profile
Hola:

  Me encuentro en el siguiente problema:

  En mi trabajo usamos subversion como sistema de control de versiones, usualmente creamos ramas para los nuevos features que hay que desarrollar, las mergeamos y las publicamos.
  El problema que tenemos es el manejo de la version "viva" y las versiones de desarrollo. Actualmente el trunk es lo que va a produccion y cuando se encuentran bugs se corrigen sobre el mismo y se propagan los cambios a las ramas abiertas (features).

  Estuve leyendo que puede ser mas conveniente utilizar el trunk como linea base del desarrollo y mantener en produccion los releases, que serian en nuestro caso la integracion de los nuevos features a un trunk estable. Alguien tiene alguna sugerencia a este respecto? Gracias.

chuidiang

  • Administrator
  • Hero Member
  • *****
  • Posts: 5472
  • Karma: 12
    • View Profile
    • Apuntes de programación
Re: ¿Que estructura conviene usar para el manejo de ramas de subversion?
« Reply #1 on: Abril 27, 2011, 11:44:25 am »
No hay forma correcta de hacer las cosas, es sólo cuestión de organizarse y seguir lo que se decida.

Dependiendo de la complejidad del proyecto, la cantidad de gente, lo disciplinada que sea y tal suele haber dos formas de trabajo, la primera más sencilla, la segunda algo más compleja.

La forma más sencilla consiste en que la trunk es la principal de desarrollo, donde la gente en general trabaja. Que la trunk sea o no estable depende mucho de lo responsable que sea la gente y lo que pruebe antes de meter en svn. Cuando una versión se entrega al cliente, se suele hacer un branch con esa versión, de forma que en ese branch tienes lo mismo que tiene el cliente y ahí le corriges los bugs y le añades las mejoras, sin que le afecte la evolución de la trunk.

La forma más compleja es la que tú comentas, en la trunk se tiene siempre la última versión estable y cada nueva funcionalidad que se quiera desarrollar se hace en una rama separada que luego se integra a la trunk. Eso no quita que si se entrega una versión al cliente o se saca una versión al mercado, se haga un branch para esa versión, de forma que siempre tengas controlado qué es lo que tiene el cliente y puedas hacer modificaciones sólo para el cliente (aunque luego las incorpores al trunk). Si no haces estas ramas para el cliente, si tiene que corregir un bug en una versión de cliente algo antigua, no podrás hacerlo, ya que tu trunk habrá seguido evolucionando.

Elegir una u otra, como te digo, depende un poco de la complejidad del proyecto y forma de trabajo. Si normalmente un desarrollador hace una funcionalidad nueva y no coincide mucho con los ficheros que tienen que tocar los demás, la primera opción puede ser buena. Si una nueva funcionalidad debe desarrollarse entre varios y encima los ficheros coinciden con los de otro grupo de trabajo en otra funcionalidad, posiblemente sea mejor hacer ramas para cada funcionalidad de forma que cada grupo de trabajo lo hace en su rama y no todos tocando simultáneamente la trunk.

Se bueno.

 

ey