Jose F. Gimenez escribió:
> Rafa,
>
> yo he seguido evaluando los DVCS estos días a ratos, y la verdad, me han
> decepcionado bastante
>
> - Bazaar: Tiene muy buena pinta. Los modos de trabajo son muy claros, sin
> confusiones ni artifícios raros. Lo malo parecía ser el formato de los
> repositorios, que parece que no "terminan de poner el huevo"; con cada
> versión de bazaar añaden un nuevo formato. Pero lo peor lo vi al intentar
> hacer un "branch". No sé si lo hice mal o no supe hacerlo, pero lo que vi es
> que un "branch" consiste en copiar todo el proyecto en otro subdirectorio
> (WTF!). Vamos, que para hacer eso no necesito ningún VCS; me copio el
> proyecto en otro directorio y hago las comparaciones y los "merges" con
> WinMerge. Y no he usado SVN, pero me parece que en SVN es algo parecido
La verdad que cuando vi, como se 'hacian las ramas' en el SVN.... que
triste, aunque en linux no hay apenas penalizacion por el tema de los
enlaces simbolicos, en windows es una castaña, la prueba, bajate el
harbour, y alucina con las ramas.
Yo tiro directamente del trunk , si no, es inviable.
>
> - Git: Está bien, aunque esa forma de nombrar (numerar) las revisiones es un
> poco fastidiosa. Pero claro, es el precio a pagar por un sistema 100%
> distribuido. Sí, ya sé que permite enviar a un repositorio central, pero da
> la impresión de que todo está diseñado para trabajar completamente "peer to
> peer", donde los desarrolladores envian "parches" al director o directores
> del proyecto y estos lo añaden a sus propios repositorios si lo aprueban.
> Por otro lado, no permite tener ramas o revisiones "privadas"; cuando haces
> un "push" se envia todo al repositorio remoto. Francamente, me parece una
> carencia monumental en un DVCS.
Ummm.. no he profundizado mucho con Git, como digo y publiqué en
olivares2000, me costó hacer un repositorio central.
De todas maneras, eso que dices de las ramas, quizás pueda pasar cuando
este en modo centralizado, porque precisamente GIT se pensó para manejar
mucho el temas de las ramas/fusiones, es más, dicen las malas lenguas
que es el mejor en este punto.
Pero las ramas privadas en sistemas 'centralizados' no existen, y si
pones Git como centralizado, lógicamente las ramas tienen que subir.
Pero, lo que si puedes hacer es:
- Crear una rama en local.
- Hacer commit local.
- NO hacer push de la rama, si no del HEAD. ( esto tengo que probarlo y
te cuento )
Entonces, tienes lo que quieres, modelo centralizado, y ramas privadas.
Como sabrás, Git funciona similar al CVS para trabajar con ramas, que
tienes que hacer un checkout de la rama/head/revision que queramos para
trabajar en ella.
>
> - Mercurial: la verdad es que no lo he revisado a fondo. El simple hecho de
> que el TortoiseHG esté hecho con GTK me echa para atrás. Sí, ya sé que a
> algunos os gusta mucho, y que puede tener ciertas ventajas. Pero es que la
> forma de distribuir los controles en los diálogos tiene poco que ver con
> windows. Vamos, que el botón de aceptar lo ponen arriba, en una barra de
> botones, en vez de abajo como aparece en prácticamente *todos* los programas
> de windows.
Bueno.... para gustos los colores
>
> Y ahora lo mejor... ¿cómo debería ser un DVCS? Pues en mi opinión, lo ideal
> sería:
>
> - El modo de trabajo principal tendría que ser trabajar siempre en modo
> local (con un repositorio local) y hacer "push" cuando queramos al
> repositorio central. Pero no cualquier repositorio remoto, sino uno central
> bien definido. Si estamos trabajando sólos entonces no hace falta un DVCS, y
> tanto CVS como SVN sirven perfectamente. No obstante, si queremos usar el
> mismo VCS para todo, bastaría con no hacer nunca "push"
>
Exacto.
> - Tendría que permitir ramas y revisiones tanto "locales" como "privadas".
> Locales serían las que se mantienen en el repositorio local, pero que al
> hacer "push" se envian al central. Pero las privadas se mantienen siempre en
> local, y al hacer "push" sólo se envia el estado final, no las revisiones
> intermedias. No tiene sentido que si yo estoy desarrollando una parte algo
> complicada y hago commits locales continuos, esos commits aparezcan en el
> repositorio central, porque esos estados intermedios no son funcionales.
>
Asi es como lo hace Git, los commits son locales, el push es cuando
quieras tu publicarlo en el central, si lo has configurado como central.
Lo guapo también es enviar ramas de un desarrollador a otro, etc..
> - El sistema de numeración de revisiones de SVN o Bazaar sería el ideal.
>
Ah! Pues a mi me gusta mucho más el sistema del CVS.
Después, Tags a todo lo que quiera controlar en el tiempo, que es más o
menos lo que hace SVN.
> Quizás haya un DVCS que cumpla más o menos con esto, pero o no lo he
> encontrado o no lo he sabido ver. Y la verdad, si no fuera porque tengo
> mucho trabajo y tengo que dedicar mis esfuerzos a otras cosas, me pondría a
> hacer uno; por lo que he podido ver, no es tan complicado. Lo que es más
> laborioso es la parte de interface al estilo tortoise. Pero el núcleo...
> bastaría con coger un buen algoritmo delta (basta con goglear un poco) y
> usar SQLite como repositorio. Yo estoy seguro de que se podría hacer muy
> rápidamente.
>
Bueno, fíjate en el Linus, creo Git porque no había lo que quería, ya
sabes, te lías y te creas uno propio
Saludos
Rafa Carmona
