git
git clone --bare <URL-GIT-OLD>
cd <PROJECT>

Comprueba que están bien los datos de todos los desarrolladores:
git shortlog -e -s -n

Corrige con el siguiente script la información que pudiera estar mal:

git-author-rewrite-multiple.sh
————–
#!/bin/sh

for email in user1@olddomain.com user2@olddomain.com
do
git filter-branch -f --env-filter '

OLD_EMAIL="'${email}'"
CORRECT_NAME="'${email%%@*}'"
CORRECT_EMAIL="'${email%%@*}'@newdomain.com"

if [ "$GIT_COMMITTER_EMAIL" = "$OLD_EMAIL" ]
then
export GIT_COMMITTER_NAME="$CORRECT_NAME"
export GIT_COMMITTER_EMAIL="$CORRECT_EMAIL"
fi
if [ "$GIT_AUTHOR_EMAIL" = "$OLD_EMAIL" ]
then
export GIT_COMMITTER_NAME="$CORRECT_NAME"
export GIT_AUTHOR_EMAIL="$CORRECT_EMAIL"
fi
' --tag-name-filter cat -- --branches --tags; echo "done for ${email}"

done
————–

git push --mirror <URL-GIT-NEW>
cd ..
rm -rf <PROJECT>

Algunos enlaces de interés
Duplicating a repository
list authors of a git repository including commit count and email
Changing author info

Anuncios

git
sudo apt-get install git-svn
Descargar: svn-migration-scripts.jar


java -jar svn-migration-scripts.jar authors <URL-SVN> > authors.txt
git svn clone --prefix="" --stdlayout --authors-file=authors.txt <URL-SVN>
cd <PROJECT>
java -Dfile.encoding=utf-8 -jar ../svn-migration-scripts.jar clean-git --force
git remote add origin <URL-GIT>
git push -u origin --all
git push --tags

vía

Estructura general

svn

  • En el trunk avanza el desarrollo de las nuevas versiones (1.0.0-SNAPSHOT).
  • En un momento dado se da por finalizado el desarrollo de dicha versión.
  • A partir de este estado se crea una rama para el mantenimiento de dicha versión (1.0.x).
  • En el trunk se actualiza la versión para que pueda comenzar la nueva iteración de desarrollo con nueva funcionalidad (1.1.0-SNAPSHOT).
  • En la rama se fija el número de versión final (1.0.0).
  • Una vez fijado el número de versión, se etiqueta (1.0.0) y esta versión será susceptible de ser instalada.
  • Una vez etiquetada la versión (1.0.0), en la rama de mantenimiento, se actualiza el número de versión para el desarrollo de los posibles correctivos (1.0.1-SNAPSHOT).
  • En cierto momento, se aplican cambios correctivos y se decide que la versión de mantenimiento está lista.
  • En ese momento se fija el nuevo número de versión (1.0.1).
  • A partir de este estado se etiqueta la versión (1.0.1).
  • Una vez etiquetada la versión (1.0.1) se actualiza el número de versión de desarrollo del mantenimiento (1.0.2-SNAPSHOT).
  • El proceso se repite tantas veces como sea necesario.

Lee el resto de esta entrada »

git

Usar múltiples cuentas con repositorios remotos puede resultar complicado.  En esta entrada explico cómo podemos conseguir que Git utilice la clave SSH correcta para el repositorio en el que estemos trabajando.

Creación de diferentes claves públicas

Para generar una clave nueva ejecutaremos el siguiente comando:

$ ssh-keygen -t rsa -C "your_email@youremail.com" -f "your_user_id_file"

La opción -C es un comentario para ayudar a identificar la clave.  La opción -f especifica el nombre del fichero.

En el ejemplo, crearemos 2 claves que debemos guardar en el directorio ~/.ssh/:

~/.ssh/id_rsa_user1
~/.ssh/id_rsa_user2

Una vez creadas, las añadiremos al anillo de claves del agente SSH de autentificación ejecutando los comandos:

$ ssh-add ~/.ssh/id_rsa_user1
$ ssh-add ~/.ssh/id_rsa_user2

NOTA: Podemos eliminar todas las claves anteriormente cacheadas mediante el comando:

$ ssh-add -D

Finalmente podemos comprobar las claves almacenadas mediante el comando:

$ ssh-add -l

Importación de la clave pública en GitHub

Debes importar la clave púbica generada anteriormente en su cuenta GitHub asociada.

Consulta la documentación de GitHub para ver cómo hacerlo.

Configuración de SSH

En el directorio ~/.ssh/ crearemos un fichero llamado config:

$ cd ~/.ssh/
$ touch config

He introduciremos un contenido similar a este:

#user1 account
Host github.com-user1
	HostName github.com
	User git
	IdentityFile ~/.ssh/id_rsa_user1

#user2 account
Host github.com-user2
	HostName github.com
	User git
	IdentityFile ~/.ssh/id_rsa_user2

Clona tu repositorio y modifica su configuración Git

Clona tu repositorio git

$ git clone git@github.com-user1:user1/your-repo-name.git

Si ya tenías una copia local será necesario que actualices el origin:

$ git remote set-url origin git@github.com-user1:user1/your-repo-name.git

Ahora ve al repositorio Git local que quieres configurar y ejecuta:

$ git config user.name "user1"
$ git config user.email "user1@example.com" 

o puedes tener tu configuración git global:

$ git config --global user.name "user1"
$ git config --global user.email "user1@example.com"

Repite el proceso con el otro usuario y su repositorio.

A partir de aquí, podemos usar el flujo normal para publicar nuestro código

$ git add .
$ git commit -m "your comments"
$ git push

vía

Subversion Logo
Tipos de merge:

  • sync o catch-up: un merge que introduce en la rama destino todos los cambios de la rama fuente que “todavía no tenemos” en la rama destino.
  • cherry-pick: un merge que introduce un o más cambios específicos de la rama fuente en la rama destino.
  • reintegrate: similar a un sync merge, pero pensada para ser utilizada en la otra dirección.

Asumamos un orden parcial entre branches, de tal modo que cada branch tiene (0 o más) Feature Banches que son menos estables que ella, y Release Branches que son más estables que ella, y ella se considera el padre de cada una de estas. Un merge se puede realizar entre una branch padre y uno de sus Feature o Release branches inmediatas, y en ninguna otra parte.

  • Un merge a una Feature Branch desde su padre normalmente es un catch-up.
  • Un merge desde una Feature Branch a su padre normalmente es un reintegrate.
  • Un merge a una Release Branch desde su padre normalmente es un cherry-pick.
  • Un merge desde una Release Branch a su padre podría ser un catch-up o un cherry-pick. (¿Funciona un catch-up correctamente y has hecho cherry-picks en la otra dirección? Puede que no.)

Subversive Logo
Inicialmente tenía conectados en Eclipse varios proyectos con un SVN utilizando el plugin Subclipse.

Debido a unos problemas en la creación de patches, tuve que cambiar a Subversive.

El problema viene porque una vez eliminado el plugin de Subclise y añadido el de Subversive, la única opción que aparece al pulsar botón derecho sobre un proyecto –> Team, es “Apply Patch…

Esto es debido a que Eclipse “recuerda” que el proyecto estaba conectado al SVN usando Subclipse (que ya no está disponible) y no me permite volver a conectarlo usando Subversive.

Para solucionarlo tenemos dos opciones.

La primera opción (des-instalar/re-instalar los plugins):

  1. Des-instala Subversive
  2. Re-instala Subclipse
  3. Verifica que los proyectos están conectados al SVN
  4. Botón derecho sobre el proyecto –> Team –> Disconect. Asegúrate de marcar “Do not delete the SVN meta-information (e.g. .svn subdirectories).
  5. Des-instala Subclipse
  6. Re-instala Subversive
  7. Botón derecho sobre el proyecto –> Team –> Share Proyect…

La segunda opción (si no quieres des-instalar/re-instalar):

  1. Crea un nuevo workspace vacío
  2. Abre Eclipse utilizando dicho workspace
  3. File –> Import –> General –> Existing Projects into Workspace
  4. Selecciona el proyecto del viejo workspace
  5. Botón derecho sobre el proyecto –> Team –> Share Proyect…

vía

git
Si no entiendes las motivaciones que hay detrás del diseño de Git, eres candidato a vivir un mundo de penurias. Con suficiente empeño puedes forzar a Git a actuar del modo que tú crees que debería hacerlo en vez del modo en que él quiere hacerlo. Pero eso es como usar un destornillador como si fuera un martillo; hace el trabajo, pero lo hace mal, lleva más tiempo, y estropea el destornillador.

Lee el resto de esta entrada »

A %d blogueros les gusta esto: