por
pobrecito hablador
el Domingo, 10 Junio de 2007, 15:01h
(#920835)
"Comparar CVS (tedioso) o Subversion (aceptable) con cualquier SCM distribuido es hasta gracioso."
No más que tratar de comparar cualquier SCM distribuído con otro centralizado. Parten de conceptos distintos y son mejores en situaciones también distintas.
"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.
"En cambio, en proyectos donde 2, 3 o más personas escriben mucho código y modifican simultaneamente los mismos ficheros, git (el que más he usado) es MUCHO más cómodo que Subversion. "
La impresión que da tu forma de hablar y lo que dices es que ni conoces CVS, ni conoces SVN... ni tan siquiera conoces GIT.
"Además de que por su naturaliza distribuida no es necesario dar acceso de escritura al repo central para que la gente pueda hacer pequeñas contribuciones. "
Claro, y dichas contribuciones llegan a ser conocidas por el grueso de los desarrolladores del proyecto por arte de birlibirloque ¿verdad?
Los sistemas distribuídos tienen sus ventajas cuando la ingeniería que rodea al proyecto es, qué casualidad, distribuída (como es el caso del kernel de Linux). 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 (¿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?).
Aún así, es cierto que hay cosas que los sistemas centralizados pueden aprender de los distribuídos; la más notable, la posibilidad de usar transacciones "cacheadas" de forma que un desarrollador pueda realizar "commits" locales cuando está desconectado del repositorio central. Otra cosa son las pecualiaridades o limitaciones concretas de herramientas concretas (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).
Si no conoces en profundidad (y digo en profundidad: arquitectura, objetivos y "filosofía", no cuatro ordenes para utilizar la herramienta como usuario en cuatro casos sencillos) al menos una herramienta distribuída (puede ser GIT, o monotone o la que sea), CVS o Subversion, Clearcase y Perforce, por favor abstente de juicios de valor, porque es bastante claro que no tienes mucha idea de lo que estás hablando.
Re:Distribuido y centralizado
(Puntos:3, Interesante)No más que tratar de comparar cualquier SCM distribuído con otro centralizado. Parten de conceptos distintos y son mejores en situaciones también distintas.
"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.
"En cambio, en proyectos donde 2, 3 o más personas escriben mucho código y modifican simultaneamente los mismos ficheros, git (el que más he usado) es MUCHO más cómodo que Subversion. "
La impresión que da tu forma de hablar y lo que dices es que ni conoces CVS, ni conoces SVN... ni tan siquiera conoces GIT.
"Además de que por su naturaliza distribuida no es necesario dar acceso de escritura al repo central para que la gente pueda hacer pequeñas contribuciones. "
Claro, y dichas contribuciones llegan a ser conocidas por el grueso de los desarrolladores del proyecto por arte de birlibirloque ¿verdad?
Los sistemas distribuídos tienen sus ventajas cuando la ingeniería que rodea al proyecto es, qué casualidad, distribuída (como es el caso del kernel de Linux). 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 (¿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?).
Aún así, es cierto que hay cosas que los sistemas centralizados pueden aprender de los distribuídos; la más notable, la posibilidad de usar transacciones "cacheadas" de forma que un desarrollador pueda realizar "commits" locales cuando está desconectado del repositorio central. Otra cosa son las pecualiaridades o limitaciones concretas de herramientas concretas (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).
Si no conoces en profundidad (y digo en profundidad: arquitectura, objetivos y "filosofía", no cuatro ordenes para utilizar la herramienta como usuario en cuatro casos sencillos) al menos una herramienta distribuída (puede ser GIT, o monotone o la que sea), CVS o Subversion, Clearcase y Perforce, por favor abstente de juicios de valor, porque es bastante claro que no tienes mucha idea de lo que estás hablando.