Manejo de Subversion - Cambios en linea base

[andresenlared]

Saludos a todos.

Tengo una pregunta respecto a la gestion de la configuracion, Tengo proyectos en delphi controlados por SVN, Las aplicaciones son diseñadas conforme dice la normatividad de salud en Colombia, Se diria entonces que la implementacion de la norma es la funcionalidad base y que todos los clientes la deben tener igual. pero los clientes suelen pedir desarrollos a la medida que afectan en algo la funcionalidad base.

Mi pregunta esta encaminada a determinar cual seria el control a realizar por subversion. Por ejemplo.

1. Crear un branch por cada cliente y llevar los desarrollos separados. Analizando este punto en el momento en que cambie la normatividad en salud, que de por cierto es muy cambiante, se tendria que ir a modificar cada branch con lo que se requiera.
2. Realizar una parametrizacion por cliente en la misma aplicacion y llevar solo el trunk, haciendo merge por cada desarrollo a la medida realizado. En este punto puede ser que el mantenimiento nos pueda generar no conformidades en otras funcionalidades, por lo parametrizado que esta la aplicacion.

Con lo anterior va la pregunta de este hilo, cual es la mejor forma de llevar el control de los fuentes con estas caracteristicas de negocio,

Muchas gracias.

[mamcx]

Eso depende de la profundidad y divergencia de los cambios. Una alternativa es manejar las variaciones por medio de un sistema de plugins.

El problema es que tu concepto de branching esta limitado por los problemas de SVN. Por ejemplo, es muy normal que al hacer cambio en un branch no solo aplique para tu cliente, sino tambien para toda la aplicacion. Si manualmente tienes que administrar y copiar/pegar los cambios entre los branchs, no esta sirviendote de mucho el usar un SCM.

Debes combinar, en mi opinion, un esquema que te permita aislar el codigo volatil del estable. Esto se logra tanto nivel de la arquitectura del codigo como del soporte de la herramienta de SCM.

P.D> Subversion al igual que todos los SCM centralizados tiene un soporte mediocre al concepto de branching y peor de merge.

“The trouble with distributed version control is that it makes it too easy to branch,” I said, “and branching always causes problems.” Turns out this was wrong, too. I was on a streak.

Branching causes problems in Subversion because Subversion doesn’t store enough information to make merging work. In Mercurial, merging is painless and easy, and so branching is commonplace and harmless.

En ese aspecto, absolutamente te recomiendo que te muevas a mercurial o git. En estos, hacer branching y merge es algo tan natural y casi sin complicaciones en su proceso.

El problema con SVN es mas acentuado mientras mas gentes este tocando codigo y mientras mas tiempo pase entre el branch & merge, o mas radical los cambios (como mover archivos, borrar, y cambiar decenas). Con mercurial (el que uso) eso no es problema. De hecho, cada vez que se modifcan el arbol luego de un commit es un branch, y cada commit es un merge. Asi de natural es el proceso de esto en los SCM distribuidos.

Esto es lo que hago.

Tengo una rama que es la estable (la por defecto). Hago un branch para la linea de desarrollo donde hago los cambios de forma regular, que luego aplico a la estable. Luego tengo N ramas por cada cambio radical, que representa una gran divergencia (por ejemplo, mientras actualizo del iPhone al iPad) pero aislado de la linea de desarrollo (que representa los cambios del dia a dia). Estos al final se integran a la linea de desarrollo, y esta eventualmente a la estable. Cuando un cambio que aplico a una rama la necesito en estable, puedo aplicar SOLO ESOS CAMBIOS y casi sin problemas (osea, no mas que un hora de ajustes) los tengo en la estable sin necesidad de traer toda la rama que esta aun incompleta.

De nuevo, reitero que absolutamente te deberias de mover a mercurial o git si vas a hacer branching de forma significativa. Mi experiencia con SVN en todos los casos que intente de hacer merge fue traumatica, y es por eso que en SVN es algo "raro" usar branch. Por el contrario, en mercurial y git es algo totalmente natural.

Por eso, el soporte de tu SCM terminaria forzandote a seguir un camino u otro.


P.D Git es mas popular estos dias, pero recomiendo mucho mas mercurial. Es mas simple, tiene mejor soporte en windows (como se refleja en esta pregunta que hice)

Puedes ver el tutorial:

http://hginit.com/

O usar git. Igual con ambas no hay pierde.

[andresenlared]

Muchisimas gracias por tu ayuda. Ya lei algo de Mercurial, y me parece excelente, definitivamente los casos que trata en el documento ya me han pasado sobre todo al hacer merge.

Definitivamente el proceso es mucho mas facil, ahora nos resta definir en cuanto a la arquitectura como seria la mejor forma de desarrolloar ya que contamos con delphi, java y php.

Saludos.