Mostrando entradas con la etiqueta repositorio. Mostrar todas las entradas
Mostrando entradas con la etiqueta repositorio. Mostrar todas las entradas

sábado, enero 13, 2018

PlasticSCM: Cambiar la ubicación del Repositorio

(Publicado originalmente por Carton Jeston en el foro Google de la Comunidad Visual FoxPro)
https://groups.google.com/d/msg/publicesvfoxpro/faUPGOBsdBs/kfg7jBtmBAAJ

---

Después de instalar plasticscm en su carpeta por defecto (c:\Program Files\PlasticSCM5\) los repositorios se guardan dentro de la subcarpeta SERVER.  No me parece una gran idea tener datos importantes en la misma partición de windows y necesito, por motivos de seguridad y para facilitar el backup, que estén separados y en otra ubicación.

Lo primero es salir del plasticscm y asegurar que no hay ningún servicio dependiente o archivo abierto y hacer una copia de seguridad de toda la carpeta PlasticSCM5 por si fallara algo.

Para este ejemplo, teniendo una unidad/particion D: para los datos importantes, creare una carpeta llamada PLASTIC en el disco D: (D:\PLASTIC) que es la nueva ubicación donde se guardaran los repositorios. Recomiendo usar siempre minúsculas aunque Windows no se vea afectado por ello.

Dentro de la subcarpeta SERVER hay un archivo de texto llamado DB.CONF, que si se instala por defecto con la base de datos SQLITE deberá tener esta información:


<DbConfig>
 
<ProviderName>sqlite</ProviderName>
 
<ConnectionString>Data Source={0};Synchronous=FULL;Journal Mode=WAL;Pooling=true</ConnectionString>
 
<DatabasePath></DatabasePath>
</DbConfig>

Y entre <DatabasePath>d:\plastic</DatabasePath> insertamos la ubicación de la carpeta que hemos creado antes, recordando que mejor en minúsculas, quedando así:



<DbConfig>
 
<ProviderName>sqlite</ProviderName>
 
<ConnectionString>Data Source={0};Synchronous=FULL;Journal Mode=WAL;Pooling=true</ConnectionString>
 
<DatabasePath>d:\plastic</DatabasePath>
</DbConfig>

Ahora guardamos los cambios el archivo que hemos editado DB.CONF.

Como hemos observado anteriormente, las bases de datos que empleaba plasticscm era SQLITE, así que buscamos en la misma carpeta SERVER todos los archivos con extensión .SQLITE y tendrás algo así:

repositories.plastic.sqlite
rep_1.sqlite
rep_2.sqlite
etc.


Ahora hay que moverlos todos a la nueva carpeta que creamos (D:\PLASTIC) y si todo ha ido bien, al abrir plasticscm apuntara a los repositorios guardados en esta ubicación.

Ya está.

En mi caso, cuando hago una versión nueva final de mi aplicación, hago la copia del workspace (donde esta nuestro proyecto, formularios, prg,etc) que tengo en esa unidad de datos y ahora ademas hago la copia de los repositorios para salvaguardar también la base de datos de los cambios de la versión de la aplicación. No hay que olvidar que un mal paso, un virus o una rotura de disco duro y siempre hay que tener copia de seguridad.



¿Como parar/reanudar el servicio de plastic para hacer un backup/restore de los repositorios?

Como he comentado arriba, conviene para el servicio de plasticscm antes de hacer un backup y sobre todo, al restaurar copiando nuestros repositorios puede dar errores.

Te darás cuenta que en la carpeta de los repositorios en algún momento habrán dos archivos con el nombre de un repositorio y con la extensión .sqlite-shm y .sqlite-wal y es porque plasticscm esta haciendo algún trabajo en segundo plano.

Para evitar conflictos, lo mejor es parar el servicio y que termine lo que esta haciendo y después hacer nuestras copias de los repositorios sin ningún problema.

