[ubuntu-ar] Script para copiar carpeta y excluir archivos.

Thu Apr 23 19:12:24 BST 2009

Mariano, lo tuyo es sublime.

PD: tengo 38, gracias por lo de "Uds los jovenes" !! jua jua
17+ años desarrollando en RPG para AS/400 ...

Mariano Mara escribió:
> On 23.04.09 11:32, Nicolas Machado wrote:
>   
>>    Mariano Mara escribió:
>>
>> 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í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]http://bazaar-vcs.org/
>>
>>
>>    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. http://bazaar-vcs.org/
>>     
>
> La idea que esté duplicado no es mala (no creo que pese gigas): tenés
> copias de respaldo como plan de contención. 
>
> Vamos a hacer dos cosas: te voy a proponer un modelo de trabajo para que
> sigas usando el workflow que tenés definido hoy en día y además te voy a
> proponer otro que yo veo como ideal y te voy a dar algunos ejemplos de
> donde tenés ventajas si usá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ás en el raíz del trunk y
> hacés
> bzr init
> luego deberá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í también podrás "ignorar" archivos (o sea que no se versionen).
> Luego te vas a tu sitio de producción y hacé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í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ón, te vas a la
> carpeta de producción, hacés un pull (o sea que traiga los cambios) y en
> tu sitio de producción solo vas a recibir las diferencias de los
> archivos que hayas cambiado y nada más (si esos cambios son de archivos
> que no estén ignorados).
> Ahí tenés tus dos pedidos originales respondidos y además tenés un
> historico de todos tus cambios por si los necesitás y no tocaste casi
> nada de como venís haciendo las cosas hoy en día.
>
> 2- Ahora vamos a un escenario más completo:
>
> * en la máquina de cada desarrollador tengo todo lo necesario para
> replicar el ambiente donde corre mi aplicación (un apache, un php
> completo, una base de datos con los datos de ejemplo o mejor aún una
> conexión remota a la base donde están los datos de ejemplo).
> * hago bzr init en mi servidor de desarrollo (como el paso anterior) y
> desde la má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í. Cada vez que tengo algo que quiero que el
> resto vea o que considero que está 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á disponible para todos (incluido el servidor
> de producción donde aplicarían los pasos que te comenté anteriormente).
> ¿Qué ganas vos con todo este despliegue?
> a- si te levantaste cruzado un día y muy poco inspirado te ponés a
> desarrollar y por esas casualidades haces alguna estupidez, no afectás
> ni el repositorio central ni el sitio de producción, solo tu versión.
> b- tenés copia de respaldo del desarrollo: ya se puede prender fuego el
> servidor y todos tus compañeros pueden desaparecer, vos seguís teniendo
> una copia de todo el trabajo y te reís de janeiro.
> c- ponele que tené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ítico no lo hacías: hacer un branch, te ponés a trabajar
> y justo que estás haciendolo llega un bug crítico que si o si hay que
> arreglar ahora: jamaica don't worry, te hacés otro branch de tu trunk
> (total los cambios que estabas haciendo no estaban ahí), arreglás el
> bug, subís el código  a tu copia local del trunk, lo subís al servidor y
> de ahí a producción. Tu branch con el nice to have sigue donde lo
> dejaste y no afectó tu trabajo.
>
> ¿Es más trabajo? Seguro
> ¿Vas a tener más copias? Seguro (aunque podés tener un shared repo donde
> se comparte el árbol de cambio).
> Pero al final del día vas a trabajar más tranquilo y te vas a ahorrar
> muchos dolores de cabeza que seguro tenés con tu workflow actual de
> trabajo (archivos pisados, cambios que no deberías haber hecho, cosas
> que te pisaste con otro desarrollador).
>
> Espero que esta guí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í el que te vaya mejor:
> http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/ubuntu-ar/attachments/20090423/18d2645c/attachment-0001.htm 