Barrapunto

"¿Trabajas solo? Eso del valor semántico queda muy chulo, pero si trabajas con alguien más en ese repositorio a la gente no le va a hacer gracia que el código deje de compilar cada vez que tú haces commit."

¿No entiendes o es que no escuchas? Si yo meto aunque sea mierda pura en la versión 237 ¿la versión 236 deja de funcionar "mágicamente"? ¿A que no? La diferencia entre la versión 236 y la 237 *tiene* que ser semántica y, desde luego, no tiene nada que ver con que compile o no. Lo lógico es compilar con versiones que compilen (y para eso se han "inventado" las ramas de integración o los tags flotantes) y mantener la historia de todas las versiones relevantes, que es para lo que está el sistema de control de versiones, si no, se llamaría "control de versiones compilables" pero no, de compilables no dice nada.

"Por no hablar de que ramificar y luego hace merge no es precisamente indoloro en svn."

¿Estamos hablando de sistemas de control de versiones distribuidos frente a sistemas de control de versiones centralizados o de SVN frente a váyase-usted-a-saber-qué? Mezclar ramas *siempre* es doloroso y cuanto más tardes más: se llama deriva y es un problema independiente del sistema de control de versiones que uses o de su paradigma centralizado o distribuído.

"Por lo menos ten la decencia de poner cuatro líneas explicando los errores de base que tengo"

Te lo he dicho ya en el primer mensaje pero, en fin, vamos a repetirlo, esta vez para duros de mollera: nunca, nunca, nunca compiles contra el HEAD de nada; el HEAD no tiene ninguna razón para compilar o ser funcionalmente válido: el control de versiones sirve para seguir el histórico de cambios: si es interesante documentar un cambio, hay que integrarlo en el sistema de control de versiones, independientemente de que compile o sea funcionalmente válido. Para compilar marca versiones como compilables y utiliza esas. Para marcar dichas versiones utiliza una rama de integración o un "tag móvil". En grupos de trabajo heterogéneos, modulariza el código: cada grupo de trabajo (bases de datos, capa de presentación, bloque funcional tal o cual...) publica código en versiones concretas (cada vez que se alcanza un hito funcional -estas versiones sí compilan y no sólo es que compilen: hacen "cosas interesantes"-) y el resto del equipo, de nuevo mediante versiones de integración o tags flotantes NUNCA actualizan a HEAD sino a esas marcas. Igual que el usuario final nunca debe utilizar HEAD del CVS de un proyecto libre, sino aquello que publica el grupo de desarrollo como "estable", los distintos grupos de desarrollo de un producto son también usuarios (aunque internos) del código de los demás y exactamente por la misma razón que el usuario final tampoco deben usar el HEAD de los demás grupos, sino lo que ellos publiquen (aunque internamente) como utilizable. ¿Y en el caso de paradigmas XP donde todo el mundo es "propietario" de todo el código? Pues más de lo mismo, aunque entonces el grupo ya depende más de las funcionalidades concretas de la herramiente de SCM elegida para apoyar su modelo estratégico concreto: por ejemplo y para el caso de SVN es posible (y adecuado) mantener una sandbox "mixta" (al desarrollador no le cuesta nada puesto que es el administrador del repositorio el que la crea y, salvo cambios importantes en el lay-out del código luego ya no hay que tocarla) y más de lo mismo: al desarrollador sólo le llegan las versiones "bendecidas" salvo que, por necesidades de desarrollo -de su propio desarrollo-, le interesen versiones más modernas. Comparativamente, lo mismo que, por ejemplo, con debian: normalmente el usuario utiliza "Stable" salvo que le interese algún "pinning" de algún paquete concreto; los desarrolladores normalmente utilizan "Unstable" (que es en todo el