proyecto de practica Terminado xD

Pues si, despues de todo lo que me preocupe por como iba a hacer el proyecto, despues de tantas horas si poder dormir (puro drama :P) al fin logré terminar el proyecto de practica >_>

La idea es algo boba, pero era necesaria (o eso me dijeron) para la empresa, el proyeto mio consistió en coger el script de sincronización de servidores y modificarlo de tal manera que sincronizara carpetas dentro de un determinado repositorio.

Mas o menos la idea es asi:

El problema que se enfrenta en estos momentos podría ser solucionado de dos maneras válidas más sin embargo una de ellas no viable.

Primera (pero no viable):

Tener un repositorio base que es donde se encuentran los datos principales, y tener “sub-repositorios” (donde se va a guardar cada carpeta) para mantener las dos (o más) sedes sincronizadas, de esta manera habría que:

. 1.--> exportar la carpeta a un nuevo repositorio

2 . --> hacer un dump del repositorio

. ----> Trasladar el dump a la nueva máquina donde se quiere cargar el repositorio

4. .--> Cargar el dump en la nueva maquina.

Luego de esto automatizar una tarea cron para que cada determinado tiempo, se ejecute el script de sincronización de repositorios existente y así mantener el repositorio del servidor 1 sincronizado con el repositorio del servidor 2.

¿Pero porque no es viable? Respuesta: Por varias razones, entre ellas:

* Qué tal si tenemos más de una carpeta a ser sincronizada, habría que crear más de un repositorio y al otro lado tener el mismo número de repositorios a los que llegan la sincronización

* La gente ya está acostumbrada a subir y bajar datos del repositorio principal, seria ineficiente acostumbrar a la gente a subir determinados datos a un repositorio, y otros datos a otros repositorios, seria confuso y poco práctico.

* No se puede mesclar de dos repositorios existentes determinadas carpetas y sincronizarlo a un repositorio.

De esto podemos concluir que con esta primer alternativa, la conexión de sincronización que opera en los repositorios es una conexión 1:1, es decir por cada repositorio existente en Server 1, este solo tiene uno y solo un repositorio sincronizado en Server 2.

Segunda:

Tener en una red de repositorios, varias carpetas que se quieran sincronizar, no importa de donde vengan dichas carpetas e introducirlas a uno o varios repositorios, de tal forma que un repositorio sea la suma de varios repositorios.

Esta propuesta de proyecto de práctica, después de haber investigado las operaciones posibles sobre un repositorio de SVN, llegué a la conclusión de que podía haber dos maneras para desarrollar este modelo de sincronización las cuales eran:

Export – Import.

Procedemos para hacer un “dump” asi:

1. --> Del repositorio de inicio hacer un export de la carpeta que queremos sincronizar

2. --> Trasladar dicha carpeta al repositorio destino y adicionarla al nuevo repositorio

El problema de este enfoque es que cada vez que se quiera hacer una operación de sincronización, al no poseer el export un manejo de versiones, hay que traerse toda la carpeta y añadirla forzosamente, esto implica que cada vez que estamos haciendo updates, nos toca traernos toda la carpeta a la que se le añadió algo.

Por esta sencilla razón, esta opción queda completamente descartada, pues estamos desperdiciando demasiado ancho de banda trayéndonos toda la carpeta cada vez que se actualiza un pedazo del directorio.

SVN DIFF (La elegida)

Despues de hablar con el wise , este me recomendo usar svn diff, para esta aproximacion, procedemos de la siguiente manera:

1 1. Si la carpeta a hacer el backup nunca ha sido sincronizada, entonces realizamos un svn diff desde la revisión cero hasta la actual, de tal forma que nos traigamos todo el historial de todo lo que se ha hecho desde que se creó la carpeta y se añadió al repositorio hasta el momento actual.

2. Trasladar dicha carpeta al repositorio destino, revisar si la versión de la carpeta que estoy tratando de sincronizar es mas nueva en comparación con la del repositorio destino, si dicha carpeta está en su más reciente versión, entonces no realizar ningún cambio, de lo contrario “parchar” la carpeta con los cambios que esta trae.

El único problema que este enfoque presenta es que si se borra un archivo en el repositorio inicio, al momento de actualizar, en el repositorio destino, dicho archivo no es eliminado, sino que su contenido es el eliminado, es decir queda un archivo en blanco en el repositorio destino.