<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.3" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: ¿Qué guardo en el SVN?</title>
	<link>http://weblog.linkingpaths.com/2006/07/14/%c2%bfque-guardo-en-el-svn/</link>
	<description>Un blog de Linking Paths sobre pequeñas empresas y grandes productos.</description>
	<pubDate>Tue, 06 Jan 2009 23:46:56 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.3</generator>

	<item>
		<title>By: vitxo.</title>
		<link>http://weblog.linkingpaths.com/2006/07/14/%c2%bfque-guardo-en-el-svn/#comment-201</link>
		<dc:creator>vitxo.</dc:creator>
		<pubDate>Mon, 17 Jul 2006 14:11:55 +0000</pubDate>
		<guid>http://weblog.linkingpaths.com/2006/07/14/%c2%bfque-guardo-en-el-svn/#comment-201</guid>
		<description>&lt;p&gt;Azuluaga, si buscas un SCM no s&#243;lo para texto tu amigo es &lt;a href="http://www.perforce.com"&gt;Perforce&lt;/a&gt;. Se integra perfectamente con MS Office y adem&#225;s es capaz de sacar versiones de im&#225;genes. Hace unos meses trabaj&#233; maquetando un portal y los PSDs (los fuentes de Photoshop) con el dise&#241;o de la apariencia &lt;a href="http://www.perforce.com/perforce/products/plugins-p4gt.html"&gt;se versionaban&lt;/a&gt; bajo Perforce. Es comercial, pero si no recuerdo mal, gratuito para proyectos opensource de no m&#225;s de dos desarrolladores/usuarios.&lt;br /&gt;
&lt;br /&gt;
En cuanto al post, quiz&#225; porque yo aprend&#237; a pegarme con CVS con C&#225;&#241;amo -y C&#225;&#241;amo viene de quien viene ;)- yo soy de los que no prefiere almacenar archivos caracter&#237;sticos del IDE ni clases autogeneradas. S&#243;lo archivos fuentes (de cualquier tipo, c&#243;digo fuente hasta PSDs o XCF :-) ), scripts de ANT, Rake/Makefiles y documentaci&#243;n (cuando la haya :-) ).&lt;br /&gt;
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&#243;lo de JEdit+plugins y SmartSVN/CVS.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Azuluaga, si buscas un SCM no s&oacute;lo para texto tu amigo es <a href="http://www.perforce.com">Perforce</a>. Se integra perfectamente con MS Office y adem&aacute;s es capaz de sacar versiones de im&aacute;genes. Hace unos meses trabaj&eacute; maquetando un portal y los PSDs (los fuentes de Photoshop) con el dise&ntilde;o de la apariencia <a href="http://www.perforce.com/perforce/products/plugins-p4gt.html">se versionaban</a> bajo Perforce. Es comercial, pero si no recuerdo mal, gratuito para proyectos opensource de no m&aacute;s de dos desarrolladores/usuarios.</p>
<p>En cuanto al post, quiz&aacute; porque yo aprend&iacute; a pegarme con CVS con C&aacute;&ntilde;amo -y C&aacute;&ntilde;amo viene de quien viene ;)- yo soy de los que no prefiere almacenar archivos caracter&iacute;sticos del IDE ni clases autogeneradas. S&oacute;lo archivos fuentes (de cualquier tipo, c&oacute;digo fuente hasta PSDs o XCF :-) ), scripts de ANT, Rake/Makefiles y documentaci&oacute;n (cuando la haya :-) ).<br />
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&oacute;lo de JEdit+plugins y SmartSVN/CVS.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Al</title>
		<link>http://weblog.linkingpaths.com/2006/07/14/%c2%bfque-guardo-en-el-svn/#comment-202</link>
		<dc:creator>Al</dc:creator>
		<pubDate>Sun, 16 Jul 2006 16:56:18 +0000</pubDate>
		<guid>http://weblog.linkingpaths.com/2006/07/14/%c2%bfque-guardo-en-el-svn/#comment-202</guid>
		<description>&lt;p&gt;jejejeje. Bueno, me pasa por simple. M&#225;s bi&#233;n deber&#237;a haber escrito de otra forma la frase de "todo lo necesario para generar la aplicaci&#243;n". Deber&#237;a haber dicho para "generar, probar y entender" la aplicaci&#243;n. Determinada documentaci&#243;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&#233;s. &lt;br /&gt;
