<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="-1"><font face="Verdana">Mariano, lo tuyo es sublime.<br>
<br>
PD: tengo 38, gracias por lo de "Uds los jovenes" !! jua jua<br>
17+ a&ntilde;os desarrollando en RPG para AS/400 ...<br>
<br>
</font></font><br>
Mariano Mara escribi&oacute;:
<blockquote cite="mid:20090423154635.GD6586@kafka.com.ar" type="cite">
  <pre wrap="">On 23.04.09 11:32, Nicolas Machado wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">   Mariano Mara escribi&oacute;:

On 23.04.09 10:10, Nicolas Machado wrote:


   buenos dias, soy algo nuevo en linux y mas en shell scripts.
   En una misma maquina tenemos un sitio PHP en lo que llamamos desarrollo
   y en otro httpdocs esta lo que llamamos produccion.
   necesito un script shell que me permita copiar desde desarrollo a
   produccion, pero
   que:
       Controle la fecha y si el de destino es mas nuevo , no lo copie
       que tampoco copie archivos de configuracion. (son dos el de la conf
   de bd y otro mas general )
   Alguien tiene algun ejemplo que me pueda servir de base?
   Los archivos son .php, imagenes, y alguno otro
   Muchas gracias
   Nicolas


Deber&iacute;as usar un sistema de control de version para esas cosas donde
puedas ignorar archivos y se encargue por vos de pasar las
modificaciones. Hay muchisimos dando vueltas, yo te recomiendo bzr[1]

Mariano

[1] [1]<a class="moz-txt-link-freetext" href="http://bazaar-vcs.org/">http://bazaar-vcs.org/</a>


   Ante todo gracias Mariano.
   La duda que siempre tuve con los CVS, y por eso no lo uso, es la
   siguiente:
   En el caso de una aplicacion php uno esta desarrollando sobre el sitio
   directamente, es decir cambio el php, F5 en el browser y ya veo el
   cambio.
   si tengo q crear mi propio directorio con todos los php de la
   aplicacion estaria duplicando el sitio, creo.
   Si ademas somos 2 los desarrolladores, estamos triplicando el sitio.
   y si ademas tengo un entorno que llamo produccion, lo estoy
   cuadruplicando.
   teniendo en cuenta que el sitio YA esta creado, cual seria la mejor
   manera de ahora que esta "listo" y en la version 1.0, cargarlo a un CVS
   ?
   incluso habia pensado en que el repositorio estuviera en internet, pero
   no me cerrabala idea de tener el sitio en cada usuario .
   Es asi como deberia trabajar ?
   Alguna sugerencia ?
   Saludos
   y gracias

References

   1. <a class="moz-txt-link-freetext" href="http://bazaar-vcs.org/">http://bazaar-vcs.org/</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->
La idea que est&eacute; duplicado no es mala (no creo que pese gigas): ten&eacute;s
copias de respaldo como plan de contenci&oacute;n. 

Vamos a hacer dos cosas: te voy a proponer un modelo de trabajo para que
sigas usando el workflow que ten&eacute;s definido hoy en d&iacute;a y adem&aacute;s te voy a
proponer otro que yo veo como ideal y te voy a dar algunos ejemplos de
donde ten&eacute;s ventajas si us&aacute;s el que te propongo.

1- Tu workflow actual pero con versionado:
Tu carpeta desarrollo es tu mainline de trabajo (la vamos a llamar
trunk) y es tu objetivo principal de trabajo.
Para versionarla con bzr [1] simplemente te par&aacute;s en el ra&iacute;z del trunk y
hac&eacute;s
bzr init
luego deber&aacute;s agregar los archivos y hacer el commit inicial (te dejo los
detalles para que los investigues en los docs de bzr: son muy simples).
All&iacute; tambi&eacute;n podr&aacute;s "ignorar" archivos (o sea que no se versionen).
Luego te vas a tu sitio de producci&oacute;n y hac&eacute;s que sea una copia de tu
trunk (no una copia por linea de comandos, una copia por ejemplo con el
comando branch que solo va a copiar los archivos que vos hayas agregado
y no los que ignores).
Estar&iacute;a listo: cada vez que hagas algo en tu trunk, le das commit (eso
te va a permitir recuperar cosas anteriores si es necesario, por
ejemplo) y cada vez que tengas algo listo para producci&oacute;n, te vas a la
carpeta de producci&oacute;n, hac&eacute;s un pull (o sea que traiga los cambios) y en
tu sitio de producci&oacute;n solo vas a recibir las diferencias de los
archivos que hayas cambiado y nada m&aacute;s (si esos cambios son de archivos
que no est&eacute;n ignorados).
Ah&iacute; ten&eacute;s tus dos pedidos originales respondidos y adem&aacute;s ten&eacute;s un
historico de todos tus cambios por si los necesit&aacute;s y no tocaste casi
nada de como ven&iacute;s haciendo las cosas hoy en d&iacute;a.

