|
Que bien, pero estan haciendo a "medias" la cosa. Y de paso estan perdiendo varios beneficios....
Un CVS debe tener una copia de TODOS y CADA UNO de los archivos y recursos necesarios para compilar y desplegar el proyecto. Es MALA MALA idea lo que hacen porque es una manera muy facil de que se les corrompan los archivos de codigo o DCU (y luego que salgan errores intermitentes de Acces violation por un lio de la red, o lentitud, no sabran si es por causa de ustedes, la red o una libreria de terceros). Es lo mismo de malo de usar Paradox y Acces en un acceso de Red directo... Porque hacerlo si tienen un motor Sql como Firebird o Oracle? En su caso es lo mismo. Estan corriendo, por decirlo asi, "acces" por un lado y "Firebird" por el otro.
Si los archivos cambian muy poco, mayor razon aun para copiarlos localmente..... es una perdidad de recursos y un riesgo innecesario. Es como programar Cliente/Servidor: Las tablas que cambian muy poco, se cachean en el cliente para darle velocidad.
La idea es que dentro de cada root del CVS esta todos y cada uno de los archivos (codigo, formas, reportes, imagenes, Scrips de crear BD, documentacion, archivos ini de configuracion, etc...).ABSOLUTAMENTE TODO lo que forma parte del proyecto. TODO lo que se necesite.. si un archivo de Word tiene una explicacion importante, se mete tambien. No se preocupen: Los buenos CVS solo actualizan los cambios, no todos los archivos al hacerlo commit, y solo descargan los cambios tambien, a menos que sea la primera vez. Mas o menos, uno maneja estos 3 "proyectos"
- Codigo compartido.
- Archivos compartidos
- Uno por cada proyecto individual
Asi, hay minimo 2 descargas: El codigo compartido y el proyecto. Es benefico no poner todo junto porque la idea del codigo compartido es que sea eso, compartido, y el meterlo en un proyecto especifico es una gran tentacion a bastardizar el codigo...
Lo que DEMUESTRA que se estan haciendo bien las cosas, es que se debe poder en CUALQUIER momento, cualquier SEGUNDO, obtener una copia del CVS en un equipo y carpeta fresca, compilar y debe FUNCIONAR. Si no compila (la minima unidad de calidad) no es gracia, o falto un archivo (y lo meten al CVS) o estan dando COMMIT a codigo inestable (MAL hecho: Un CVS solo debe tener codigo estable, aunque no perfecto o sin bugs, pero si estable). De ahi, una vez que se logre la minima unidad de calidad si el desarrollo es grande y lo amerita (en este caso SI, hay muchos programadores) entonces se debe escalar a la segunda: Se debe poder generar ejecutables, dlls e instaladores y poder lanzar una version beta funcional (aunque no necesariamente correcta), o sea, hacer builds diarios o casi diarios, garantizando que cada build lanzado minimamente corre y abre y cierra el programa.
Es un beneficio lateral muy bueno. En mi caso, estamos haciendo un desarrollo largisimo que lleva ya 2 años. Ahora estamos en la recta final y los vendedores y testeadores, gerentes y clientes, necesitan con que "jugar". Antes de usar un CVS, me podia demorar hasta 1 mes en generar un beta. Un mes perdido para vendedores, gerentes, clientes y lo peor, testeadores. El mes de retardo era que si estaba en medio de un cambio interno, tocaba esperar a que todo se estabilizara de nuevo. Ahora, tengo la CERTEZA que puedo sacar en cualquier MINUTO una version Beta decente a quien me lo pida CUANDO lo pida y no al otro dia.... Porque puedo tranquilamente demorarme mi mes haciendo lo mio, pero en el CVS esta una copia estable, ademas hice un script con NAnt que me genera, compila, hace copia de seguridad y crea instaladores....
|