GESTION DE FUENTES

HAROLD KEVIN QUISPE CANAZA

GESTIÓN DE FUENTES

• A todo proyecto de desarrollo de programas le conviene tener archivada su

historia, por ejemplo, porque alguna modificación puede producir un error
oculto que se descubra tardíamente y haya que recuperar el original, al
menos para analizar el problema. Si el proyecto lo desarrollan varias
personas, es necesario también registrar al autor de cada cambio, con las
razones del mismo explicadas.
CVS

• CVS (Concurrent Version Sytem) es un sistema de gestión de fuentes optimista

diseñado a finales de los 80, que es usado por abrumadora mayoría en los
proyectos libres [cvshome][fogel:cvs][ceder:cvs]. Utiliza un repositorio central
al que se accede según un sistema cliente/servidor. El administrador del sitio
decide quienes tienen acceso al repositorio o a qué partes del repositorio,
aunque normalmente, una vez que un desarrollador ha sido admitido en el
círculo de confianza, tiene acceso a todos los ficheros. Además puede
permitirse un acceso anónimo, sólo en lectura a todo el mundo.
 OTROS SISTEMAS DE GESTIÓN DE FUENTES
• CVS, a pesar de ser el sistema de control de versiones más ampliamente usado, tiene notables inconvenientes:}
1. CVS no soporta renombrados o cambios de directorio de ficheros, ni tampoco metadatos (propietarios,
permisos, etc.) ni enlaces simbólicos.
2. Al ser una evolución de un sistema de control de versiones de ficheros individuales, no soporta naturalmente el
control de versiones de grupos completos.
3. No soporta conjuntos de cambios coherentes. En efecto, para añadir una característica o corregir un error,
puede ser preciso cambiar varios ficheros. Estos cambios deberían ser atómicos.
4. En CVS es bastante complicado el uso de ramas y mezclas. En efecto, si creamos una rama experimental de
un proyecto, y deseamos incluir las correcciones hechas a la rama estable, es preciso conocer en detalle que
correcciones se han hecho ya, para no hacerlas varias veces.
5. CVS depende de un servidor centralizado y, aunque puede hacerse trabajo estando desconectado,
necesitamos conexión con el mismo para generar versiones, compararlas y mezclarlas.
6. CVS no genera, sin la ayuda de herramientas aparte, el fichero changelog, que muestra la historia global de
cambios de un proyecto.
7. CVS no soporta bien proyectos con un número muy grande de ficheros, como es el caso del núcleo de Linux.
DOCUMENTACIÓN

• En el mundo del software libre, apenas se usan procesadores de texto

WYSIWYG y otras herramientas ofimáticas que tanto éxito tienen en otros
entornos, a pesar de haber ya herramientas libres, como OpenOffice. Ello es
debido a varios factores importantes:
1. Es conveniente mantener la documentación bajo control de fuentes, y los sistemas
de control de fuentes, como CVS, aunque admiten formatos binarios, prefieren
formatos textuales transparentes, editables con un editor de texto normal y
procesables con herramientas desarrolladas para programas, que nos permitan
ver fácilmente las diferencias entre versiones, generar y aplicar parches basados
en esas diferencias, y realizar operaciones de mezcla.
2. Ciertas licencias de documentación libre, especialmente la GFDL (“Licencia de
documentación libre de GNU”), exigen formatos transparentes, sobre todo por
facilitar el trabajo a los que realicen documentos derivados.
3. Las herramientas WYSIWYG (what you see is what you get) generalmente no
contienen más información que la estricta de visualización, haciendo muy difícil, si
no imposible, el procesamiento automático, como identificar autores o título, y la
conversión a otros formatos. Incluso aunque permitan conversión de formatos, ésta
suele hacerse de forma interactiva, siendo muchas veces imposible automatizarla
(con make, por ejemplo).
DOCBOOK

• El problema radica en que no existe separación entre contenido y

presentación, ni en las aplicaciones de TeX ni en las de nroff, ya que la
abstracción se construye por capas. Esta separación la tienen las aplicaciones
de SGML[sgml] y XML[xml], donde la presentación se especifica con hojas de
estilo completamente separadas. Muy pronto empezaron a utilizarse
aplicaciones muy sencillas de SGML, como linuxdoc y debiandoc, pero debido
a su escasa capacidad expresiva, se optó por ir a DocBook[walsh:docbook].
 WIKIS

• Mucha gente encuentra demasiado complicado escribir documentación con lenguajes tan
complejos como DocBook y mecanismos de colaboración como CVS. Por ello se ha hecho
muy popular un nuevo mecanismo de colaboración para la elaboración de documentos
en línea vía web llamado Wiki, inventado por Ward Cunningham[ward:wiki], puesto por
primera vez en servicio en 1995, y hoy ampliamente utilizado en muy diversas variantes
para elaborar documentos muy dinámicos, no destinados a ser impresos, y muchas veces
con una vida corta (por ejemplo, organización de una conferencia).
 GESTIÓN DE ERRORES Y OTROS TEMAS

• Uno de los puntos fuertes del modelo de desarrollo libre es que la comunidad
contribuya con informes de errores, y que ella sienta que sus informes o soluciones son
tenidos en cuenta. Por ello es necesario un mecanismo sencillo de informar de errores, de
modo que los desarrolladores reciban información suficiente, de forma sistemática, y con
todos los detalles necesarios, ya sea aportados por el colaborador, como la explicación
de lo que pasa, nivel de importancia y posible solución, ya por algún mecanismo
automático que determine, por ejemplo, la versión del programa y del entorno en que
funciona