Pulsar Ctrl+Alt+Supr y elegir la opción "Iniciar administrador de tareas". Pulsar en la pestaña Servicios, buscar el nombre PLASTIC SERVER 5 y pulsas con el botón derecho del ratón. Ahora elegir Detener servicio, hacer nuestras copias o restaurarlas en cuanto desaparezcan los dos archivos mencionados arriba y al terminar, botón derecho de nuevo sobre el servicio y elegir Iniciar servicio.

También puedes acceder a los Servicios a través del Panel de control de Windows, Herramientas administrativas y elegir Servicios.

Otro metodo alternativo mediante la consola de comandos del sistema (ejecutar-cmd) o automatizar mediante un archivo BAT o similar o bien acceso directo:

net start "plastic server 5"    >>> inicia el servicio     
                                                            
net stop  "plastic server 5"    >>> detiene el servicio    

[N.del E.] o también:

sc \\localhost start "plastic server 5"                      
                                                             
sc \\localhost stop  "plastic server 5"                      




Particularmente me gusta mucho este método por su automatización y porque te indica cuando ha terminado la operación correctamente y seguro para un proceso desatendido. Tener en cuenta de probarlo por primera vez manualmente y ver que el nombre del servicio no ha cambiado, actualmente es la versión plasticSCM 5.



Número del archivo de base de datos de Plastic

Para poder saber qué workspace tenemos en qué repositorio (BDD), debemos usar el comando cm desde la consola de Windows, con este parámetro:


cm lrep --format="TABLE"                                      

Que en mi caso deja una salida como esta:

 1 default localhost:8087                                     
 2 dvcs_vfp9 localhost:8087                                   
 5 foxpro_diff_merge localhost:8087                           
 6 filename_caps localhost:8087                               


Donde la primera columna contiene el número de repositorio, la segunda el nombre del workspace y la tercera la máquina:puerto donde apunta.

Si se está usando la nomenclatura de repositorio por defecto ( osea que no se ha cambiado) y se usa SQLite, entonces  el nombre del repositorio es de la forma:

rep_NN.plastic.sqlite

Y aplicando el número obtenido a la nomenclatura, se puede ver que el nombre de BDD del repositorio que contiene el workspace  dvcs_vfp9, será:

rep_2.plastic.sqlite


Nota: Para que el comando cm funcione sin tener que indicar la ruta cada vez, es buena idea agregar la ruta "c:\Program Files\PlasticSCM5\client" al PATH de Windows.



Hasta la próxima! :D

Artículos relacionados:
PlasticSCM: Opciones de conectividad, transporte del código fuente y backup
PlasticSCM: Cómo configurar la replicación de repositorios Plastic locales y remotos


viernes, agosto 15, 2014

PlasticSCM: Sincronización con GitHub

Por: Fernando D. Bozzo

En esta nota vamos a ver cómo se vincula y sincroniza un repositorio Plastic con GitHub.

Nota: Plastic tiene sus propios repositorios, y no necesita conectarse a repositorios externos como GitHub o BitBucket para funcionar. Esto solo se hace cuando específicamente se quiere trabajar con esos repositorios.


Un aviso importante:


   Una vez hecha la sincronización con GitHub ya no hay marcha atrás, y lo que se suba quedará subido y no se podrá borrar localmente. Aunque se intente borrar localmente (por ejemplo un changeset) en la siguiente sincronización se volverá a descargar todo y volverá a aparecer, y si no se controla bien los archivos que suben, sus conversiones a texto, su capitalización y el tipo de archivo (que no sea basura), puede perjudicar la sincronización con GitHub, lo que en la práctica puede significar tener que volver a hacer todo desde cero (crear otro repositorio Plastic, otro repositorio GitHub, etc), por eso insisto tanto en tomar las precauciones necesarias para no tener que perder tanto tiempo luego en reconfiguraciones.

Una vez aclarado el tema, ahora sí, el proceso de sincronización.


Pasos a seguir para sincronizar con un repositorio GitHub


1) Seleccionar el alias del workspace que se quiere sincronizar desde la solapa superior, justo bajo el título de la ventana (ejemplo: dvcs_vfp9). Como el workspace está vinculado a un directorio y al Repositorio (de hecho es un alias para una vista del repositorio), Plastic sabe de donde tomar la información y donde actualizar. También puede observarse que justo bajo la solapa del workspace está la información del mismo, en el formato:

Rama @ Repositorio @ servidor : puerto  y Workspace path (directorio del workspace)




2) Ahora vamos vincular nuestro repositorio con GitHub. Hacemos click-derecho en la rama /main sobre la parte gris que está fuera del punto azul (es poco margen al principio, pero se puede seleccionar y se quedará coloreada de azul claro, bajo los puntos circulares), se abrirá el menú contextual y en el título del panel derecho deben ver que dice "Nombre de la rama" (si dice "numero de changeset" eligieron mal), en este menú eligen "Replicación / Sincronizar con Git":



3) Aquí ponen la URL del repositorio de GitHub ( ejemplo: https://github.com/fdbozzo/dvcs_vfp9.git ) y el usuario y contraseña que usaron para darse de alta en GitHub, y pulsan "Sincronizar" (no se preocupen del nombre que figura en la captura, que es solo ilustrativo):



4) Si todo salió bien, deberían ver esto:



Si lo anterior sale en rojo, es que algo salió mal (por ejemplo, siguiente imagen) y se debe analizar el mensaje de error dado. En este caso, el error se debió a un bug de Plastic que reporté en febrero y que solucionaron:




5) Una vez que cierren esta pantalla, ya está hecha la sincronización y guardadas las credenciales para las próximas sincronizaciones.En el Explorador de ramas, si actualizan con F5 o con el icono de la flecha circular (a la derecha de ACCIONES PRINCIPALES), deberían poder ver dos o más puntos azules, al menos más puntos de los que veían antes de sincronizar. Esta vista es un gráfico de changesets (cambios) en el tiempo, donde pueden ver la fecha (arriba), y hacia la derecha siempre está lo más nuevo.



Nota importante:
Las ramas nuevas no hacerlas nunca del primer nodo de /main (el de más a la izquierda), debe hacerse de los posteriores y normalmente se hace desde el último changeset de la derecha, ya que si no les quedarán ramas fantasma que no podrá ver nadie mas.



Solución a algunos problemas sincronizando con GitHub u otro repositorio externo no-Plastic


Cuando se trabaja con repositorios externos como GitHub, BitBucket u otros, a veces las cosas pueden no salir como esperamos.

Si el problema es de conexión, o sea que da un error nada más intentar sincronizar, lo primero que se debe verificar son los datos de conexión al repositorio externo, como la URL, el usuario y la contraseña, que a veces poner mal un carácter impide la conexión.

Si se detecta que lo que uno de los usuarios ve no se corresponde con lo que debería ver, una solución podría ser que el usuario se cree un nuevo repositorio local, en un nuevo workspace y un nuevo directorio, vuelva a configurar la conexión al repositorio externo y sincronice. De esta forma se le bajará todo nuevamente, y si el repositorio local anterior tenía algún problema, entonces ese problema desaparece.

Normalmente esto lleva unos minutos, dependiendo del tamaño del repositorio externo.




Hasta la próxima!



martes, marzo 25, 2014

Control de Código Fuente: Terminología común que hay que conocer

Por: Fernando D. Bozzo

Esta entrada fue motivada por las inquietudes de algunos de ustedes durante las pruebas que hicimos en marzo 2014, y que me recordaron que en este tema hay términos de uso común que el que recién comienza no domina (obviamente), y por eso quiero hacer una breve reseña de los términos más usados y de lo que significan, y que iré completando a medida que me hagan nuevas preguntas sobre "¿qué significa tal término?".

Para facilitar las cosas, pondré alguna imagen cuando sea necesario y relacionaré los términos con los de FoxPro cuando pueda aplicarse.



Workspace


El workspace, que se traduce como "espacio de trabajo", es un alias que se le asigna a un directorio. Así como en FoxPro podemos usar un alias para usar una tabla bajo otro nombre, donde el alias "clientes" apunta a "c:\un-directorio\clientes.dbf", el workspace es eso mismo, pero aplicado a un directorio, de modo que si creamos un workspace llamado "dvcs_vfp9" para referirnos al directorio "c:\desa\tests\dvcs_vfp9", realmente estamos creando ese alias para que sea más fácil de manejar en Plastic, ya que es más cómodo mostrar un alias significativo en una de las solapas superiores que todo el nombre de un directorio, lo que dejaría poco lugar para las solapas de otros workspaces. De modo que hablar de "workspace" y de "directorio de trabajo" es lo mismo.

