7 comentarios para “¿Qué guardo en el SVN?”

1. Alfredo dice:

   14 jul, 2006 @ 16:27

   “Para mi las fuentes es todo aquello que se utiliza para generar la aplicación.”
   
   En eso estoy de acuerdo, en lo que no estoy de acuerdo es que el control de versiones sólo tenga que tener “las fuentes”. Algunos ejemplos:
   
   - Las clases de Test: no son necesarias para generar la aplicación pero su sitio creo que es el CVS.
   - Otro tipo de archivos para pruebas: scripts para pruebas funcionales automatizadas, scripts para pruebas de estress, incluso documentos que describan que pruebas manuales hay que hacer al producto. Todo esto en mi opinión también debe ir al CVS.
   - La documentación del proyecto, sobre todo si se trata de proyectos a largo plazo tenerla en el CVS es la mejor forma de tener la documnetación sncronizada con la versión de la aplicación. (no me refiero a los javadocs, sino a la documentación generada manualmente).
   
   En general yo guardo en el CVS cualquier cosa relativa al proyecto que no puede generarse automaticamente o partir de otros ficheros.
   
   Sobre lo de guardar los ficheros de IDE’s, no lo veas como una imposición sino como una opción, en mi caso es obligatorio subir un ANT que permita compilar el proyecto, pero si además subes los archivos de un IDE concreto pues permites que alguien pueda tener el proyecto funcionando en segundos. Quien quiera usar los archivos del IDE que los use y el que no pues que se lo monte como le plazca, siempre y cuando mantenga el ANT compilando.
   
   Que un programador tenga libertad es lo mejor si esta capacitado para aprovecharla, pero seamos realistas, muchos no saben aprovecharla, en mi caso si no les pongo unos ficheritos para que puedan abrir el proyecto en eclipse o neetbeans me toca ir detras de ellos montandoles los proyectos cada vez…
2. azuluaga dice:

   14 jul, 2006 @ 16:59

   Estoy de acuerdo con ambos en guardar el código fuente y las pruebas de la aplicación.
   Tampoco me gusta lo de mantener los archivos de configuración del proyecto, prefiero hacerlo yo mismo como me guste y me parece necesario que todo mundo sepa como es que se instala y se configura el proyecto en el IDE que guste trabajar. Lo que comenta Alfredo de montarle el proyecto a sus analistas, es un problema de él al no explicarles o no dejarlos que se las vean con sus programas.
   
   La documentación me parece importante mantenerla actualizada y el control de versiones (SVN o CVS) es una opción aceptable, pero es ideal que con esos documentos se pueda hacer lo mismo que con el código fuente: comparar físicamente los datos a ver que ha cambiado entre versiones (claro, que muestre cosas perceptibles para un humano) y ese es el problema que habría con documentos de Microsoft Office u OpenOffice que viene a ser contenido binario (perdón por la inexactitud).
   
   Entiendo que ya hay sistemas que manejan documentos de Microsoft Word como lo hace un sistema de control de versiones con un archivo plano (JLibrary?) ahí si me parece útil el asunto con la documentación, de resto, sería solo para conservar la historia del proyecto y a la larga serviría, pero serviría muy poco.
