Mejoras en el sistema de merge (usabilidad, Cherry Picking,...)

18:15 1 Comments

En las últimas releases se ha trabajado en mejorar el sistema de merge. Se ha buscado que sea más rápido, más efectivo y que de más información útil para el usuario (que contribuidor/es lo ha modificado, porque se ha descartado), siempre hay que mejorar, uno no se puede quedar estancado.

Pero no solo hay que mejorar las cosas, sino cambiarlas, adaptarlas. Tras observar la diversidad de patrones de SCM aplicados durante el desarrollo, se ha optado por ampliar las posibilidades de merge y de esta manera facilitar o tratar de ayudar en un patrón distinto al de rama por tarea que se propone.

Hasta ahora el comando de merge permitía incorporar los cambios realizados en una rama en el espacio de trabajo. A la hora de hacerlo se podía mezclar el último contenido de la rama o bien el contenido de la rama que hubiese sido etiquetado. Todo ello estaba orientado a facilitar el trabajo cuando se usaba el patrón de rama por tarea. A partir de ahora como origen del merge también se podrá elegir un changeset, una etiqueta o una revisión concreta.

Con todo, la forma de entender el merge como la mezcla del contenido del origen con el contenido del destino seguía siendo la misma. Para tratar de dar un mayor número de posibilidades se introdujo la posibilidad de realizar el merge no sólo con el contenido de la revisión, sino que también hacerlo con el cambio concreto introducido en una revisión (cherry picking) o de los cambios introducidos por un intervalo de revisiones.

El cherry picking es un merge mediante el cual un cambio (delta) introducido por una revisión es aplicado en el espacio de trabajo. Aunque está operación no suele ser muy común, dado que normalmente lo que se quiere es incorporar todo el contenido (la suma de todos los cambios que sufrió el origen), aunque en ocasiones incorporar sólo el último cambio puede resultar de utilidad.

Pongamos un escenario donde el cherry picking puede ser de gran utilidad. En una rama se está añadiendo nueva funcionalidad y durante el proceso se ha corregido un error, puede darse el caso de queramos incorporar esa corrección de error pero no la nueva funcionalidad en ese caso se usuaria el cherry picking.

Concretando tenemos una clase en la que hemos añadido varias propiedades y métodos, y posteriormente hemos corregido un pequeño error. Cuando se haga el cherry picking de la revisión (o changeset) que corrige el error como resultado se incluirá la corrección de ese error pero no la funcionalidad que había sido añadida previamente, la cual puede estar incompleta, sin probar, etc.

El caso de hacer el merge de un intervalo de revisiones extiende el concepto del cherry picking permitiendo incluir no sólo un cambio sino todos los cambios que se han realizado entre dos revisiones de un mismo elemento.

Aun así para realizar todas esto es más aconsejable crear una rama nueva que permita aislar el cambio tranquilamente de forma que la trazabilidad del mismo y su aislamiento sea mayor. Pero en caso de no querer realizar ramas para este tipo de cosas el cherry picking puede ser de gran utilidad.

1 comentarios:

SQL Server Intercalaciones (Collation)

19:14 3 Comments

Está palabra tan enrevesada es la empleada por Microsoft para definir como se ordenan y comparan las cadenas en los diferentes idiomas. Este punto, por el que se suele pasar muy por encima, es muy importante si se pretende usar SQL Server como backend en una aplicación con soporte para todos los idiomas (al menos en la información que se guarda como es nuestro caso).

El saber que palabra es igual a otra, o cual va antes que otra (alfabéticamente) puede parecer una cosa sin importancia y bastante trivial, en nuestro caso puede ser, pero en el resto de los idiomas no es así. Por ejemplo el Japonés emplea tres alfabetos diferentes, y tiene unas reglas bastante complejas para determinar que carácter va antes y cual después. Es más, inclusive dentro de un idioma como el nuestro existen diferentes criterios para ordenar como puede ser que la combinación de letras “ch” se coloque después de la letra c.

Las intercalaciones permiten definir el idioma, así como una serie de criterios adicionales que se aplican a la hora de diferenciar y ordenar diferentes caracteres. En SQL Server 2005 los idiomas soportados son los mismo que se soportan en los sistemas operativos Windows. Aparte del idioma entre los otros criterios que pueden especificarse son:
  • Permite diferenciar entre mayúsculas y minúsculas (CS Case Sensitive – CI Case Insensitive).
  • Permite diferenciar entre una misma letra acentuada o sin acentuar. (AS Accent Sensitive – AI Accent Insensitive).
  • Permite diferenciar entre las sílabas japonesas katakana e hiragana (KS Kana Sensitive – KI Kana Insensitive).
  • Permite distinguir la representación lógica de los caracteres para poder compararlos como iguales o diferentes desde su ancho (byte), sin importar que sean el mismo carácter (WS Width Sensitive – WI Width Insensitive).

La intercalación puede definirse a diferentes niveles según nos interese en cada caso. Puede definirse a nivel de servidor de BD, a nivel de la BD, a nivel del campo de texto dentro de la tabla o nivel de la consulta. Al margen del primer caso que es para tener una política general para todas ellas, las otras se aplicarían una u otra según nuestras necesidades:
  • Si se aplica a nivel de BD no solamente los datos tendrán en cuenta estos criterios sino los nombres de tablas, campos,..
  • Si se aplica a en los campos de texto dentro de las tablas lo podríamos hacer o para todos los datos o sólo para algunos, pero en cualquier caso los nombre de los elementos de la BD no se verían afectados.
  • Si se aplica en las consultas, ese criterio sólo se aplicaría en esa consulta concreta, puede ser interesante para permitir hacer búsquedas al usuario sin tener que preocuparse de mayúsculas, acentos, etc, inclusive que el mismo lo defina en el momento de hacer la consulta (opciones de la búsqueda).
En cualquiera de los casos COLLATE seguido de la intercalación que se quiera utilizar.

3 comentarios: