GXServer Lab

Bienvenido al Laboratorio
de GeneXus Server 2014

Laboratorio GeneXus Server
Página 1
Introducción
Copyright  Artech Consultores S. R. L. 1988-2014.
Todos los derechos reservados. Este documento no puede ser reproducido en cualquier medio sin el
consentimiento explícito de Artech Consultores S.R.L. La información contenida en este documento es para uso
personal únicamente.
Marcas Registradas
Artech y GeneXus son marcas o marcas registradas de Artech Consultores S.R.L. Todas las demás marcas
mencionadas en este documento son propiedad de sus respectivos dueños.

Página 2
Introducción
Introducción
¿Qué es GXserver?
GeneXus Server es una herramienta que facilita el trabajo en equipo.
El desarrollo de software es una actividad que generalmente se realiza en equipo, y por lo
tanto implica la necesidad de cierta interacción entre los desarrolladores. Sin embargo
esta interacción no se realiza en forma continua, pues cada desarrollador necesita de cierto
tiempo, por ejemplo, para implementar una nueva característica o para reparar algún error
en el código. A su vez, es importante poder realizar estas tareas en un ambiente aislado
para no verse afectado por los constantes cambios que pueden estar introduciendo los
otros miembros del equipo.
Una vez que el desarrollador termina de hacer la tarea que tenía asignada, deberá integrar
su trabajo con el resto del equipo, tanto para añadir los cambios que haya realizado, como
para recibir los cambios que hayan introducido los otros desarrolladores.
Este ciclo se repite en forma constante para todos los miembros del equipo, y por tanto es
necesaria una herramienta que provea un ambiente aislado para cada desarrollador y
que también brinde un servicio de comunicación para integrar su trabajo con los demás.
GeneXus Server provee ambas funcionalidades, permitiendo que cada desarrollador
trabaje en su propia copia local de la base de conocimiento, que a su vez está asociada a
una copia central de la misma base de conocimiento en la cual se integra el trabajo de
todos los desarrolladores.

Página 3
Introducción

Página 4
Modalidad del Laboratorio
GeneXus Server es una herramienta que facilita el trabajo en equipo y por lo tanto a lo largo
de este laboratorio veremos cómo se lleva a cabo esta tarea.
Para esto, simularemos un equipo de desarrollo compuesto por dos integrantes: Diego y
Mary.
En cada una de las computadoras hay dos IDEs de GeneXus abiertos, uno simula el trabajo
de Diego (azul) y el otro el trabajo de Mary (plateado).
Ya que en el laboratorio vamos a estar trabajando con dos personas por computadora, se
propone que la persona de la derecha haga el trabajo de Mary y la persona de la izquierda
haga el trabajo de Diego.
De esta forma cuando en la letra se indique que Mary debe hacer algo, será la persona de la
derecha la que trabaje utilizando el IDE de color plateado y cuando se indique que Diego
debe hacer algo, será la persona de la izquierda quien debe trabajar utilizando el IDE azul
(en caso que se encuentre sólo realice tanto las tareas de Diego como de Mary).

Página 5

Laboratorio
En este laboratorio veremos las operaciones básicas de GeneXus Server: Send KB to
Server, Create KB from Server, Commit y Update.
Además veremos como GeneXus Server resuelve ciertos problemas con los cuales nos
podemos encontrar a la hora de consolidar nuestro trabajo con el resto del equipo.
También se mostrará el versionado en GeneXus Server: creación de versiones congeladas,
creación de versiones de desarrollo a partir de una versión congelada, pasaje de cambios
entre versiones, etc.
Primera parte
Paso 1
Una vez creados los usuarios se puede pasar a crear el nuevo proyecto llamado
“Laboratorio2014”.
Para esto Mary debe crear una nueva base de conocimiento llamada Laboratorio2014.
 Vaya al IDE plateado y cree una nueva base de conocimiento (Ctrl+Shift+N). Cambie el
nombre a “Laboratorio2014” y haga click en “Create”1
.
No importa el Prototyping Environment seleccionado, puede seleccionar uno distinto a Ruby
Environment

