El mejor sistema de control de versiones para gestionar directorios personales

Question

Tengo 3 máquinas Linux y quiero alguna forma de mantener sincronizados los archivos de puntos en sus directorios de inicio.Algunos archivos, como .vimrc, son iguales en las 3 máquinas y algunos son únicos para cada máquina.

He usado SVN antes, pero todos los rumores sobre los DVCS me hacen pensar que debería probar uno: ¿hay alguno en particular que funcione mejor con esto?¿O debería seguir con SVN?

Answer 1

Tuve el mismo problema y construí una herramienta sobre Subversion que agrega permisos, propiedad y seguimiento de segundo contexto, mantiene los directorios .svn fuera de los árboles versionados realmente y agrega un concepto de capas para que puedas, por ejemplo, rastrear todos su configuración relacionada con el desarrollo, que luego solo verifica en las máquinas que utiliza para el desarrollo.

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.

Aquí está la página del proyecto..Todavía es un poco tosco, pero también lo usamos en el trabajo para versionar la configuración del sistema para nuestros más de 60 servidores.

En general, cualquier sistema de control de versiones que utilice algún tipo de archivos de metadatos para rastrear cosas le causará problemas al usarlo.

Answer 2

He tenido este problema durante años y no creo que el control de versiones sea necesariamente el camino correcto a seguir.He tenido buen éxito con el el sincronizador de archivos Unison que está diseñado con el propósito expreso de mantener directorios personales consistentes en dos máquinas.Actualmente estoy gestionando siete réplicas al unísono y los detalles son un poco complicados, pero es una gran herramienta y si empiezas con dos quedarás muy satisfecho.

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

Answer 3

Es probable que cualquier DVCS funcione bien.Mi favorito es Bazar.Sería más fácil mantener sus archivos de configuración en .config, versionarlo y luego vincularlo simbólicamente según corresponda.

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

Answer 4

El software de control de versiones no es realmente bueno para los directorios personales.Peor aún, a algunos programas no les gustan mucho las carpetas .svn o empiezan a interpretar su contenido.Por supuesto, podrías intentar solucionar este problema con alguna configuración de duplicación muy compleja, pero eso es difícil.

Answer 5

Aquí hay un desarrollador de Mozilla que intentó hacer esto: Versión que controla mi directorio de inicio, hay un par de sugerencias en los comentarios.

Answer 6

git o mercurialesLa ramificación barata de funcionaría muy bien para esta situación.Comencé con Mercurial, porque es más simple, pero posteriormente pasé a git.

Answer 7

Una forma de manejar esto de manera muy flexible es tener un directorio de compilación bajo control de revisión, no intentar usar svn en su directorio de inicio real (que tiene sus propios problemas).

Así que dentro de esto mantienes 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 para especializar archivos (o no)

Puede ser más pesado de lo que necesita, pero si su configuración real es compleja (he hecho esto en 3 o 4 unidades diferentes a la vez), entonces vale la pena hacer algo como esto.

Answer 8

Yo uso git para esto.Hasta ahora, he podido mantener sincronizados los directorios de inicio de varias máquinas, sin necesidad de bifurcaciones ni fusiones.En cambio, uso git rebase.Hasta ahora los conflictos han sido pocos y fáciles de resolver.

Mantengo los archivos que necesitan tener contenidos separados fuera del control de revisión colocándolos en .gitignore.

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

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

Guardo notas y demás en un subdirectorio que tiene su propio repositorio git.

Answer 9

Yo sugeriría investigar etc guardián si aún no lo has hecho.Está diseñado para versionar archivos de configuración en /etc usando un sistema de control de versiones:

etckeeper es una colección de herramientas para dejar que /etc se almacenen en un repositorio GIT, Mercurial, DARCS o BZR.Se conecta a APT (y otros administradores de paquetes, incluidos Yum y Pacman-G2) para comprometer automáticamente los cambios realizados a /etc. durante las actualizaciones de paquetes.Rastrea los metadatos de archivo que los sistemas de control de Revison normalmente no admiten, pero eso es importante para /etc., como los permisos de /etc /shadow.Es bastante modular y configurable, al tiempo que es fácil de usar si comprende los conceptos básicos de trabajar con el control de revisión.

Aunque está diseñado para /etc, creo que probablemente también funcione bien (quizás con alguna adaptación) para directorios personales 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 de puntos.

Mi sistema actual utiliza subversión.Lo clave que hice fue revisar la copia de trabajo en ~/.svnhome/ (en retrospectiva, debería haberla 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 vinculo en mi servidor doméstico.

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

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

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