Barrapunto

¿te has parado a pensar, por ejemplo, cómo se "mapea" la célebre expresión "release soon, release often" en un entorno distribuído frente a otro centralizado?

¡Pero si te lo respondes tú mismo en el siguiente párrafo! "Submit soon, submit often".

El modelo centralizado se esta quedando desfasado, los proyectos grandes se mantienen por inercia y porque cambiar de scm es complicado (no solo es migrar el fuente, tb los scripts de construccion, tests unitarios...).

La centralizacion permite una politica de accesos/seguridad mas restrictiva pero tampoco tanta, hay copias locales por cada desarrollador pj que mas da que en vez de copia local sea un repositorio, y en un distribuido si hay un responsable de aceptar parches ya hace el filtro.

En empresas pequeñas no hace falta mucho, un svn, facil de configuracion, backup, logins a cargo de apache...

El problema es la gran empresa, 4 o mas delegaciones , programadores internos (la mayoria reciclados) y externos subcontratados a no menos de 6 consultoras. Cada una en un proyecto pero que esta todo relacionado... la red no da, los procesos de branch y merge estan limitados para no montar un galimatias...

El problema de los distribuidos es que si ya es complicado que un programador llegue sabiendo que es cvs, ponerle en linea de comandos es mision imposible. He visto abortarse una migracion cvs->svn porque "aprender a usar el plugin de eclipse era muy complicado". Trabajar en proyectos de soft libre es una maravilla en comparacion con el soft privativo. En uno tienes gente entusiasta, en otro gente que se apunto a programador como quien se apunta ser secretaria/administrativo.

Me he reido mucho con el "los sistemas centralizados ofrecen ventajas irreemplazables", en un sistema distribuido si mantienes un repositorio oficial y es el unico desde el que se realizan las construcciones (a integracion, acept, fixes, preprod y produccion) tienes un sistema con las ventajas de ambos mundos.

Con esta me he reido mas todavia XD "la bastante mala gestión de tags y branches por parte de SVN, que todavía no está a la altura de la de CVS", teniendo en cuenta que cvs no es atomico cualquier cosa ya es mejor, sin contar que permite mover y borrar ficheros y directorios sin tantos problemas. A svn le falla el merge (y lo saben)

De los distribuidos (y libres):
Lo importante es el momento (velocidad*masa) que tienen, sobretodo porque un scm debe ser fiable, no se puede perder o corromperse... es decir muy probado/usado.
Mercurial me gusto, y es el utilizado por opensolaris y Xen, lamentablemente no hay plugin de eclipse.

GIT sera el triunfador, tiene mucha gente detras y muy buena (ole a la gestion de ramas y fusiones). Sigue estando verde (mas fuera de sistemas linux) pero va a velocidad de crucero (la v1.5 es muy sencilla), tiene un emulador cvs (git-cvsserver) que le abrira las puertas a la gran empresa. En el soft libre, Xorg y mozilla ya se han pasado.

bazaar tiene a la gente de ubuntu detras pero no esta a prueba de pkts.

svk no es eficiente en red y ademas la gestion de ramas/fusiones de svn es mala

En fin, que los sistemas distribuidos estan despegando ahora y su utilizacion es bastante moderna en comparacion con cvs y svn. Solo ahora empiezan a aparecer scms de facil utilizacion y por supuesto siguen lejos del nivel que ofrece el "body shoping".

"En estos proyectos o bien casi todo el código lo lleva una sola persona y los demás hacen pequeñas contribuciones o bien las probabilidades de que dos personas trabajen en el mismo fichero son bajas. "

Ya... Debe de ser que FreeBSD (que utiliza CVS) es un proyecto de pocos ficheros en el que trabajan pocas personas. Y debe de ser que KDE (que utilizar SVN) es un proyecto de pocos ficheros en el que trabajan pocas personas.

Obviamente desconoces por completo el trabajo de mantenimiento y release engineering detrás de FreeBSD. CVS es un quebradero infernal y contínuo de cabeza. Y por algo se desarrolla usando Perforce.

Claro, y dichas contribuciones llegan a ser conocidas por el grueso de los desarrolladores del proyecto por arte de birlibirloque ¿verdad?

Supongo que conocerás las listas de correo, la bandeja de entrada de un buzón de correo electrónico y las ramas de desarrollo "fiables" (¿maintainers?) que llevan los desarrolladores. Coges de un lado, coges del otro, integras (o chillas), y ¡voila!

Pero cuando la ingeniería del proyecto es centralizada (cosa que pasa en la inmensa mayoría de los proyectos de software, con licencias libres o privativas), los sistemas centralizados ofrecen ventajas irreemplazables

¿No podrías usar términos un poco más pedantes? No tienes razón. Nada de razón. Lo único irreemplazable que ofrecen lo que llamas sistemas centralizados son desventajas gordas en la mayoría de situaciones (a veces simplemente no ofrecen desventajas, lo cual ya es todo un logro). Y podrías explicar un poquito cuál es tu pensamiento sobre esa pregunta de "release soon, release often", es toda una intriga. :o

por ejemplo, la bastante mala gestión de tags y branches por parte de SVN, que todavía no está a la altura de la de CVS

Te ha faltado añadir lo de "por suerte".

por favor abstente de juicios de valor, porque es bastante claro que no tienes mucha idea de lo que estás hablando.

Consejos vendo...

[cita]"En estos proyectos o bien casi todo el código lo lleva una sola persona y los demás hacen pequeñas contribuciones o bien las probabilidades de que dos personas trabajen en el mismo fichero son bajas. " Ya... Debe de ser que FreeBSD (que utiliza CVS) es un proyecto de pocos ficheros en el que trabajan pocas personas. Y debe de ser que KDE (que utilizar SVN) es un proyecto de pocos ficheros en el que trabajan pocas personas.[/cita]

Ya sé que hay proyectos enormes utilizando CVS. Yo solo hablo por los pequeños proyectos en los que he trabajado. A un nivel básico, git me ha resultado mucho más fácil. Cada desarrollador con su propia rama principal, e incluso con varias según el propósito. ¿Cuantos proyectos que utilicen CVS pueden decir que hacen un uso tan exaustivo de las ramas?