linux - source - sistemas de control de versiones mas usados
El mejor sistema de control de versiones para administrar directorios de inicio (10)
Tengo 3 máquinas con Linux, y quiero una forma de mantener sincronizados los archivos punto en sus directorios personales. Algunos archivos, como .vimrc, son los mismos en todas las 3 máquinas, y algunos son únicos para cada máquina.
He usado SVN antes, pero todo el rumor acerca de los 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?
Aquí hay un desarrollador de Mozilla que ha intentado hacer esto: Versión que controla mi directorio de inicio , hay un par de sugerencias en los comentarios.
Cualquier DVCS probablemente funcione 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.
Un beneficio 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.
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.
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, rastrear todo su configuración relacionada con el desarrollo, que luego solo verifica en las máquinas que usa para desarrollar.
Esto me ha ayudado a organizar mi configuración mucho mejor en las más de 50 máquinas en las que me conecto.
Aquí está la página del proyecto . 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 rastrear cosas te causará dolor cuando lo esté usando.
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 sincronizador de archivos Unison, 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.
La ramificación barata de Git o Mercurials funcionaría muy bien para esta situación. Empecé con Mercurial, porque es más simple, pero luego se movió a git.
Sugiero que busque en etckeeper si aún no lo ha 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 permitir que / etc se almacene en un repositorio de git, mercurial, darcs o 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. Realiza un seguimiento de los metadatos de archivos que los sistemas de control de revisión normalmente no admiten, pero eso es importante para / etc, como los permisos de / etc / shadow. Es bastante modular y configurable, a la vez que simple de usar si comprende los conceptos básicos de trabajar con el control de revisiones.
Aunque está diseñado para / etc, creo que probablemente también funcione bien (quizás con alguna adaptación) para los directorios principales, ya que las necesidades básicas son las mismas.
Una forma de manejar esto de manera muy flexible es tener un directorio de compilación bajo control de revisión, no intentar y svn 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 archivo MAKE puede contener lógica para archivos especializados (o no)
podría ser más pesado de lo que necesita, pero si su configuración real es compleja (lo he hecho en 3 o 4 unidades diferentes a la vez), entonces vale la pena hacer algo como esto.
Yo uso 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.
.gitignore archivos que necesitan tener contenidos separados 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
- gnus
- BBDB
- emacs-w3m
- chucho
- pantalla
- varias utilidades y scripts
Guardo notas y tal en un subdirectorio que tiene su propio repositorio git.
Sé que este es un hilo viejo pero lo encontré mientras buscaba algunos archivos punto.
Mi sistema actual usa subversion. 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.
Esta es la última cosa que me queda usando subversión (todo lo demás está usando git aparte del trabajo). El beneficio de svn es que 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.