Laboratorio GeneXus Server X Evolution 3 | 7
Una vez creada la base de conocimiento, la misma podrá ser editada por Mary, pero
todavía no estará disponible para el resto del equipo de desarrollo.
Ahora Mary debe publicar la base de conocimiento para que la misma quede disponible
para los otros desarrolladores y así puedan comenzar a trabajar en equipo.
Para esto, simplemente alcanza con que Mary haga la operación Send KB to Server, por lo
tanto,
 En el IDE plateado abra el menú “File” y seleccione la opción “Send Knowledge Base to
Server”.

Genexus desplegará el diálogo para enviar una KB a GeneXus Server. Mediante este
proceso será posible crear una base de conocimiento centralizada (la cual llamaremos KB
de GeneXus Server) que es una copia de la base de conocimiento local (la cual llamaremos
KB local) en la que estaba trabajando Mary. La KB local de Mary quedará automáticamente
enganchada a la KB de GeneXus Server, de tal forma que cuando Mary lo disponga pueda
impactar los cambios realizados en su KB local, en la KB de GeneXus Server. Además pueda
recibir los cambios que otros desarrolladores hagan en la KB de GeneXus Server, en su KB
local.
Por defecto se mostrará la URL del servicio http://sandbox.genexusserver.com/xev3/
Sin embargo el servicio que van a utilizar Diego y Mary es
http://www.laboratoriogxserver.com/evento.
 Ingrese la URL a la que debe enviar la KB Mary:
http://www.laboratoriogxserver.com/evento.
 Seleccione la version Laboratorio2014.
 En la sección “Security” seleccione el tipo de autenticación “Local” e ingrese username
mary y password mary.

 A continuación haga click en “Send” y simplemente espere a que finalice la operación.
Como podrá ver se agregó en GeneXus una opción Team Development al menú Knowledge
Manager que utilizaremos para interactuar con el server y además si vamos a las
Preferences podemos ver que se agregó un nuevo nodo al árbol llamado Team
Development que guarda la información de la conexión con GeneXus Server, como se
puede ver en la siguiente imagen:

GXserver simplifica el trabajo en equipo. Al automatizar la
integración de cambios, permite que los integrantes del equipo
puedan concentrarse en el desarrollo, sin perder tiempo y esfuerzos
en la consolidación.
Paso 2
En el Paso 2 lo que haremos será integrar a Diego al equipo de desarrolladores que
trabajarán con la base de conocimiento “Laboratorio2014”.
Para esto simplemente alcanza con hacer la operación llamada Create KB from Server.
¿Qué hace esta operación? Lo que hace es, a partir de la KB de GeneXus Server que se creó
cuando Mary publicó su KB local, le crea a Diego su propia copia local y la misma también
queda automáticamente enganchada a la KB de GeneXus Server, de forma que también
pueda integrar sus cambios con el resto del equipo.
 Vaya al IDE azul (IDE de Diego) y elija la opción de menú “File” / “New” / “Knowledge
Base from Server”, lo cual desplegará el correspondiente diálogo.

Como “Server KB URL” ingresamos la misma en la que Mary publicó su base de
conocimiento http://www.laboratoriogxserver.com/evento.
 Después hacemos click en “Select Server KB…”, lo cual nos listará todas las bases de
conocimiento que se hayan publicado en dicho Genexus Server. En este caso será sólo
Laboratorio2014.

 En este caso como queremos realizar la operación de “Create KB From Server” con un
usuario diferente seleccionamos el servidor “evento” de la lista “Servers”, hacemos click
derecho y luego “Edit”. En el siguiente diálogo ingresamos en el campo “Username” el
nombre “diego” y en Password “diego” y marcamos el checkbox de “Save Password”.
 Luego seleccionamos la KB “Laboratorio2014” presionando “Select”.

 Luego de presionar “Select” se abrirá nuevamente el diálogo original donde debemos
seleccionar la versión Trunk e ingresamos el nombre de la nueva KB, que crearemos
como“Laboratorio2014_Diego”.
 Hacemos click en Create, y aguardamos a que finalice la operación.