&lt;br /&gt;
Aunque si que soy muy agn&#243;stico de determinados tipos de documentaci&#243;n previos al desarrollo, porque no suele corresponderse con la realidad, y es peor tener documentaci&#243;n desfasada que no tenerla. &lt;br /&gt;
&lt;br /&gt;
Pero vamos, archivos del IDE, clases generadas, etc, no gracias.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>jejejeje. Bueno, me pasa por simple. M&aacute;s bi&eacute;n deber&iacute;a haber escrito de otra forma la frase de &#8220;todo lo necesario para generar la aplicaci&oacute;n&#8221;. Deber&iacute;a haber dicho para &#8220;generar, probar y entender&#8221; la aplicaci&oacute;n. Determinada documentaci&oacute;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&eacute;s. </p>
<p>Aunque si que soy muy agn&oacute;stico de determinados tipos de documentaci&oacute;n previos al desarrollo, porque no suele corresponderse con la realidad, y es peor tener documentaci&oacute;n desfasada que no tenerla. </p>
<p>Pero vamos, archivos del IDE, clases generadas, etc, no gracias.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: azuluaga</title>
		<link>http://weblog.linkingpaths.com/2006/07/14/%c2%bfque-guardo-en-el-svn/#comment-203</link>
		<dc:creator>azuluaga</dc:creator>
		<pubDate>Sat, 15 Jul 2006 16:39:22 +0000</pubDate>
		<guid>http://weblog.linkingpaths.com/2006/07/14/%c2%bfque-guardo-en-el-svn/#comment-203</guid>
		<description>&lt;p&gt;[Alfredo]: "Si de mi dependiera no habr&#237;a trabajando en nuestros proyectos ninguno de los del segundo grupo, pero esto no es decisi&#243;n mia por desgracia y hay que intentar ser lo m&#225;s productivo con lo que se tiene".&lt;br /&gt;
&lt;br /&gt;
Tienes toooda la raz&#243;n :-), en tu caso es mucho mejor subir los ficheros de configuraci&#243;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. :-).&lt;br /&gt;
&lt;br /&gt;
&#191;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.&lt;br /&gt;
&lt;br /&gt;
&#191;JLibrary lo hace?&lt;br /&gt;
Saludos.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>[Alfredo]: &#8220;Si de mi dependiera no habr&iacute;a trabajando en nuestros proyectos ninguno de los del segundo grupo, pero esto no es decisi&oacute;n mia por desgracia y hay que intentar ser lo m&aacute;s productivo con lo que se tiene&#8221;.</p>
<p>Tienes toooda la raz&oacute;n :-), en tu caso es mucho mejor subir los ficheros de configuraci&oacute;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. :-).</p>
<p>&iquest;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.</p>
<p>&iquest;JLibrary lo hace?<br />
Saludos.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Claudex</title>
		<link>http://weblog.linkingpaths.com/2006/07/14/%c2%bfque-guardo-en-el-svn/#comment-204</link>
		<dc:creator>Claudex</dc:creator>
		<pubDate>Sat, 15 Jul 2006 07:27:54 +0000</pubDate>
		<guid>http://weblog.linkingpaths.com/2006/07/14/%c2%bfque-guardo-en-el-svn/#comment-204</guid>
		<description>&lt;p&gt;Estamos de acuerdo que si se ocupa un formato para documentaci&#243;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&#237;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&#243;digo.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Estamos de acuerdo que si se ocupa un formato para documentaci&oacute;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&iacute;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&oacute;digo.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alfredo</title>
		<link>http://weblog.linkingpaths.com/2006/07/14/%c2%bfque-guardo-en-el-svn/#comment-205</link>
		<dc:creator>Alfredo</dc:creator>
		<pubDate>Fri, 14 Jul 2006 18:50:55 +0000</pubDate>
		<guid>http://weblog.linkingpaths.com/2006/07/14/%c2%bfque-guardo-en-el-svn/#comment-205</guid>
		<description>&lt;p&gt;"Lo que comenta Alfredo de montarle el proyecto a sus analistas, es un problema de &#233;l al no explicarles o no dejarlos que se las vean con sus programas."&lt;br /&gt;
&lt;br /&gt;
Se lo puedo explicar, puedo hacer un documento que comente paso a paso como montarlo (que lo he hecho), &#191;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&#250;n interes y lo &#250;nico que harian seria seguir el documento al pie de la letra para montarse el proyecto en eclipse o lo que fuera. &#191;Entonces porque no subirlo directamente al CVS?, as&#237; se ahorran el tiempo que perderian montando el proyecto.&lt;br /&gt;
&lt;br /&gt;
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&#237;a trabajando en nuestros proyectos ninguno de los del segundo grupo, pero esto no es decisi&#243;n mia por desgracia y hay que intentar ser lo m&#225;s productivo con lo que se tiene, aunque a veces esto suponga no hacer las cosas de la forma m&#225;s ortodoxa...&lt;br /&gt;
&lt;br /&gt;
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&#243;digo con las versiones de la documentaci&#243;n pero no puedes ver los cambios entre versiones. Con un sistema externo puedes ver los cambios entre versiones pero no tienes la documentaci&#243;n sincronizada con el resto del proyecto, lo ideal ser&#237;a integrar las dos cosas.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>&#8220;Lo que comenta Alfredo de montarle el proyecto a sus analistas, es un problema de &eacute;l al no explicarles o no dejarlos que se las vean con sus programas.&#8221;</p>
<p>Se lo puedo explicar, puedo hacer un documento que comente paso a paso como montarlo (que lo he hecho), &iquest;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&uacute;n interes y lo &uacute;nico que harian seria seguir el documento al pie de la letra para montarse el proyecto en eclipse o lo que fuera. &iquest;Entonces porque no subirlo directamente al CVS?, as&iacute; se ahorran el tiempo que perderian montando el proyecto.</p>
<p>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&iacute;a trabajando en nuestros proyectos ninguno de los del segundo grupo, pero esto no es decisi&oacute;n mia por desgracia y hay que intentar ser lo m&aacute;s productivo con lo que se tiene, aunque a veces esto suponga no hacer las cosas de la forma m&aacute;s ortodoxa&#8230;</p>
<p>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&oacute;digo con las versiones de la documentaci&oacute;n pero no puedes ver los cambios entre versiones. Con un sistema externo puedes ver los cambios entre versiones pero no tienes la documentaci&oacute;n sincronizada con el resto del proyecto, lo ideal ser&iacute;a integrar las dos cosas.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: azuluaga</title>
		<link>http://weblog.linkingpaths.com/2006/07/14/%c2%bfque-guardo-en-el-svn/#comment-206</link>
		<dc:creator>azuluaga</dc:creator>
		<pubDate>Fri, 14 Jul 2006 16:59:31 +0000</pubDate>
		<guid>http://weblog.linkingpaths.com/2006/07/14/%c2%bfque-guardo-en-el-svn/#comment-206</guid>
		<description>&lt;p&gt;Estoy de acuerdo con ambos en guardar el c&#243;digo fuente y las pruebas de la aplicaci&#243;n.&lt;br /&gt;