Vista del workspace "vfp_test_grupo" y el directorio que representa en Plastic





Checkin y Checkout



Check-in significa algo así como "verificar o realizar entrada", que es lo opuesto a Check-out, que es "verificar o realizar salida". Tanto la entrada como la salida se refiere a archivos, entrada o salida de archivos, o lo que es lo mismo, enviar/subir (checkin) o recuperar/bajar (checkout) archivos al servidor del Control de Código fuente.

El paralelismo con FoxPro sería el buffering de tablas, donde uno agrega, elimina o modifica registros en vez de archivos, en cualquier momento se pueden comprobar qué registros han cambiado con GetFldState (en Plastic se revisa la vista de Cambios Pendientes que actúa sobre los archivos del workspace) y luego se confirma la grabación de los mismos con TableUpdate (equivale al Check-in) o bien se pueden deshacer todos los cambios usando TableRevert (en Plastic equivale a "Deshacer Cambios"). El Checkout en Plastic solo es un estado que indica si un archivo está marcado para modificar o no. En otros SCM el checkout es la operación que se baja la última versión de un archivo al workspace, pero en Plastic esto se hace seleccionando un workspace por su solapa, o eligiendo "Actualizar workspace" en la vista de Items, o con el comando cm getfile en una ventana de comandos DOS.



Hacer un "Diff"


Versión corta: Hacer un Diff es buscar y mostrar las "Diferencias" (Differences en Inglés) entre dos archivos. Se usa para saber qué líneas o bloques de código se han cambiado entre dos versiones de un programa, por ejemplo trabajamos un rato en un programa, donde vamos guardando los cambios cada tanto (con checkin) y luego queremos ver los últimos cambios visualmente (a diferencia de tener que recordarlos)
Para la versión larga aplicada a Plastic, leer este artículo.



Hacer un "Merge"


Versión corta: Hacer un Merge es realizar la mezcla de las modificaciones hechas por separado a un mismo programa, para volver a tener un solo programa que tenga todos los cambios. Si yo tengo un programa copiado en dos directorios, a una copia le agrego un método "A" y a la otra copia le agrego un método "B", el merge sería tomar el programa original y agregarle los métodos "A" y "B".
Para la versión larga aplicada a Plastic, leer este artículo.



Cherry Pick


Versión corta: Es un tipo de Merge que permite seleccionar changesets o ramas específicas, sin incluir el resto de archivos heredados.
Para la versión larga aplicada a Plastic, leer este artículo.



Rama


Una rama es una línea paralela de trabajo, una copia completa del workspace (o directorio del proyecto) en la cuál poder trabajar sabiendo que a la copia original no la afectamos en lo más mínimo.
Una rama está compuesta por uno o más changesets.
En la práctica es como hacerse una copia del sistema en otro directorio y trabajar en él para, al terminar, pasar los cambios al directorio original.

Para la versión larga aplicada a Plastic, leer este artículo.

Imagen de la rama v1.19.17 de FoxBin2Prg con 4 changesets y una etiqueta de versión




Repositorio


En Plastic un repositorio es una base de datos (archivos de SQL Server, MySQL, etc) que contienen un grupo de tablas y esquemas que contendrán los archivos y relaciones que se hagan entre ellos.

Los archivos contenidos serán los que nosotros "subamos" al control de código, mediante las opciones "Agregar al control de código" o mediante los "checkin", y que también se pueden marcar opcionalmente como modificables con un checkout.

Normalmente se usa un repositorio por cada proyecto.



Changeset


"Changeset" significa "juego de cambios" o "conjunto de cambios", y se usa para identificar las operaciones de agregado, borrado o modificación hechos a uno o varios archivos que luego se guardan con checkin.
En Plastic se puede ver el contenido de las operaciones de un changeset haciendo doble click sobre uno de ellos.

Ejemplo de las operaciones contenidas en un changeset (archivos Movidos, Borrados y Añadidos):




Lista de archivos ignorados (ignore.conf)


Los archivos ignorados son aquellos archivos Privados que no nos interesa ver en la vista de Items de Plastic para mantenerla más despejada y poder enfocarnos en los archivos que sí nos interesa controlar. Es un filtro, un archivo de texto que contiene una lista de archivos o especificaciones de archivo donde generalmente se suelen anotar los .tmp (temporales), .fxp (compilados), .bak (backups), y demás archivos que no queramos ver.

Ejemplo de parte de un ignore.conf:

*.FXP
*.LNK
!/_iniciar aqui.lnk
*.SCC
*.TMP
*.BAK
*.ZIP
*.7Z

foxuser.dbf
*/FXUResults.*




Detalle de la especificación: 


En el ejemplo anterior tenemos los 4 tipos de ignore soportados, que se interpretan como un filtro con la función LIKE() en FoxPro:
  • La extensión sola (ej: *.FXP): Se ignoran todos los .fxp dentro del workspace, incluyendo subdirectorios
  • Un nombre de archivo (ej: foxuser.dbf): Se ignora el archivo indicado dentro del workspace, incluyendo subdirectorios
  • Un directorio con especificación de archivo (ej: */FXUResults.*): Se ignora el archivo dentro del directorio indicado. La raíz del workspace siempre es "/", que como se ve no es la contrabarra de Windows, sino el signo dividido que se usa en Linux y Mac para los directorios, ya que Plastic es multiplataforma
  • Una excepción a la regla (ej: !/_iniciar aqui.lnk): Este tipo realmente actúa como "anti-filtro" y es muy útil en los casos en los que tenemos definido un filtro, pero no queremos que se aplique en un directorio en particular. En el ejemplo dado se ignoran todos los accesos directos (*.lnk), pero se exceptúa de esta regla a un archivo en particular que está en la raíz y que se usa para abrir una sesión de FoxPro


Lista de archivos cloaked (cloaked.conf):


Los archivos cloaked son aquellos archivos controlados por Plastic, donde no nos interesa que se vuelvan a descargar o actualizar desde la base de datos.
Su uso habitual es para evitar que algunos archivos pesados (como un DBF con datos o un binario) se descarguen cada vez que actualizamos el workspace o nos cambiamos de changeset.
Se usa mucho en la industria del videojuego, donde ciertos mapas de textura pueden tener cientos de MB que tardarían un buen rato en descargarse y que al programador no le aporta nada para sus pruebas.

En FoxPro, un buen caso de uso podría ser el archivo "/_iniciar aqui.lnk" del ejemplo anterior, donde por un lado nos interesa controlarlo con Plastic para que todos los programadores se lo puedan descargar y que luego cada uno lo pueda personalizar según dónde tenga instalado FoxPro, poniéndolo en el cloaked.conf para que no se le vuelva a descargar y se pierda su configuración particular.

La especificación de archivos es la misma que para los ignorados.



Lista de cambios ocultos (hidden_changes.conf):


Los "cambios ocultos", como podría llegar a deducirse, son los archivos controlados por Plastic que no queremos ver en la vista de Cambios Pendientes aunque hayan sido modificados.
Un ejemplo podría un archivo LOG que se protegió inicialmente vacío, pero que suele cambiar frecuentemente y cuyo contenido no nos interesa que se guarde en la base de datos.

La especificación de archivos es la misma que para los ignorados.




Nivelar una rama


Nivelar una rama significa actualizarla con el contenido más actualizado de otra rama, y se hace tomando el contenido de otra rama (origen) y haciendo un merge sobre la rama a nivelar (destino).

Para nivelar una rama se debe estar ubicado sobre ella, en el último changeset más actualizado (en Plastic es donde se debe ubicar la casa)

Para la versión larga aplicada a Plastic, leer este artículo.



Si creen que faltan términos, me comentan y los voy agregando.


Saludos!