2009-04-14 10 views
8

He sido extremadamente travieso. He estado desarrollando una pieza de software (soy el único desarrollador) por un tiempo (O.K., es en el transcurso de algunos años), pero no he usado ningún tipo de control de fuente.¿Cómo convierto copias de seguridad de proyectos simples no controladas por código fuente en un repositorio git versionado?

He decidido utilizar el control de código fuente (parece más probable que git, ya que las herramientas de Windows parecen haber aparecido mucho en los últimos meses) a partir de ahora. Lo que sí tengo son copias de seguridad fechadas de todo el directorio de mi solución (.NET).

Lo que me gustaría hacer es automágicamente tener mis copias de seguridad visibles en el historial de revisiones. Será desordenado Los proyectos y archivos se agregarán/eliminarán en el transcurso del historial de soluciones. No me molestan estos problemas, como lo que sé que los archivos renombrados se interpretan como la eliminación de un archivo y la adición de uno nuevo, no relacionado.

De manera más general, mi problema es: tengo pedidos de copias de un directorio cambiante. Importar el primero en git es fácil, supongo. Pero, entonces, quiero que todas las copias posteriores del directorio se combinen, en orden de fecha, de a una por vez sin que tenga que enviar cada subdirectorio y archivo individualmente.

¿Es esto posible, o es solo que me castigan por no usar el control de fuente desde el principio?

Editar: Si sigo adelante con el método 'commit all snapshots individual' manualmente (hay menos de 20 instantáneas), ¿hay alguna manera (como Esko Luontola sugiere que yo desee) de anular las fechas de confirmación con el fechas que tengo para la instantánea. git commit no parece tener una bandera para permitir esto. ¿Hay alguna otra forma (estoy usando Vista)?

Editar: En respuesta a mi problema de utilizar las fechas originales: Debe establecer las variables de entorno GIT_AUTHOR_DATE y/o GIT_COMMITER_DATE para anular el uso de las fechas y horas actuales al realizar la confirmación.

La razón por la que hay dos conjuntos de variables (también hay GIT_ (AUTHOR | COMMITER) _ (NAME | DATE | EMAIL)) es para distinguir entre, por ejemplo, el autor que envía un parche y el mantenedor que está en realidad haciendo los commits en el repositorio.

Nota si se usan extensiones git en VS: si establece (export varname = "value") estas variables usando la línea de comando 'git bash', y luego vuelve a la GUI para hacer un commit, parece ignorar ellos. Tienes que mantenerte en la línea de comando y ejecutar 'git commit' desde allí.

+0

¿Te gustaría tener también las fechas reales en el repositorio de Git? Al menos hicieron algo así cuando movieron 20 años de historia de Perl a Git: http://github.com/blog/276-perl-mirror-on-github –

+0

No es relevante: mover el historial de Perl a Git fue importar desde Perforce –

Respuesta

5

Puede haber una forma automatizada de hacer esto, pero git debe ser lo suficientemente inteligente como para dejar git init en su copia de seguridad más antigua y luego copiar repetidamente la carpeta .git para copias de seguridad incrementalmente nuevas y crear una confirmación con todo para cada una. Scripting esto debería ser bastante fácil.

Mejor aún, podría pasar una variable de entorno --git-dir= o $GIT_DIR a git y hacer que utilice un repositorio, guardando el paso de copiado.

Algo como esto:

cd $FINAL_DIR 
git init 

export GIT_DIR=$FINAL_DIR/.git 

cd $NEXT_BACKUP 
git add -A . 
git commit 
# rinse and repeat 
+0

Sugeriría usar "git add -A." y no dar "-a" a cometer git, parece un poco más claro ... si su versión de git add admite -A, eso es. Alternativamente, "git add". seguido de "git add -u" (para rastrear archivos nuevos y eliminados). – araqnid

3

yo no sé muy bien por qué no quiere simplemente cometer todas las instantáneas de forma individual. Quiero decir, un script de shell (o Perl, Python, Ruby, Tcl, lo que sea) para hacer eso, es probablemente menos de 5 líneas de código y menos de 10 minutos de trabajo.

Además, existe git load-dirs, que le permitiría reducirlo a tal vez 3 líneas y 5 minutos.Pero todavía tienes que cargar cada dir indvidually.

Pero, si así lo desea, existe la herramienta git fast-import que está destinada a facilitar la escritura de convertidores e importadores de repositorios. De acuerdo con la página de manual, puede escribir un importador en aproximadamente 100 líneas y un par de horas.

Sin embargo, todo esto pasa por alto el problema más grande: el valor de un VCS se encuentra no en el contenido - sólo así podría utilizar copias de seguridad periódicas para que - pero en los mensajes de cometer. Y ninguna herramienta mágica te va a ayudar allí, tendrás que escribirlos todos en ti mismo ... y lo más importante, tendrás que recordar exactamente por qué hiciste cada pequeño cambio en los últimos años.

+1

Hay ejemplos de scripts de importación rápida en contrib/fast-import /, que incluyen import-zips.py (en Python) e import-tars.perl (en Perl). –

+1

-1 No creo que esta respuesta sea útil, es como "amigo, eres un idiota, es tan fácil, hazlo, puedo hacerlo en 2 minutos con los ojos cerrados" – hasen

7

Puede utilizar herramientas basadas ejemplo git-fast-import distribuidos en el repositorio git.git: import-zips.py(en Python) o import-tars.perl(en Perl) o utilice los script como base de su propio guión de importación. Puede encontrar esos scripts en el directorio contrib/fast-import/.

Cuestiones relacionadas