Publicar el trabajo e integrarse a la KB central se realiza en dos
simples pasos, permitiendo desarrollar en un ambiente local y
autónomo, pero manteniendo la vinculación con el proyecto
centralizado.
Paso 3
En este momento tenemos a dos desarrolladores, Mary y Diego, los cuales tienen cada
uno, una copia local de la base de conocimiento, y a su vez se creó una base de
conocimiento de GeneXus Server que será sobre la cual se impactarán los cambios de
ambos desarrolladores.
Ahora vamos a comenzar a trabajar con cada uno de los desarrolladores.
 En el IDE de Mary (IDE plateado) cree la transacción Salon (puede utilizar el atajo Ctrl+N)
para que quede de la siguiente manera y guarde los cambios.

Ahora supongamos que Mary quiere integrar su transacción Salon a la KB de GeneXus
Server para que los demás desarrolladores puedan recibir este cambio.
 Seleccione el menú “Knowledge Manager” / “Team Development”.

En el diálogo de Team Development puede observar cuatro pestañas: Commit, Update,
History y Versions. A lo largo del laboratorio veremos qué funcionalidades ofrecen algunas
de estas pestañas.
Al momento de ingresar, en la pestaña de Commit GeneXus presentará automáticamente
todos los objetos que han sido modificados localmente y que por lo tanto están pendientes
para commit. Es decir, son cambios a los cuales los demás desarrolladores todavía no
tienen acceso (porque no están consolidados).
La columna Action indica si es un objeto nuevo que no está en la KB de GeneXus Server
(Inserted), un objeto modificado (Modified), o si es un objeto que se borró (Deleted). En
este caso como la transacción es nueva se puede ver que la Action es Inserted.
Lo único que resta antes de consolidar los cambios locales con los de la KB de GeneXus
Server es añadir un comentario. En Genexus Server los comentarios son obligatorios ya
que son considerados una buena práctica que ayuda a entender mejor la razón de por qué
se realizan los cambios.
 En este caso ponga en el comentario “Se añade la transacción Salon” y luego haga click en
el botón “Commit”.

Con esto, los cambios locales de Mary quedan consolidados en la KB de GeneXus Server y
por lo tanto estarán disponibles para los demás usuarios.
De igual forma, Diego podría crear todos los objetos que desee y siguiendo los mismos
pasos que Mary, podría integrarlos a la KB de GeneXus Server para que queden
disponibles para los demás desarrolladores.
GXserver permite publicar fácilmente los cambios realizados en
forma local, al tiempo que mejora y centraliza la documentación del
desarrollo.
Paso 4
Ahora supongamos que Diego quiere recibir todos los cambios que hayan introducido los
otros desarrolladores.
 Para ésto, en el IDE azul vaya al menú “Knowledge Manager” / “Team Development”.
 Seleccione la pestaña “Update”.

En el dialogo de Update, tenemos dos opciones: Update y Preview. La opción de Update
nos permite actualizar nuestra KB recibiendo todos los cambios que estén en el server y
que aún no hayamos recibido. Si quisiéramos hacer una actualización parcial, podemos
usar la opción de Preview que nos mostrará la lista de objetos a actualizar y podremos
seleccionar los que queramos.
 En este caso haga click en “Update” para que traiga todos los cambios directamente.
Al finalizar la operación se mostrará una lista de los objetos modificados.
Con estos sencillos pasos Diego obtuvo los cambios de los demás desarrolladores en su KB
local.

De esta forma Diego y Mary podrían repetir este ciclo todas las veces que sea necesario y
estarían consolidando sus cambios de una forma muy simple.
GXserver permite recibir fácilmente los avances que hayan realizado
los demás miembros del equipo, quienes podrían estar trabajando en
diferentes horarios y lugares.
Segunda Parte
Paso 5
Lógicamente, mientras Mary y Diego editen objetos distintos no habrá ningún problema,
pero uno podría preguntarse ¿qué pasa si ambos modifican el mismo objeto?
En este paso ambos desarrolladores modificarán la transacción Salon y veremos cómo
GeneXus Server integra los cambios.
Primero Diego le añadirá a la transacción el atributo SalonColor, por lo tanto:
 En el IDE azul, abra la transacción y agregue el atributo “SalonColor” de la siguiente
manera, guardando los cambios al finalizar
Luego vamos a publicar los cambios de Diego de la misma forma que en el Paso 3.

 Ir a la ventana de “Team Development”, pestaña “Commit”, hacer click en el botón
