Versiones Bajo Control

Cuando se está escribiendo un programa o un documento muy largo (como un informe, o una memoria o una tesis), uno quisiera hacer una marca en el proyecto al llegar a un punto estable; esto es, guardar una versión estable del trabajo. La idea de guardar versiones es que si los nuevos cambios quedan mal, la marca nos servirá para volver al punto estable y recomenzar desde ahí. Si las cosas salen bien y se alcanza una nueva estabilidad, se pone otra marca.
Una forma de simular este proceso es haciendo una copia de todo el proyecto y respaldarlo. Para la siguiente marca se hace simplemente una nueva copia. Y así, a medida que el proyecto va creciendo, nos vamos llenando de copias y copias, y más copias, y el asunto se vuelve imposible de manejar eficientemente.
El problema es aún más difícil si trabajamos con más personas en el mismo proyecto. ¿Cómo mezclar el trabajo de todos de forma que quede consistente? La solución es utilizar un sistema de control de versiones >>
El sistema funciona de la siguiente forma. Se crea un repositorio central al cual todos los involucrados en el proyecto tiene acceso. El repositorio es administrado por un programa que decide como mezclar los cambios hechos por los programadores. Como CVS es el padre de los controladores de versiones, nos referiremos a él en este artículo introductorio.
Cada programador (o escritor, si estamos hablando de documentos) tiene una copia local del proyecto sobre la cual trabaja. Las copias locales se crean con CVS haciendo un checkout. Una vez que los cambios introducidos al proyecto de manera local funcionan, éstos se envían al repositorio. Al envío le llamamos un commit. Así, el repositorio mantiene la versión más actualizada del proyecto. Cada programador realiza una actualización de su propia copia local pidiéndosela regularmente al repositorio, lo que se llama update.
CVS además permite hacer marcas del proyecto, lo que llamamos tags. Así, más adelante uno puede decir: "dame el proyecto tal cual como estaba cuando lo marcamos con el tag foo". Los tags sirven también para definir versiones del proyecto.
Además, tal como se ve en la imagen, cuando alguien quiere hacer algo más experimental, se crea una rama del proyecto. Si el experimento funciona, se mezclan los cambios al proyecto principal. La imagen es de la herramienta tkcvs que permite usar CVS de una manera muy gráfica.
Los sistemas de control de versiones son super útiles incluso si uno trabaja solo, y como ya mencioné, no sólo es útil para programadores, sino también para mantener los documentos bien administrados.
- Artículos de Tchorix
- 5054 lecturas
-
- RSS comentarios
Lo más reciente en Manzana Mecánica
-
— 24 Nov 2008.484 lecturas.
-
— 25 Nov 2008.374 lecturas.
-
— 28 Nov 2008.231 lecturas.
-
— 27 Nov 2008.176 lecturas.
-
— 26 Nov 2008.158 lecturas.
-
— 1 Dic 2008.93 lecturas.
-
— 2 Dic 2008.34 lecturas.




Comentarios
construccion de sistema controlador de versiones
estoy interesado en crear un sistema controlador de versiones, tengo conceptos basicos de como realizarlo pero si alguien me puede colaborar le agradeceria mucho gracias.
Interesante!!
La verdad que recien me acabo de enterar de este tipo de programas, aun estoy estudiando en la universidad pero ya e tenido la oportunidad de trabjar en equipos, especialmente para un proyeto de curso y es verdaderamente todo un caos juntar los avances que tengan tus compañeros de trabajo. Voy a comenzar a usar este programa y me parece muy interesante
Gabriel
EPIS - UNSA
ola a todos, por favor toy
ola a todos, por favor toy haciendo un trabajo de clase sobre CVS y mi pregunta es si alguien me puede expicar las deficiencias k tiene con respecto a subversion, gracias
git
Por aquí mencionan a CVS y Subversion, ambos pertencientes al SCM "centralizado" pero también hago notar el otro modelo "distribuido", que tiene sustanciales ventajas en algunos casos. Uno de sus exponentes de creciente uso: git.
y darcs
Hola Knight sin nombre. Gracias por mencionar git. Pronto vamos a dar las ventajas de subversion sobre CVS, y más adelante hablaremos de darcs, que al igual que git, sigue una filosofía decentralizada que me gusta mucho. Como no conzco git, será interesante contar con tu comentarios más adelante.
saludos
Tchorix
—Tchorix
Yo uso
CVS todos los dias.. y algo que detesto, pero comprendo que es porque el software es viejo, que cada ves que cambio el nombre de un archivo, pierdo toda la historia de cambios a ese archivo....
Subversion es un poco mas inteligente en ese sentido?
Subversion...
...le patea el trasero a CVS.
Seriously, svn conserva la historia, conserva historia incluso ante refactorings animales (cambio de nombre "y dirección").
En cuanto uno se acostumbra al modelo de numeración de versiones (en vez de tener 1 número de version por archivo, los números de version son de todo el repositorio...) se hace demasiado agradable :)
http://subversion.tigris.org/
de más
Que bueno que mencionas Subversion, porque más adelante mencionaremos cuales son las ventajas sobre CVS. De hecho, no entiendo por qué sourceforge todavía esta "considerando" dar soporte para subversion, en vez de adoptarlo de una vez por todas.
saludos
—Tchorix
Sourceforge SI soporta Subversion
En la documentación de SourceForge si aparece como soportado.
http://sourceforge.net/docman/display_doc.php?docid=31070&group_id=1
Buen artículo introductorio. Recuerdo épocas remotas cerca del 2000, en uno de los primeros proyectos J2EE que hicimos en un trabajo. Era un CAOS porque no teníamos control de versiones, éramos 8 programadores pasandonos código por mail, carpetas compartidas. Bloqueabamos archivos llamándonos por teléfono. Horrible.
Al año siguiente ya había CVS en la pega y ahora no entiendo como pudimos haber entregado algún proyecto funcionando sin CVS.
Ahora uso Subversion, y claro que le da 1000 patadas a CVS, pero mejor que lo dejamos para el siguiente artículo de Tchorix. :-D
Saludos,
—Denis
California roll connoisseur