Tampoco me gusta lo de mantener los archivos de configuraci&#243;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 &#233;l al no explicarles o no dejarlos que se las vean con sus programas.&lt;br /&gt;
&lt;br /&gt;
La documentaci&#243;n me parece importante mantenerla actualizada y el control de versiones (SVN o CVS) es una opci&#243;n aceptable, pero es ideal que con esos documentos se pueda hacer lo mismo que con el c&#243;digo fuente: comparar f&#237;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&#237;a con documentos de Microsoft Office u OpenOffice que viene a ser contenido binario (perd&#243;n por la inexactitud).&lt;br /&gt;
&lt;br /&gt;
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&#237; si me parece &#250;til el asunto con la documentaci&#243;n, de resto, ser&#237;a solo para conservar la historia del proyecto y a la larga servir&#237;a, pero servir&#237;a muy poco.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Estoy de acuerdo con ambos en guardar el c&oacute;digo fuente y las pruebas de la aplicaci&oacute;n.<br />
Tampoco me gusta lo de mantener los archivos de configuraci&oacute;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 &eacute;l al no explicarles o no dejarlos que se las vean con sus programas.</p>
<p>La documentaci&oacute;n me parece importante mantenerla actualizada y el control de versiones (SVN o CVS) es una opci&oacute;n aceptable, pero es ideal que con esos documentos se pueda hacer lo mismo que con el c&oacute;digo fuente: comparar f&iacute;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&iacute;a con documentos de Microsoft Office u OpenOffice que viene a ser contenido binario (perd&oacute;n por la inexactitud).</p>
<p>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&iacute; si me parece &uacute;til el asunto con la documentaci&oacute;n, de resto, ser&iacute;a solo para conservar la historia del proyecto y a la larga servir&iacute;a, pero servir&iacute;a muy poco.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alfredo</title>
		<link>http://weblog.linkingpaths.com/2006/07/14/%c2%bfque-guardo-en-el-svn/#comment-207</link>
		<dc:creator>Alfredo</dc:creator>
		<pubDate>Fri, 14 Jul 2006 16:27:41 +0000</pubDate>
		<guid>http://weblog.linkingpaths.com/2006/07/14/%c2%bfque-guardo-en-el-svn/#comment-207</guid>
		<description>&lt;p&gt;"Para mi las fuentes es todo aquello que se utiliza para generar la aplicaci&#243;n."&lt;br /&gt;
&lt;br /&gt;
En eso estoy de acuerdo, en lo que no estoy de acuerdo es que el control de versiones s&#243;lo tenga que tener "las fuentes". Algunos ejemplos:&lt;br /&gt;
&lt;br /&gt;
- Las clases de Test: no son necesarias para generar la aplicaci&#243;n pero su sitio creo que es el CVS.&lt;br /&gt;
- 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&#243;n tambi&#233;n debe ir al CVS.&lt;br /&gt;
- La documentaci&#243;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&#243;n sncronizada con la versi&#243;n de la aplicaci&#243;n. (no me refiero a los javadocs, sino a la documentaci&#243;n generada manualmente).&lt;br /&gt;
&lt;br /&gt;
En general yo guardo en el CVS cualquier cosa relativa al proyecto que no puede generarse automaticamente o partir de otros ficheros.&lt;br /&gt;
&lt;br /&gt;
Sobre lo de guardar los ficheros de IDE's, no lo veas como una imposici&#243;n sino como una opci&#243;n, en mi caso es obligatorio subir un ANT que permita compilar el proyecto, pero si adem&#225;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.&lt;br /&gt;
&lt;br /&gt;
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...&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>&#8220;Para mi las fuentes es todo aquello que se utiliza para generar la aplicaci&oacute;n.&#8221;</p>
<p>En eso estoy de acuerdo, en lo que no estoy de acuerdo es que el control de versiones s&oacute;lo tenga que tener &#8220;las fuentes&#8221;. Algunos ejemplos:</p>
<p>- Las clases de Test: no son necesarias para generar la aplicaci&oacute;n pero su sitio creo que es el CVS.<br />
- 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&oacute;n tambi&eacute;n debe ir al CVS.<br />
- La documentaci&oacute;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&oacute;n sncronizada con la versi&oacute;n de la aplicaci&oacute;n. (no me refiero a los javadocs, sino a la documentaci&oacute;n generada manualmente).</p>
<p>En general yo guardo en el CVS cualquier cosa relativa al proyecto que no puede generarse automaticamente o partir de otros ficheros.</p>
<p>Sobre lo de guardar los ficheros de IDE&#8217;s, no lo veas como una imposici&oacute;n sino como una opci&oacute;n, en mi caso es obligatorio subir un ANT que permita compilar el proyecto, pero si adem&aacute;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.</p>
<p>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&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