“Refresh” y escribir como comentario “Se añade el atributo SalonColor a la transacción
Salon”. Por último hacer click en Commit2
.
Ahora hagamos que Mary le agregue a la transacción Salon el atributo SalonCantidadSillas,
por lo tanto:
 Vaya al IDE plateado y modifique la transacción agregando el atributo
“SalonCantidadSillas” y luego guarde los cambios de la siguiente forma.
Si ya tenía abierto el diálogo de TeamDevelopment y al ir a la pestaña Commit no le
aparecen objetos pendientes, asegúrese de haber guardado los cambios y presione el botón
Refresh que aparece en la pestaña Commit.

A continuación integraremos los cambios locales de Mary con la KB de GeneXus Server,
para esto al igual que en el Paso 3:
 Vaya a la ventana de “Team Development”, en la pestaña de Commit, y haga click en
“Refresh”
 Escriba como comentario “Se añade el atributo SalonCantidadSillas a la transacción Salon”
y haga click en “Commit”.
Usted debería recibir el siguiente mensaje de error en el output:
Esta es una situación normal. GeneXus Server simplemente le está indicando que algún
otro desarrollador ya modificó la transacción, y por lo tanto no puede recibir los nuevos
cambios3
. Estos cambios deberán ser primero integrados en una nueva versión local para
luego ser enviados a GeneXus Server.
Esta integración se logra muy fácilmente haciendo un Update para actualizar la
transacción.
Para esto:
 Seleccione la pestaña “Update” y en este caso haga click en “Preview”.
Si GeneXus Server aceptara recibir el objeto en este momento, se perderían los cambios que
hicieron los demás miembros del equipo.

Como se puede ver, GeneXus lista la transacción Salon ya que la misma fue modificada por
Diego. Si hacemos click derecho sobre la transacción y seleccionamos la opción “Compare
With Current Revision”, nos mostrará las diferencias entre el objeto local y el objeto en el
server.
En este caso las líneas modificadas son distintas y por lo tanto cuando realicemos la
operación de Update, Genexus hará una integración automática (merge) entre la versión
de GeneXus Server y la versión local de los objetos involucrados en el conflicto, quedando
el objeto pendiente para commit, y permitiendo publicar los cambios que realizó Mary. El
estado del objeto en este momento es exactamente equivalente a que Mary hubiera hecho
sus cambios partiendo de la versión ya modificada por Diego.

Por lo tanto:
 Cierre la ventana del “Comparer” y en la ventana de “Team Development” haga click en
“Update Selected”.
En el output podrá ver el siguiente mensaje que le indicará que Genexus Server hizo el
merge del objeto.
 Luego vaya a la pestaña “Commit” y haga click en el botón “Commit”.
La operación ahora sí finalizará con éxito y quedarán consolidados tanto los cambios de
Mary como los de Diego sobre la transacción Salon.
Es importante notar que se destacará con color verde el objeto “Salon” afectado por la
operación de Merge.

Ahora veamos qué pasa cuando ambos modifican la misma línea en el mismo objeto.
Para esto Mary añadirá un procedimiento y lo llamará Saludo. Luego deberá publicar este
nuevo objeto.
 Cree un Procedure GeneXus de nombre “Saludo” y guarde el cambio (recuerde que puede
utilizar el atajo Ctrl+N).
 Vaya a la ventana de “Team Development”, en la pestaña de “Commit” presione el botón
“Refresh”
 Escriba como comentario “Se añade el procedimiento Saludo” y haga click en “Commit”

Ahora Diego debe recibir este objeto
 Vaya al IDE azul y en la ventana de “Team Development”, seleccione la pestaña “Update”4
 Haga click en el botón “Start New Update” y luego presione el botón “Update”
Ambos desarrolladores tienen en este momento el procedimiento Saludo en su copia local
 Vaya al IDE plateado y añada el siguiente código al procedimiento y guarde los cambios.
Luego publique el cambio. Para esto nuevamente:
 En la pestaña “Commit” de “Team Development” agregue el comentario “Se añade un Msg
