<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>TUX-ES.com &#187; linux</title>
	<atom:link href="http://www.tux-es.com/project1/tag/linux/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.tux-es.com/project1</link>
	<description></description>
	<lastBuildDate>Thu, 08 Dec 2011 14:15:21 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>es</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Tips AdminLinux: Adiós a los .old .bkp .date</title>
		<link>http://www.tux-es.com/project1/2010/04/tips-adminlinux-adios-a-los-old-bkp-date/</link>
		<comments>http://www.tux-es.com/project1/2010/04/tips-adminlinux-adios-a-los-old-bkp-date/#comments</comments>
		<pubDate>Fri, 09 Apr 2010 08:27:54 +0000</pubDate>
		<dc:creator>macuriel</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[linux]]></category>
		<category><![CDATA[sysadmin]]></category>

		<guid isPermaLink="false">http://www.tux-es.com/project1/?p=632</guid>
		<description><![CDATA[Hoy he intentado acordarme de la buena práctica que realizaba cuando modificaba ficheros de configuración, y cómo se suele hacer. Creo que todos hemos visto ficheros con sufijos del tipo .old, .orig, .bkp, .fecha que sirven de pseudo-backup de un fichero importante de configuración.
No voy a entrar a valorar si este método es bueno o [...]]]></description>
			<content:encoded><![CDATA[<p>Hoy he intentado acordarme de la buena práctica que realizaba cuando modificaba ficheros de configuración, y cómo se suele hacer. Creo que todos hemos visto ficheros con sufijos del tipo .old, .orig, .bkp, .fecha que sirven de pseudo-backup de un fichero importante de configuración.</p>
<p>No voy a entrar a valorar si este método es bueno o malo, porque deberíamos evaluar otros factores como si la máquina es administrada por varios admins, si es un servidor crítico, si realmente queda documentada esa nomenclatura, etc&#8230;</p>
<p>Pero si quiero mencionar, y poner algún ejemplo de una metodología que si es estándar, y que hay un probabilidad muy elevada de encontrarla en casi cualquier sistema GNU/Linux: RCS utils. Con este sistema, tendremos un control de versiones con todas sus ventajas aplicado a un único fichero sin crear ni configurar nada adicional (ni repositorios, ni demonios, ni dependencias de servicios), solo instalando el paquete necesario <strong>rcs</strong>. Es raro que no esté instalado.</p>
<p>Esta información ha sido obtenida de <strong>RCS Intro &#8211; </strong><strong><a href="http://www.daemon-systems.org/man/rcsintro.1.html" target="_blank">http://www.daemon-systems.org/man/rcsintro.1.html</a></strong></p>
<p>¿Qué operaciones se suelen realizar con más frecuencia en un sistema de control de versiones?</p>
<ul>
<li>Crear ficheros nuevos</li>
<li>Modificar fichero existentes</li>
<li>Bloquear para evitar modificaciones concurrentes</li>
<li>Controlar versiones, y adjuntar comentarios para ver de forma rápida este Changelog</li>
<li>Comprobar diferencias entre versiones</li>
<li>Recuperar cualquier versión</li>
<li>Controlar el quién y el cuando de una modificación de fichero a lo largo de su vida</li>
</ul>
<p>Basándonos en esta pequeña lista, pondré los dos comandos que nos permitirán realizarlas:</p>
<p style="text-align: center;"><strong>co y ci</strong></p>
<p style="text-align: left;"><strong>Sigue leyendo para ver los ejemplos &#8230;</strong></p>
<p style="text-align: left;"><strong><span id="more-632"></span></strong></p>
<p style="text-align: left;"><strong>Ejemplos:</strong></p>
<p>$ vi fichero1 #Guardamos cambios</p>
<p>$ ci -u fichero 1 #Con esto creamos la primera revisión, y nos pedirá introducir un comentario con un breve resumen del contenido del fichero</p>
<p>A partir de este momento, tendremos dos ficheros parecidos: <em>fichero1 y fichero1,v</em>. Este segundo fichero contendrá todo el control de versiones, no será necesario nada más. El parámetro <em>-u</em> sirve para no borrar la copia local. En los sucesivos ci que hagamos, nos pedirá introducir un comentario, pero en este caso hará referencia a los cambios que hayamos realizado.</p>
<p>$ co -l fichero1 # Realizará un checkout, es decir obtendrá una copia de la última revisión del fichero, y además la bloquea por el <em>-l</em>.</p>
<p>A partir de este momento, estos dos comando serán los que más utilicemos para usar RCS sobre fichero concretos. Posteriormente podremos utilizar parámetros como <em>-r1.24</em> para indicarle a mano la revisión con la que se guardará el fichero, o la revisión que se obtendrá.</p>
<p>Podremos utilizar <em>rcsdiff</em> para ver las diferencias entre dos revisiones, o el comando <em>rlog</em> para ver toda la evolución del fichero con sus comentarios. Existen muchas más opciones, y quiero remitiros al enlace que puse en el artículo para que comprobéis las que más se ajustarán a vosotros.</p>
<p style="text-align: left;"><strong> </strong></p>
<p><strong> </strong></p>
]]></content:encoded>
			<wfw:commentRss>http://www.tux-es.com/project1/2010/04/tips-adminlinux-adios-a-los-old-bkp-date/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