2- Ahora vamos a un escenario m&aacute;s completo:

* en la m&aacute;quina de cada desarrollador tengo todo lo necesario para
replicar el ambiente donde corre mi aplicaci&oacute;n (un apache, un php
completo, una base de datos con los datos de ejemplo o mejor a&uacute;n una
conexi&oacute;n remota a la base donde est&aacute;n los datos de ejemplo).
* hago bzr init en mi servidor de desarrollo (como el paso anterior) y
desde la m&aacute;quina de cada desarrollador hago un branch y tengo una
copia en local: yo desarrollador me hago "otra" copia de ese trunk y
trabajo exclusivamente ah&iacute;. Cada vez que tengo algo que quiero que el
resto vea o que considero que est&aacute; listo para subirse, lo paso a mi
"trunk" local y subo esos cambios al servidor de desarrollo. A partir de
ese momento ese cambio est&aacute; disponible para todos (incluido el servidor
de producci&oacute;n donde aplicar&iacute;an los pasos que te coment&eacute; anteriormente).
&iquest;Qu&eacute; ganas vos con todo este despliegue?
a- si te levantaste cruzado un d&iacute;a y muy poco inspirado te pon&eacute;s a
desarrollar y por esas casualidades haces alguna estupidez, no afect&aacute;s
ni el repositorio central ni el sitio de producci&oacute;n, solo tu versi&oacute;n.
b- ten&eacute;s copia de respaldo del desarrollo: ya se puede prender fuego el
servidor y todos tus compa&ntilde;eros pueden desaparecer, vos segu&iacute;s teniendo
una copia de todo el trabajo y te re&iacute;s de janeiro.
c- ponele que ten&eacute;s mucho tiempo libre porque no hay nada para hacer y
ya te aburriste de jugar al arkanoyd, el buble buble o alguno de esos
juegos modernos que tienen ustedes los jovenes y finalmente vas a
ponerte a hacer ese nice-to-have que alguna vez te pidieron pero como
era muy poco cr&iacute;tico no lo hac&iacute;as: hacer un branch, te pon&eacute;s a trabajar
y justo que est&aacute;s haciendolo llega un bug cr&iacute;tico que si o si hay que
arreglar ahora: jamaica don't worry, te hac&eacute;s otro branch de tu trunk
(total los cambios que estabas haciendo no estaban ah&iacute;), arregl&aacute;s el
bug, sub&iacute;s el c&oacute;digo  a tu copia local del trunk, lo sub&iacute;s al servidor y
de ah&iacute; a producci&oacute;n. Tu branch con el nice to have sigue donde lo
dejaste y no afect&oacute; tu trabajo.

&iquest;Es m&aacute;s trabajo? Seguro
&iquest;Vas a tener m&aacute;s copias? Seguro (aunque pod&eacute;s tener un shared repo donde
se comparte el &aacute;rbol de cambio).
Pero al final del d&iacute;a vas a trabajar m&aacute;s tranquilo y te vas a ahorrar
muchos dolores de cabeza que seguro ten&eacute;s con tu workflow actual de
trabajo (archivos pisados, cambios que no deber&iacute;as haber hecho, cosas
que te pisaste con otro desarrollador).

Espero que esta gu&iacute;a a las apuradas te sirva como respuesta.
Suerte con eso.

[1] te hago el ejemplo con bzr pero hay muchos otros dando vueltas, vos
comparalos y eleg&iacute; el que te vaya mejor:
<a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Comparison_of_revision_control_software">http://en.wikipedia.org/wiki/Comparison_of_revision_control_software</a>


  </pre>
</blockquote>
</body>
</html>