de Hello al comienzo del procedimiento Saludo” y haga click en “Commit”.
Ahora Diego modificará también el procedimiento.
 Vaya al IDE azul, abra el procedimiento “Saludo” e introduzca la siguiente línea de código
Msg(“Goodbye World”)
 Guarde los cambios.
 Luego en la pestaña “Commit” de “Team Development”, haga click en el botón “Refresh”,
agregue el comentario “Se añade un Msg de Goodbye al comienzo del procedimiento
Saludo” y haga click en “Commit”.
GeneXus Server le dará el error que tuvo anteriormente Mary, ya que el procedimiento ha
sido modificado en una fecha posterior a la última sincronización con GeneXus Server.
Si tenía abierto el diálogo de TeamDevelopment abierto debe hacer click en el botón Start
New Update para que nuevamente se habiliten los botones Update y Preview.

 Vaya a la pestaña “Update”, luego presione “Start New Update”, seleccione “Preview”, y
luego haga click derecho sobre el procedimiento “Saludo” y elija la opción “Compare With
Current Revision”.
Se puede ver que se ha modificado la misma línea de código en ambos procedimientos, y
por lo tanto al hacer Update, GeneXus no tiene forma de deducir una combinación
correcta de ambos cambios. En esta situación GeneXus hará prevalecer el estado que se
tiene en GeneXus Server, sobre-escribiendo los cambios locales, pero advirtiéndole al
usuario del caso, y dándole una manera muy fácil de cambiar esta decisión ya sea que
usted decida mantener sus propios cambios, o combinarlos de cierta manera.
 Cierre el “Comparer”, vaya a la ventana “Team Development” y seleccione “Update
Selected”.
Como habíamos anticipado, en el output aparecerá el siguiente mensaje que le advierte
que GeneXus resolvió el conflicto tomando el objeto en el server, y permitiéndole al
desarrollador editarlo manualmente, o volver a su propia versión anterior.

Supongamos ahora que Diego sabe que su versión es la correcta y no la que estaba en el
GeneXus Server. Entonces Diego puede revertir los cambios aplicados en la operación de
Update sobre el procedimiento Saludo.
 En el IDE azul abra el procedimiento “Saludo”, haga click derecho sobre la pestaña del
procedimiento y seleccione la opción “History”
 Seleccione la penúltima versión de las que aparecen (que es precisamente la que tenía los
cambios de Diego), haga click derecho y seleccione “Restore this revisión” como muestra la
figura.

 Confirme el cambio y el objeto volverá a la versión anterior.
 Ahora debe marcar, desde el diálogo de “Commit”, que ha resuelto el conflicto. Para hacer
esto abra el diálogo de “Commit”, luego click derecho sobre el Procedure “Saludo” y elija la
opción “Mark as resolved” como se muestra en la siguiente figura.
 Luego de marcar el conflicto como resuelto será posible realizar la operación de “Commit”.
Agregue el objeto a la lista que serán incluidos en la operación de Commit y haga click en el
botón “Commit”.

GXserver garantiza la integridad de los objetos y evita la pérdida de
modificaciones. Resuelve de forma automática e inteligente todas las
situaciones en que esto es posible, pero mantiene el control del
desarrollador para los casos en que sea necesario.
Paso 6
Imaginemos que Diego y Mary después de trabajar un cierto tiempo desarrollan un
producto que cumple con los requerimientos necesarios para hacer una primera
liberación.
Es importante entonces tener alguna forma de congelar el estado de la base de
conocimiento, de forma que no se puedan introducir nuevos cambios a la misma, pero a
su vez también es necesario tener alguna forma de poder seguir implementando nuevas
características, por ejemplo para una versión 2.0 del producto.
¿Cómo podemos hacer esto con GeneXus Server?
GeneXus Server le brinda una consola de Administración la cual le ofrece diversas
funcionalidades. Por ahora solo nos centraremos en el manejo de versiones a través de la
consola.
 Abra el navegador e ingrese la siguiente URL:
www.laboratoriogxserver.com/evento/main.aspx
La siguiente página se abrirá:

 Ingrese como User y Password mary y tipo de autenticación Local
