Git para ‘pobres’: Usar Dropbox como repositorio de código

En el Tutorial 54 vimos como usar Subversion para nuestro control de código, usando para ello un repositorio de  Google Code y u como control de código el AnkhSVN 

Tal y como explicabamos en el tutorial anterior, a parte de subversion, existen otros métodos para gestionar nuestro código. Habiamos comentado Mercurial y Git como otros métodos. Hoy precisamente hablaremos de Git, que es sin duda una de las formas más ‘populares’ de controlar nuestro código.

Además, también comentamos en el Tutorial 54 que al usar Google Code como repositorio, nuestro código tiene que ser público. Que nuestro código sea público no es fáctible en determinados casos (programas de empresa, programas de código cerrado, etc).

En la actualidad hay varios ‘proveedores de repositorios de código’ muy populares: SourceForge, GitHub y Bitbucket.

Hablando siempre de repositorios gratuitos, tanto SourceForge como GitHub obligan a que el código sea público. Bitbucket sin embargo permite gestionar repositorios privados de código (si, incluso con cuentas gratuitas). Además, Bitbucket permite crear repositorios para "equipos de desarrollo" de hasta 5 desarrolladores (hasta un total de 8 desarrolladores con un sistema de invitaciones)

Sobre Bitbucket hablaremos en próximas entregas: Configurar una cuenta, el sistema Git y Visual Studio (incluida las versiones "Express")

La entrega de hoy básicamente explicará como instalar Git y como usar una carpeta de Dropbox para hacer "push" y tener una "copia de nuestro código en la nube".

Antes de empezar decir que no soy ni de lejos un experto en  Git y que usar Dropbox no es la mejor forma de usar Git, sobre todo en desarrollos con varios desarrolladores, valga la redundancia, sin embargo, para desarrollos pequeños/individuales va de fábula, tal y como veréis.

Instalación de Git

Lo primero que tenemos que hacer es instalar Git. Desde la página oficial podemos acceder a la descarga. A fecha de hoy la versión que he usado es la 1.7.11-preview20120710.exe Hay una versión 1.8.0 que está recién subida. 

La instalación no tiene mucho misterio. Dejáis las opciones por defecto. Sin embargo en la siguiente pantalla es muy recomendable usar la opción Run Git from the Windows Command Prompt:

Al finalizar la instalación tendréis dos programas en la carpeta "Git": Git Bash (consola) y Git GUI (pues GUI como indica). Además si habési dejado las opciones por defecto en la instalación, se ha integrado Git en el explorador de Windows.

 

Crear una carpeta para los repositorios en Dropbox

Accederemos a nuestra carpeta de Dropbox (que normalmente está en "Mis Documentos") y creamos una nueva carpeta donde meteremos todos nuestros repositorios de código. Yo la he llamado mygitrepos


(Haz click para agrandar)

A continuación haremos click con el botón derecho sobre la carpeta mygitrepos y veremos esto:

Como al instalar Git dejamos las opciones por defecto, tal y como hemos dicho antes, Git se integra con el explorador de Windows. Pues bien, pulsamos en Git Bash y se muestra la consola de Git ya configurada para trabajar en esa carpeta:


(Haz click para agrandar)

A continuación escribiremos en siguiente comando:

git init –bare prueba1.git


(Haz click para agrandar)

A mi repositorio lo he llamado prueba1.git Lo podría haber llamado "pepe".
Sin embargo por convenio los repositorios de Git tiene el nombre "loquesea.git"

Si accedemos a prueba.git vemos que se han creado unos archivos y carpetas:

Pues bien, la parte de Dropbox ya está finalizada.

 

Crear nuestra solución desde Visual Studio y realizar el primer "commit"

Ahora abrimos Visual Studio y creamos nuestra solución.

He metido un formulario, con un control botón que muestra un mensaje cuando se pulsa.
Aquí lo de menos es el código. Es un mero ejemplo:


(Haz click para agrandar)

Compilamos y salvamos la solución.

A continuación es importante añadir un archivo llamado .gitignore (sí, sin extensión y con el . delante) en la misma carpeta de la instalación:


(Haz click para agrandar)

El contenido del fichero .gitignore que yo he usado es el siguiente:

Thumbs.db
*.obj
*.exe
*.pdb
*.user
*.aps
*.pch
*.vspscc
*_i.c
*_p.c
*.ncb
*.suo
*.sln.docstates
*.tlb
*.tlh
*.bak
*.cache
*.ilk
*.log
[Bb]in
[Dd]ebug*/
*.lib
*.sbr
obj/
[Rr]elease*/
_ReSharper*/
[Tt]est[Rr]esult*
*.vssscc
$tf*/

