Mejor sistema de control de versiones para administrar los directorios de inicio

Question

Tengo 3 máquinas con Linux, y quiero mantener los archivos punto en sus directorios de inicio en sincronización. Algunos archivos, como .vimrc, son los mismos en todas las 3 máquinas, y algunos son únicos para cada máquina.

He usado SVN anteriormente, pero todo el rumor sobre DVCS me hace pensar que debería probar uno, ¿hay algún en particular que funcione mejor con esto? ¿O debería quedarme con SVN?

Answer 1

Tuve el mismo problema y construí una herramienta encima de Subversion que agrega permisos, propiedad y seguimiento de segundo plano, mantiene los directorios .svn fuera de los árboles realmente versionados y agrega un concepto de capas para que pueda por ejemplo, rastrea todas tus configuraciones relacionadas con el desarrollo, que luego solo verificas en las máquinas que usas para desarrollarlas.

Esto me ha ayudado a organizar mi configuración mucho mejor en las más de 50 máquinas en las que inicio sesión.

Here's the project page. Todavía es un poco difícil en los bordes, pero también lo usamos en el trabajo para la configuración del sistema de versión para nuestros más de 60 servidores.

En general, cualquier sistema de control de versiones que use algún tipo de archivo de metadatos para realizar un seguimiento de las cosas le causará dolor al usarlo.

Answer 2

Cualquier DVCS probablemente funcionaría bien. Mi favorito es Bazaar. Sería más fácil mantener sus archivos de configuración en .config, la versión que, y luego symlink según corresponda.

Una de las ventajas de DVCS es que también puede versionar los archivos de configuración por máquina, sin interferir con las configuraciones globales de las versiones.

Answer 3

El software de control de versiones no es realmente ideal para directorios de inicio. Peor aún, a algunos programas realmente no les gustan las carpetas .svn o comienzan a interpretar sus contenidos. Por supuesto, podría tratar de solucionar esto con una configuración de creación de reflejos muy compleja, pero eso es difícil.

Answer 4

Aquí hay un desarrollador de Mozilla que ha intentado hacer esto: Version controlling my home dir, hay un par de sugerencias en los comentarios.

Answer 5

He tenido este problema durante años, y no creo que el control de versiones sea necesariamente el camino correcto. He tenido éxito con el the Unison file synchronizer que está diseñado con el propósito expreso de mantener directorios de inicio consistentes en dos máquinas. Actualmente estoy administrando siete réplicas al unísono, y los detalles son un poco complicados, pero es una gran herramienta y si comienzas con dos estarás extremadamente satisfecho.

La diferencia clave entre Unison y un VCS es que Unison está dispuesto a retrasar el tratamiento de los conflictos que deben fusionarse. Además, obtiene todos los valores predeterminados correctos. Y es rápido: lo uso a diario, a través de una línea DSL, para sincronizar unos 40 GB de datos.

Answer 6

git o la ramificación barata de Mercurials funcionaría muy bien para esta situación. Empecé con Mercurial, porque es más simple, pero luego se movió a git.

Answer 7

Una manera de manejar esto de manera muy flexible es tener un directorio de construcción bajo el control de revisión, no tratar de SVN su directorio de inicio real (que tiene sus propios problemas)

así dentro de este a mantener una estructura como

 
/home/you/code/dotfiles 
/home/you/code/dotfiles/dotbashrc 
/home/you/code/dotfiles/dotemacs 
... 
/home/you/code/dotfiles/makefile 

y el makefile puede contener lógica de archivos especializada (o no)

podría ser más pesado de lo que necesita, pero si su configuración actual es compleja (he hecho esto a través de 3 o 4 diferentes sistemas Unix en una tiempo) entonces vale la pena hacer algo Hing así.

Answer 8

Utilizo git para esto. Hasta ahora, he podido mantener sincronizados los directorios de inicio en varias máquinas, sin necesidad de ramificación y fusión. En cambio, uso git rebase. Los conflictos hasta ahora han sido pocos y distantes entre sí y fáciles de resolver.

Guardo los archivos que necesitan tener contenido separado fuera del control de revisión poniéndolos en .gitignore.

guardo archivos de configuración para las siguientes herramientas en git:

• varias conchas
• emacs y aplicaciones, es decir
  • ñus
  • BBDB
  • emacs-w3m
• mutt
• pantalla
• varias utilidades y scripts

guardo notas y tal en un subdirectorio que tiene su propio repositorio git.

Answer 9

Sugeriría buscar en etckeeper si no lo ha hecho ya. Está diseñado para versiones de los archivos de configuración en/etc usando un sistema de control de versiones:

etckeeper es una colección de herramientas para Let/etc almacenarse en un git, mercurial , darcs, o un repositorio bzr. Se conecta a apt (y a otros gestores de paquetes , incluidos yum y pacman-g2) para confirmar automáticamente los cambios realizados en/etc durante las actualizaciones del paquete. Es rastrea los metadatos del archivo que revison los sistemas de control normalmente no admiten , pero eso es importante para /etc, como los permisos de /etc/shadow. Es bastante modular y configurable, aunque también es simple para usar si comprende los conceptos básicos de que trabajan con control de revisión.

Aunque está diseñado para/etc, creo que probablemente también funcione bien (quizás con alguna adaptación) para los directorios de inicio ya que las necesidades básicas son las mismas.

Answer 10

Sé que este es un hilo antiguo pero lo encontré mientras buscaba algunos archivos punto.

Mi sistema actual está utilizando la subversión. La clave que hice fue verificar la copia de trabajo en ~/.svnhome/(en retrospectiva debería haberlo llamado .dotfiles o algo más genérico). Luego creo enlaces simbólicos a los archivos que uso en esa computadora en casa. Por ejemplo, mis carpetas .procmail y .spamassassin solo son necesarias en el servidor de correo, por lo que no las enlace en mi servidor doméstico.

El único archivo que tiene algunas diferencias es que el archivo .bashrc tiene algunas líneas adicionales en mi mac para macports. Entonces en la parte inferior de .bashrc lo tengo verificar si .bashrc_local existe y analiza eso.

Esto es lo último que me queda usando subversion (todo lo demás está usando git aparte del trabajo). El beneficio de svn es porque no es un dvcs, así que no tengo que preocuparme por comprometerme accidentalmente en un servidor y olvidarme de presionarlo.

He considerado moverlo a git para poder crear ramas. Usando el ejemplo anterior, tendría una rama para mi servidor principal que agregaría las carpetas .procmail y .spamassassin, pero no las tendría en la rama principal. Pero el sistema actual funcionó bien durante años, incluso antes de que existiera, y no tiene ninguna motivación particular para cambiarlo ahora.