IDisposable Thoughts

Honey… where is my coding t-shirt?

Hey there! Thanks for dropping by Theme Preview! Take a look around
and grab the RSS feed to stay updated. See you around!

Posts Tagged ‘version control’

Como muchos recordaran, por iniciativa de los líderes de Alt.Net hispano se comenzó un proyecto desde cero, el proyecto Vale, una plataforma de validación que muestra y pretende enseñar la mística de como contribuir a proyectos OSS y usar Test Driven Development como herramienta de diseño y uso. Algo que suele preguntarme la gente es “quiero contribuir y aprender pero… ¿y por dónde comienzo?" bien, a manera de ejemplo decidí crear un pequeño screencast sobre como contribuir con una feature nueva al proyecto, desde su concepción hasta enviar nuestros cambios al repositorio. Es mi primer “screencast”, así que con gusto escucho sugerencias :)

Contribuyendo al proyecto Vale from Cristian Prieto on Vimeo.

Cambiando el usuario de un commit en Mercurial

Hoy mi gran amigo José Romaniello (@jfroma) me abarcó con una pregunta acerca de Mercurial un poco curiosa pero bastante bien fundada:

Por un error anterior, necesito cambiar el nombre de usuario que aparece registrado en algunos commits de mi repositorio de Mercurial por otro usuario, cómo puedo hacerlo? ¿tengo que reescribir la historia del repositorio?

Digamos que al principio de mis commits utilizaba el nombre de Santa Clos (digamos que así estaba la máquina con que comencé a trabajar el proyecto) y luego decidí cambiar el nombre a mi correcto nombre de Cristian Prieto, bueno, si vemos el log de commits tendremos algo como lo siguiente:

Powershell-2010-07-06_19.20.15

Bueno, si quieren pueden intentar cambiar la historia con Hg mq, pero una manera mucho más sencilla si tienen su historial local es usar a nuestro amigo “Convert”.

Algunos creen que convert (la cual es una extensión de Mercurial incluida en la instalación) simplemente sirve para convertir de un sistema de control de versiones a otro (entiéndase de Subversion a Mercurial, como nos lo muestra nuestro amigo Fabio), la verdad también nos permite convertir de un repositorio de Mercurial a otro, y en el transcurso de la conversión cambiar los valores de cada uno de los commits, entre ellos, el author del commit. En este caso en particular basta con crear un archivo “authors” que contenga la lista de valores de conversión de los autores, es un simple archivo de texto con retorno de carro. En este caso tendremos un archivo con este simple contenido:

Santa Clos <santa@northpole.net>=Cristian Prieto <me@cprieto.com>

Ahora asegurémonos que tenemos nuestra extensión convert activada, revisen que en su Mercurial.ini tengan la siguiente línea

[extensions]
hgext.convert=

Y basta solamente convertir nuestros repositorios

hg convert --authors authors.txt orig changed

Bien, ahora si revisamos el historial nos quedaría bello, como esperábamos :)

Powershell-2010-07-06_19.28.20

Para saber un poco más acerca de convert, basta con la página del wiki de Mercurial :)

Mercurial as a Git client

Days ago I just published a short blog post about using Mercurial as a SVN Client, I know, Subversion is the “now-legacy-vcs-system” and Git with Mercurial are the “cool kids” in the school, why not make them work together?

Well, in the same way we could make Subversion works with Hg (using extensions of course) we could make Git works with Mercurial. It requires a little more work in Windows but it stills easy to do. As usual we start with a TortoiseHg installation. I will try to show its installation in a short set of steps:

  • We need to activate the Mercurial Bookmark and rebase extensions (these extensions are included with standard Mercurial installation). Edit your mercurial.ini file and add the following to the [extensions] section
  • [extensions]
    rebase =
    hgext.bookmarks = 
  • HgGit needs a special python library to handle Git repositories, this library is named dulwich. You need to get it from its source repository, clone it in some directory

    hg clone http://bitbucket.org/abderrahim/dulwich
  • Now we need to get the HgGit source code from its repository, let’s clone it from repository

    hg clone http://bitbucket.org/durin42/hg-git
  • This is the hard part, we need to tell to HgGit the location where the dulwich library is installed. Remember, both HgGit and dalwich are Python libraries, so we’ll edit just a file to show where to get dalwich. Go to the place you cloned HgGit search and open the file __init__.py and add look for the following code and add the code highlighted
    import os
    
    # NOTE: Added for tortoisehg compatibility
    import sys
    sys.path.append('write here the directory where dulwich was cloned')
    
    from mercurial import commands, extensions, hg, util as hgutil
    from mercurial.i18n import _
  • Now let’s activate the extension, open again your mercurial.ini file and add the following line to your [extensions] section

    hggit = directory where hggit where cloned\hggit

And that is all, just test your extension installation with hg help extensions And look for hggit

Now you can clone, rebase, push, pull and do whatever you do with mercurial but using remote git repositories, for example, now you can do something like

hg clone http://github.com/castleproject/Castle.Core.git castle

I hope this guide could help you to get more fun from Mercurial, see you later!

Mercurial as a SVN client

Our friend Fabio Maulo published a few days ago about converting Subversion repositories into Mercurial, so in that way we could “rid off” svn repositories and move into Mercurial. Well, I must admit, I love mercurial from first sight, but sometimes you could not afford transform the whole SVN repository, sometimes (probably because you are working on a client’s repository) you need to keep using Subversion as your main development repository but you will like to work with Mercurial as a SVN client (like a lot of people do using Git and Git-Svn).