Básicamente lo que hace este archivo es decirle a Git que no incluya una serie de archivos y/o carpeta en el repositorio. Esto se hace así porque cuando por ejemplo hacemos un cambio en un fichero fuente y compilamos, ha cambiado tanto el fichero fuente y el ejecutable con respecto a lo que teniamos antes. El exe no me aporta nada, por eso lo ignoro con el fichero .gitignore

Bien, nos ponemos encima de la carpeta de nuestra solución, botón derecho y pulsamos esta vez en Git Gui:


(Haz click para agrandar)

A continuación seleccionamos "Create New Repository":

A continuación con el botón Browse seleccionamos la carpeta de nuestra solución de Visual Studio:

Al pulsar en el botón Create se muestra esta pantalla:


(Haz click para agrandar)

En esta pantalla se mostrarán los ficheros que han cambiado "desde la versión" anterior.

Pulsamos en el botón Stage Changed:


(Haz click para agrandar)

Al pulsar en el botón Stage Changed observamos que todos los ficheros han pasado a la lista de abajo. Incluimos un mensaje (es siempre obligatorio) y escribimos por ejemplo Commit Inicial.

Finalmente pulsamos en el botón Commit

Al pulsar en el botón Commit han "desaparecido" todos los archivos.

Ahora vamos a configurar el "repositorio remoto" de tal forma que todos los cambios que hagamos desde Git se "repliquen automágicamente" en Dropbox. Lo que explicará a continuación solo es necesario hacerlo una vez (la primera vez).

Pulsaremos en Remote > Add…


(Haz click para agrandar)

El valor de Name también es por convenio origin
En Location especificamos la ruta de la carpeta del repositorio prueba1.git que está en Dropbox. De momento marcamos la opción Do Nothing Else Now
Y pulsamos en Add:

De vuelta a la pantalla principal de Git, pulsaremos en el botón Push:


(Haz click para agrandar)

Push lo que hace es "enviar" los datos al repositorio git remoto

Se mostrará está pantalla:

Pulsamos en Push y observamos lo siguiente:

El Push se ha completado correctamente.

 

Cambios en el código y sucesivos "Commit/Push"

Bien, volvemos a nuestra solución y cambiamos varias cosas:
(recordad que es solo un ejemplo)

1)  Cambiamos el MessageBox.Show("incial") por un MessageBox.Show("Hola Mundo")

2) Añadimos el método XXX1()

Una vez realizados estos cambios, compilamos la solución (importante)


(Haz click para agrandar)

El Git Gui sigue abierto pero no se "ve nada nuevo". Para ello, o bien pulsamos F5 o bien en Commit > Rescan:


(Haz click para agrandar)

Al hacerlo vemos que "desde la versión anterior" han cambiado 3 archivos. Y es más, en rojo se muestra lo que había antes y en verde lo que hay "de nuevo":


(Haz click para agrandar)

Pulsamos de nuevo en el botón Stage Changed y escribimos un mensaje, por ejemplo: primer cambio


(Haz click para agrandar)

Pulsamos en el Commit y luego en el Push

Al hacer un Push vemos que como la carpeta de Dropbox se sincroniza:

Y aquí ya está sincronizada:

El Push se realizó correctamente:

De vuelta a nuestra solución añadimos una nueva clase:


(Haz click para agrandar)

Y hacemos más cambios en nuestro formulario principal


(Haz click para agrandar)

De nuevo recalcar que es necesario compilar la solución antes de realizar cualquier Commit

En Git GUI pulsamos F5 y observamos los cambios:


(Haz click para agrandar)


(Haz click para agrandar)

Añadimos un mensaje y pulsamos de nuevo en el Commit:


(Haz click para agrandar)

Si no pulsamos en el Push, tendremos "Una versión local" de nuestro código "distinta a la versión que tenemos en el repositorio de Dropbox".

Desde esta opción podemos ver el historial:


(Haz click para agrandar)

Aquí vemos que la rama (branch) master del remoto origen no tiene el cambio "Añadido método P1 en la clase":

Si volvemos a la pantalla del Git GUI y hacemos el "Push", luego al entrar en el historial vemos:

Ahora si que el repositorio de la carpeta de Dropbox está actualizado

 

Clonar el repositorio de Dropbox

Llega un dia en que se te escoña el disco duro, pero dont panic: Tengo una "copia de seguridad" en un USB.

Sin embargo en dicha "copia de seguridad" es de la "versión 2.12.33.12312 y tu código acutal es la versión 3.0

Pues no hay problema, se clona el repositorio de Dropbox y en 0.0 segundos tendrás disponible la versión 3.0 de tu código.

Para ello te creas una carpeta, botón derecho y seleccionas Git Gui:

Seleccionas Clone Exisiting Repository:

Seleccionas la carpeta de Dropbox como origen del repositorio y como destino una carpeta nueva:

Clone y voila, ya tienes tu código actualizado a la versión 3.0:

Pero no sólo tienes el código, tendrás disponible todos los Commits que hayas hecho y toda la "historía" de cambios.

 

Por último mencionar que el tema de Git es bastante más complejo que todo lo explicado arriba. No en vano se utiliza este sistema en megaproyectos de software y cuando digo megaproyectos son proyectos con millones de lineas de código y con cientos de developers trabajando en el mismo desarrollo.

 

 Tags: Git & Dropbox, Git para torpes, tutorial Git, Git en Visual Studio, Desarrollo Social, Social Coding

Saludos.
mov eax,ollydbg; Int 13h

 


Ollydbg ProSignature

.NET Tutorial 55. Crystal Reports, aplicaciones x86 y Windows de 64 bits

Este es un ‘error’ que ya había detectado hace bastante tiempo. Os pongo en situación:

Cuando se desarrolla una aplicación con el target "x86", Crystal Reports "no se instala correctamente" en un sistema operativo de 64 bits. Cuando se lanza el reportviewer se obtiene una bonita excepción indicando que faltan runtimes por instalar.

La solución pasa por instalar "manualmente" los archivos CRRedist2008_x86.msi y CRRedist2008_x86_es.msi, lo cual no deja de ser un poco "cutre".

Esto es debido a un "bug" en los xml de los paquetes de instalación que usa el Project Wizard de Visual Studio.

Nota: Esto lo tengo más que comprobado con Visual Studio 2008 + Crystal Reports 10.5. No sé si con Visual Studio 2010 + Crystal Reports 13.1 ocurre lo mismo, pero en caso afirmativo, la solución es la misma.

Bien, al lio.

Lo que tendremos que hacer es acceder a la carpeta donde Visual Studio busca los paquetes para generar el fichero msi  de la instalación.

Por defecto deberían estar en esta carpeta: 

Las SKDs son:

v5.0: Para Visual Studio 2005
V6.0A: Para Visual Studio 2008
V7.0A: Para Visual Studio 2010

Supongo que el nuevo Visual Studio 2012 se instalará en v8.0A (aún no he tenido tiempo de trastear con el Visual Studio 2012, sorry 😀 )

Bien, en nuestro caso, los paquetes de instalación que el usa Visual Studio 2008 para instalar Crystal Reports están en esta carpeta:

v6.0ABootstrapperPackagesCrystalReports10_5

Aquí se encuentra el fichero products.xml que usa el Wizard del proyecto de Setup del Visual Studio para añadir los paquetes de Crystal Reports para generar nuestro msi de instalación


(Haz click para agrandar)

Lo que deberemos hacer es comentar las siguientes líneas:

<BypassIf Property="ProcessorArchitecture" Value="Intel" Compare="ValueNotEqualTo"/>
<BypassIf Property="CRVSInstalled" Value="0" Compare="ValueGreaterThan"/>

El resultado del fichero products.xml una vez realizado el cambio sería algo como esto: 


(Haz click para agrandar)

Por otro lado, también tendremos que modificar el fichero que instala los runtimes "regionalizados", en este caso los del idioma español, que se encuentran en la subcarpeta es

El fichero a modificar se llama package.xml:

El contenido del fichero es el siguiente:


(Haz click para agrandar)

Al igual que antes, debermos comentar las siguientes líneas:

<BypassIf Property="ProcessorArchitecture" Value="Intel" Compare="ValueNotEqualTo"/>
<BypassIf Property="CRVSLangInstalled" Value="0" Compare="ValueGreaterThan"/>

El resultado del fichero package.xml una vez realizado el cambio sería algo como esto: 


(Haz click para agrandar)

 

Pues bien, si ahora generas un proyecto de instalación, de una aplicación "x86" que utilice Crystal Reports en un sistema operativo de 64 bits, se instalará correctamente el rutime y ya no se producirá la excepción cuando se lance un reportviewer.

 

Aclaración final: Da igual que la "máquina de desarrollo" sea de 32 o de 64 bits. El error se produce cuando se instala una aplicación "x86" en un S.O. de 64 bits.

 

Espero que os sea útil 🙂

 

Tutoriales relacionados:
.NET Tutorial 46. Visual Studio 2010, Crystal Reports 13 y .NET Framework 3.5 SP1

.NET Tutorial 47. Visual Studio 2010, Crystal Reports y RecordSelectionFormula

 

 Tags: Crystal Reports target x86 os 64 bits, Crystal Reports error no runtime installed, Crystal Reports sistema operativo 64 bits aplicación x86

Saludos.
mov eax,ollydbg; Int 13h

 

 


Ollydbg ProSignature