Lo primero que nos muestra es el Dashboard donde se muestra distinta información,
como por ejemplo la actividad más reciente, las KBs favoritas, etc. En este caso sólo está la
base de conocimiento anteriormente publicada por Mary, “Laboratorio2014” y las
operaciones realizadas sobre la misma.

Ahora vamos a abrir una KB en la consola. Para esto:
 Haga click en la opción “All” que se encuentra dentro del grupo “KNOWLEDGE BASES” del
árbol de la izquierda. Luego seleccione la opción “Open KB”.

Al momento de abrir la base de conocimiento, se mostrará el contenido de la página KB
Dashboard. Esta página muestra información relevante a la KB abierta, como por ejemplo
nombre de la versión activa (abierta), cantidad de objetos de cada tipo y los últimos
commits entre otros.
La pestaña de Versions nos permite crear y borrar nuevas versiones de la base de
conocimiento, que es en lo que nos concentraremos a continuación.
 Vaya a la opción Versions que se encuentra en la ventana KB Dashboard
 Pase el mouse sobre el recuadro plateado que dice “Laboratorio2014”, esta es la versión
Trunk que es sobre la que han estado trabajando. Al pasar el mouse le aparecerá un ícono
rojo a la derecha. Al hacer click sobre este se desplegará el menú que se ve a continuación.

 Haga click en el ícono y seleccione del menú desplegable la opción “Freeze”, lo cual
permitirá crear una versión congelada del estado actual de la versión seleccionada,
evitando así que se puedan hacer Commits en esta nueva versión.
 Ingrese como nombre para la nueva versión “Laboratorio2014 1.0” y haga click en OK
Luego de creada, aparecerá en el árbol la nueva versión congelada.
Recuerde que si bien se creó una nueva versión congelada, tanto Mary como Diego siguen
enganchados a la versión Trunk (versión “Laboratorio2014”) de la base de conocimiento.
Cuando alguna persona quiera obtener la versión congelada del producto
“Laboratorio2014 1.0” simplemente tiene que seguir los mismos pasos que siguió Diego en
el Paso 2, pero en vez de seleccionar la versión Trunk, debe seleccionar la versión
“Laboratorio2014 1.0”.
 A continuación cierre sesión. Para hacerlo localice el nombre del usuario Mary en la parte
superior derecha de la pantalla y seleccione “Sign out”.

Como ya dijimos Diego y Mary siguen enganchados a la versión Trunk, entonces ya están
en condiciones de comenzar a agregar nuevas características a la aplicación, sin afectar a la
versión liberada del producto.
Mary ahora quiere agregarle al producto la transacción Docente. De igual forma que en el
Paso 3:
 Abra el IDE plateado y cree la transacción Docente para que quede de la siguiente forma
Luego siga los pasos ya conocidos para publicar el cambio realizado
 En la pestaña “Commit” en “Team Development” añada el comentario “Se añade la
transacción Docente” y haga click en “Commit”.
De esta forma podemos seguir implementando cambios y trabajando para la versión 2.0
de nuestro proyecto “Laboratorio2014”.
Ahora supongamos que como todo desarrollo de software, el mismo puede contener
errores, algunos de los cuales no pueden esperar a la finalización de la versión 2.0 del
producto, por lo que tendremos que liberar una versión que llamaremos ‘Hot Fixes’.
¿Cómo podemos arreglar un error en el producto liberado sin tener que deshacer todos
los cambios que ya hice para la versión 2.0 del producto? La solución es muy sencilla. Para
esto Mary debe realizar lo siguiente:

 Abra nuevamente el navegador, vaya a la consola de GeneXus Server y autentíquese con el
usuario mary.
 Abra la base de conocimiento “ Laboratorio2014” y seleccione del menú principal la opción
“Versions”, como vimos anteriormente
 Pase el mouse sobre la versión congelada “Laboratorio2014 1.0” y expanda el menú a la
derecha.
 Seleccione la opción "New Version", asígnele el nombre “Laboratorio2014 1.0HF” 5