3. Alfredo dice:

   14 jul, 2006 @ 18:50

   “Lo que comenta Alfredo de montarle el proyecto a sus analistas, es un problema de él al no explicarles o no dejarlos que se las vean con sus programas.”
   
   Se lo puedo explicar, puedo hacer un documento que comente paso a paso como montarlo (que lo he hecho), ¿pero en realidad esto de que sirve?, me explico, si el programador tiene el suficiente interes el solito ya sabra montarse su proyecto en su IDE favorito, luego estan los otros, los que no tienen ningún interes y lo único que harian seria seguir el documento al pie de la letra para montarse el proyecto en eclipse o lo que fuera. ¿Entonces porque no subirlo directamente al CVS?, así se ahorran el tiempo que perderian montando el proyecto.
   
   Tal como yo lo veo, subiendo los ficheros del IDE el que tiene interes no ve restringida su libertad porque no es obligatorio usar ese IDE, y el que no lo tiene no tiene que gastar su tiempo montando el proyecto. Si de mi dependiera no habría trabajando en nuestros proyectos ninguno de los del segundo grupo, pero esto no es decisión mia por desgracia y hay que intentar ser lo más productivo con lo que se tiene, aunque a veces esto suponga no hacer las cosas de la forma más ortodoxa…
   
   Sobre lo de los documentos estoy de acuerdo contigo en que hay sistemas mejores que permiten ver los cambios entre versiones, con SVN/CVS lo que tienes es relacionadas las versiones de tu código con las versiones de la documentación pero no puedes ver los cambios entre versiones. Con un sistema externo puedes ver los cambios entre versiones pero no tienes la documentación sincronizada con el resto del proyecto, lo ideal sería integrar las dos cosas.
4. Claudex dice:

   15 jul, 2006 @ 07:27

   Estamos de acuerdo que si se ocupa un formato para documentación basado en binarios, estamos perdidos como sistemas como svn. Ahora, si utilizamos Docbook, Latex o cualquier otro lenguaje de marcado para manejar la docu, quedaría todo integrado. Aparte, hay bastantes sistemas, como phpdocu o javadoc, que se basan en documentar, por lo menos la Api, en el mismo código.
5. azuluaga dice:

   15 jul, 2006 @ 16:39

   [Alfredo]: “Si de mi dependiera no habría trabajando en nuestros proyectos ninguno de los del segundo grupo, pero esto no es decisión mia por desgracia y hay que intentar ser lo más productivo con lo que se tiene”.
   
   Tienes toooda la razón :-), en tu caso es mucho mejor subir los ficheros de configuración. Ya lo otro es gusto propio y a mi me suele gustar configurar solito el proyecto, pero lo dicho, hay cosas que ni que. :-).
   
   ¿Alguno usa un sistema para manejar las versiones de documentos que no sean de texto? algo para ver los cambios entre versiones y en fin, todo lo que hemos comentado.
   
   ¿JLibrary lo hace?
   Saludos.
6. Al dice:

   16 jul, 2006 @ 16:56

   jejejeje. Bueno, me pasa por simple. Más bién debería haber escrito de otra forma la frase de “todo lo necesario para generar la aplicación”. Debería haber dicho para “generar, probar y entender” la aplicación. Determinada documentación debe ir en el CVS/SVN, como deben ir los test. En realidad yo tengo hasta las facturas de la empresa en el SVN, ya vés.
   
   Aunque si que soy muy agnóstico de determinados tipos de documentación previos al desarrollo, porque no suele corresponderse con la realidad, y es peor tener documentación desfasada que no tenerla.
   
   Pero vamos, archivos del IDE, clases generadas, etc, no gracias.
7. vitxo. dice:

   17 jul, 2006 @ 14:11

   Azuluaga, si buscas un SCM no sólo para texto tu amigo es Perforce. Se integra perfectamente con MS Office y además es capaz de sacar versiones de imágenes. Hace unos meses trabajé maquetando un portal y los PSDs (los fuentes de Photoshop) con el diseño de la apariencia se versionaban bajo Perforce. Es comercial, pero si no recuerdo mal, gratuito para proyectos opensource de no más de dos desarrolladores/usuarios.
   
   En cuanto al post, quizá porque yo aprendí a pegarme con CVS con Cáñamo -y Cáñamo viene de quien viene ;)- yo soy de los que no prefiere almacenar archivos característicos del IDE ni clases autogeneradas. Sólo archivos fuentes (de cualquier tipo, código fuente hasta PSDs o XCF :-) ), scripts de ANT, Rake/Makefiles y documentación (cuando la haya :-) ).
   Me gusta el hecho de poder adaptar mi entorno normal de desarrollo al proyecto y no viceversa. Hay veces que por comodidad hasta termino tirando sólo de JEdit+plugins y SmartSVN/CVS.