¡Hola!
El Mon, Dec 28, 2009 at 06:18:32AM -0800, Renato Ulloa escribio:
Estimados listeros,
Soy Ingeniero de Proyectos y junto a otros colegas trabajamos en varios
proyectos
simultaneos y la documentación la manejamos cada uno a su antojo, donde las
distintas
versiones de archivos (en general xls, xlsx, doc, docx, pdf, de Visio,
CAD,...etc)
las nombramos como 'Archivo1_2009mmdd_nn', pero a lo largo del tiempo se llegan
por
ejemplo a la versión N°15 ya sea por cambios/actualizaciones o por que hay
versiones
para el cliente, para un contratista, para el jefe, etc. Todo esto en forma
local
(nuestros PC) y no compartido en un servidor central.
Pensando en:
- Versiones
- Respaldos
- Acceso de terceros (autorizados)
- Capacidad de clonar todo a otro equipo y tener todas las versiones.
Había pensado en algún sistema de Control de Versiones (años atrás usé CVS y
luego
Subversion en otro ámbito), pero para este caso creo que un Sistema Distribuido
como Mercurial o Git se acomoda más al requerimiento; permitiría contar siempre
con
copias locales y usar un repositorio central (Ubuntu 9.10 Server) para mantener
el
respaldo, permitiría acceso a otros usuarios y poder fácilemnte replicar todo el
proyecto por ej. a un portatil y usarlo desde allí.
Dudas:
1. ¿Es la mejor alternativa usar un Sistema de Control de Versiones para
archivos binarios como Mercurial o Git?
Un sistema de control de versiones como los anteriores es apropiado para menejar
versiones de archivos binarios, pero sobre todo, para manejar *conjuntos* de
archivos, sean estos de texto o binarios.
En lo personal, no te recomendaría un sistema de control de versiones para el
control de documentos, ya que al ser los documentos archivos cerrados desde el
punto de vista del control de versiones, es complicado hacer mezclas de cambios
múltiples entre versiones.
Yo te recomendaría mucho más utilizar un Wiki para realizar los documentos, aquí
utilizamos Trac y es bastante bueno. Trac incluye:
* Sistema de tickets para organizar las tareas y sus dependencias.
* Soporte para hitos en los proyectos, con fechas y tareas a cumplir.
* Un wiki que soporta adjuntar documentos, por lo que se pueden hacer
los informes en un wiki adjuntando archivos adicionales, como fotos,
planos, etc.
Lo que tratamos de realizar aquí es escribir los documentos en el Wiki separando
las secciones en distintas páginas, luego al estar finalizado el documento, se
genera un doc. de OpenOffice pegando las secciones desde el wiki. Este documento
se adjunta a la página del wiki como referencia, tanto en formato openoffice
como
en formato pdf.
La gracia de un wiki es que tienes toda la historia de las ediciones al
documento,
junto con la capacidad de mezclar cambios de distintas ediciones. Esto es muy
poderoso a la hora de ver cómo el documento se genera.
Existen otros wikis además del incluido en Trac que tienen cosas diferentes,
aquí
también utilizamos MediaWiki, que es bastante poderoso para generar
documentación,
por ejemplo manuales, pero no es tan bueno para informes de trabajo.
Espero te sirva,
Daniel.
Aca usamos Trac un buen tiempo, y la wiki nos ayudo bastante para
documentar,
el problema que tuvimos en Trac es que este no maneja (directamente)
distintos proyectos,
sino que todos los tickets, docs, wikis estan referenciados a un solo
proyecto. Haciendo unos hacks
puedes lograr manejar varios projectos.
Hace poco nos movimos a Redmine, de similares caracteristicas, pero se
ve un producto mejor logrado.
Soporta diversos projectos, asignando personas a estos, manejos de
archivos, documentos, wiki,
conexion muy simple a diversos repositorios, code browsing con soporte a
code reviews (muy recomendable).
En resumen la wiki en los dos es muy similar, pero creo que es mejor
tener todo separado por proyectos.
--
Richard Rossel
Software Engineer at Airsage Inc.
Valparaiso - Chile