y haga
click en “OK” para confirmar
Con esto hemos creado una nueva versión a partir de la que habíamos congelado, en la
que sí podremos introducir cambios y no nos veremos afectados por todo lo que se haya
implementado post-liberación en la versión principal.
Imaginemos que el error encontrado es que el atributo SalonColor de la transacción Salon
debe ser de tipo Character(40) y no Character(20), como lo es en la versión liberada.
HF es la sigla Hot Fix, ya que esta nueva versión solo contiene cambios que no pueden
esperar a la nueva liberación del producto.

Diego es la persona encargada de reparar dicho error, pero recordemos que la copia local
que tiene Diego está sincronizada con la versión Trunk de la base de conocimiento y no
con la versión creada para realizar los Hot Fixes.
Lo que se debe hacer para que Diego trabaje sobre la versión que corresponde es lo
siguiente:
 Abra el IDE azul, seleccione “File” / “Close Knowledge Base”
 Luego seleccione “File” / “New” / “Knowledge Base from Server”
 Complete el diálogo de “Create Knowledge Base” de igual forma que en el Paso 2 pero con
la salvedad de seleccionar “Selected versions” luego hacer click en “…” y seleccionar la
versión “Laboratorio2014 1.0HF”. Además como nombre a la nueva copia local ingrese
“Laboratorio2014DiegoHF” como se ve a continuación:
Con esto, Diego ya tiene una copia local de todas las versiones, que le permitirá introducir
nuevos cambios.
 Edite la transacción Salon de la siguiente manera (cambie por Character(40) el type del
atributo “SalonColor”) y guárdela:
 Luego en la pestaña “Commit” de “Team Development” añada el comentario “Se arregló un
error en el tipo del atributo SalonColor de la transacción Salon” y haga click en “Commit”.

Con esto hemos arreglado el error en la versión “Laboratorio2014 1.0 HF”. Ahora
supongamos que es un arreglo que también queremos que quede para la versión 2.0 de
nuestro producto. ¿Cómo podemos pasar el arreglo a la versión Trunk sin tener que editar
el arreglo manualmente?
 En el IDE azul cierre la base de conocimiento (“File” / “Close Knowledge Base”)
 Abra la base de conocimiento “Laboratorio2014_Diego” la cual corresponde a la copia local
de la versión Trunk de Diego (utilice la “Start Page”6
)
 Vaya a la pestaña “History” de “Team Development”
 Seleccione la versión “Laboratorio2014 1.0HF” (que fue donde se hizo el arreglo).
Encuentra las versiones en el combo arriba a la izquierda
Para abrir la base de conocimiento Laboratorio2014Diego puede ir a la Start Page y hacer
click directamente para abrirla.

 Allí se listarán todos los commits realizados en dicha versión. Haga click derecho sobre el
commit que dice “Se arregló un error en el tipo del atributo SalonColor de la transacción
Salon” que tiene el arreglo que queremos pasar y seleccione “Bring Changes”
 Finalmente haga click en el botón “Merge Selected” y quedará el cambio realizado en la KB
local de Diego
 Para efectivamente pasar el cambio a la versión Trunk debería hacer el commit
correspondiente
GXserver administra y centraliza las diferentes versiones de un
mismo proyecto, permitiendo congelar el estado de una versión en
cualquier momento, crear nuevas líneas de desarrollo, y pasar
fácilmente cambios entre versiones.
Con esto finalizamos el laboratorio de GeneXus Server 2014, esperando que hayan
quedado claros los conceptos vistos en el mismo: publicar una base de conocimiento, crear
una base de conocimiento a partir de una publicada anteriormente, publicar cambios
locales, obtener los cambios publicados por los demás desarrolladores, resolución de
conflictos en las operaciones básicas, ignorar objetos que no quiero publicar, crear
versiones, realizar cambios en distintas versiones de una misma base de conocimiento y
pasaje de cambios publicados entre las distintas versiones.
¡Gracias por participar!
Por más información acerca del producto visite www.GXserver.com.
Por documentación detallada sobre el producto visitar la categoría de GeneXus Server en
el Community Wiki

http://wiki.gxtechnical.com/commwiki/servlet/hwiki?Category%3AGeneXus+Server+X+Evolu
tion+3,.

GXServer Lab

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (6)

Semelhante a GXServer Lab

Semelhante a GXServer Lab (20)

Mais de GeneXus

Mais de GeneXus (20)

Último

Último (20)

GXServer Lab