As many of you remember, one of the biggest mercurial’s strong points is the support for extensions. There are extensions for almost anything, and all of them are written in Python language (an easy and very powerful programming language). There is a project named Hg-Svn, which allows us to use Mercurial as a Subversion client, treating our Subversion repository as a remote Mercurial repository, in that way we could use hg common remote operations (like push, pull, fetch).

Install it in Windows could become cumbersome, mainly because it is only available as Python source code and many Hg users in Windows doesn’t have a python interpreter. I will publish the easiest way to do it in Windows

  • Install TortoiseHg (if you don’t have installed already)
  • Enable rebase extension in your mercurial.ini (rebase = )
  • Fetch Hg-Svn source code from Bitbucket repository (http://bitbucket.org/durin42/hgsubversion) do it into a known directory.
  • Modify your mercurial.ini file and add svn as an extension, pointing it to the place you got hgsubversion, for example
    • svn = d:\src\hgsvn\hgsubversion
  • Done!, just test your configuration with hg help extensions and look for svn

Use the extension is really easy, just clone from a subversion repository as you would do from a Mercurial repository.

hg clone svn+http://svn.caffeine-it.com/openrasta/ openrasta

And, of course, you may send your changes as you would do with a remote repo

hg push

If your changes creates a new head into your local hg repository, when you push to Subversion repository it will automatically rebase your head into subversion head, remember, subversion is a linear source control system.

Well, I hope it will help you to get more fun with your mercurial installation :)

Review, RedGate SQL Source Control

Una de las preguntas que suelo escuchar varias veces cuando converso con varios grupos de desarrollos a los cuales se integra el DBA es la siguiente: “¿Y cómo hago para controlar los cambios o agregar los cambios de la base de datos en el sistema de control de versiones”? Bueno, en cierta manera lo comprendo, llego a tal punto de decir que si no esta en el repositorio de versiones entonces no ha sido hecho.

Red Gate me sorprende con una nueva herramienta que nos puede ayudar a controlar este pequeño problema, Red Gate SQL Source Control, un sistema de control de versiones que permite versionar una base de datos SQL Server y agregar su esquema a un repositorio de Subversion junto con el código fuente. Al principio me parecía algo extraño y hasta bizarro, pero luego de usarlo un tiempo hasta me terminó gustando :)

El Red Gate SQL Source Control se integra al SQL Server Management Studio (creo que soporta la versión express, pero no estoy para nada seguro). El versionar la base de datos es sumamente fácil, la seleccionamos, “linkeamos” la base de datos a un directorio de un repositorio ya existente (aunque permite crear un repositorio nuevo para la base de datos) y escogemos luego que objetos agregar al repositorio :)

La versión actual de Red Gate SQL Source Control se encuentra en Early Access y puede ser bajado al instante con sólo registrarse en la página.

Hay ciertos criterios que debemos tomar en cuenta:

  • No es posible hacer revert a un cambio ya existente (o por lo menos no he encontrado dónde hacerlo) NOTA: la versión 2.1 agregará soporte para Revert
  • En la versión EA actual solo hay soporte para Subversion, el próximo EA soportará TFS (no Git, no Vault, no Hg por el momento)
  • El equipo de Red Gate esta buscando feedback para mejorar la herramienta, algo sumamente positivo a mi parecer.

Resumiendo, RedGate SQL Source Control es un gran paso hacia la integración del control de versiones de nuestra base de datos a nuestro repositorio de código, un paso positivo. Le doy 9 estrellas de 10 :)

Pueden suscribirse al programa de Early Access y bajar el instalador del siguiente link http://www.red-gate.com/products/SQL_Source_Control/index.htm

Saludos!

Subversion es un excelente sistema de control de versiones centralizado (VCS) de código abierto ampliamente utilizado alrededor del mundo no sólo por los desarrolladores sino también por diversas personas que lo usan para mantener un control de cambios en sus documentos varios.

Es común para un usuario de Subversion utilizar el famoso cliente TortoiseSVN para manejar sus directorios de trabajo actuales conectados a un repositorio de Subversion. Como algunos se habran percatado, Subversion crea directorios “ocultos” .svn donde contiene la metadata necesara para trabajar de forma desconectada al repositorio, a veces estos directorios pueden llegar a ser un poco “irritantes” y necesitamos deshacernos de ellos. Recientemente un amigo me llamó con el siguiente problema:

Tengo un problema, el repositorio original no existe, por lo tanto no puedo hacer el “export” de TortoiseSVN de mi repositorio para deshacerme de los directorios .svn, necesito enviarle el código fuente a un cliente pero no quiero enviarle los .svn, ¿cómo hago para deshacerme de ellos? la estructura de directorios es muy compleja por lo que navegar uno a uno y quitarlos es un poco tedioso.

Es ahí cuando sale a la luz nuestro viejo amigo la línea de comando, no es nada que un simple script de Cmd o PowerShell en Windows no pueda resolver. Comencemos con el viejo y ya casi obsoleto Cmd:

for /r %%f in (.svn) do rd /s /q "%%f"

En PowerShell es un poco más complejo, pero igual se puede lograr :)

get-childitem -Include .svn -Recurse -force | Remove-Item -Force –Recurse

Obviamente, cualquiera de los dos comandos deben correrse en el directorio que queremos limpiar.

Saludos!

UPDATE: mi amigo jfroma me sugiere el uso de SVN Export para lograr lo mismo, bueno, recordemos que SVN Export es una operación conectada de Subversion, eso indica que debemos tener conexión al repositorio para efectuarla. Como expongo en mi caso, mi amigo no tiene acceso al repositorio original (para ser exacto según me contó fue borrado), he ahí porqué no podemos usar Export y debemos recurrir a otras “técnicas” tibetanas para lograrlo.