Лучшая система контроля версий для управления домашними каталогами

Question

У меня есть 3 машины с Linux, и я хочу как-то синхронизировать точечные файлы в их домашних каталогах. Некоторые файлы, такие как .vimrc, одинаковы на всех трех машинах, а некоторые уникальны для каждой машины.

Я уже использовал SVN, но все разговоры о DVCS заставляют меня думать, что я должен попробовать один - есть ли конкретный, который лучше всего с этим работает? Или я должен придерживаться SVN?

Answer 1

У меня была эта проблема в течение многих лет, и я не думаю, что контроль версий - это верный путь. У меня был хороший успех с файловым синхронизатором Unison , который специально разработан для поддержания согласованных домашних каталогов на двух машинах. В настоящее время я управляю семью репликами в унисон, и детали немного сложны, но это отличный инструмент, и если вы начнете с двух, вы будете чрезвычайно довольны.

Ключевое различие между Unison и VCS заключается в том, что Unison желает отложить рассмотрение конфликтов, которые должны быть объединены. Плюс ко всему, все настройки по умолчанию правильные. И это быстро: я использую его ежедневно, по линии DSL, для синхронизации около 40 ГБ данных.

Answer 2

Любая DVCS, вероятно, будет работать нормально. Мой любимый это Bazaar . Было бы проще сохранить ваши конфигурационные файлы в .config, версии, а затем, при необходимости, в символической ссылке.

Преимущество DVCS заключается в том, что вы также можете создавать версии для конфигурационных файлов для каждой машины, не влияя на глобальные настройки версий.

Answer 3

У меня была та же проблема, и я создал инструмент поверх Subversion, который добавляет права доступа, владение и отслеживание второстепенного текста, удерживает каталоги .svn от фактически версионных деревьев и добавляет концепцию слоев, чтобы вы Пример отслеживания всех ваших настроек, связанных с разработкой, которые вы затем проверяете только на машинах, которые используете для разработки.

Это помогло мне лучше организовать мои настройки на более чем 50 машинах, в которые я заходил.

Вот страница проекта . Он все еще немного грубоват, но мы также используем его для работы над настройкой конфигурации системы для наших 60+ серверов.

В общем, любая система управления версиями, которая использует какие-либо файлы метаданных для отслеживания материала, будет причинять вам боль, как и при ее использовании.

Answer 4

Я знаю, что это старая ветка, но нашла ее при поиске некоторых файлов точек.

Моя текущая система использует Subversion. Ключевым моментом, который я сделал, было проверить рабочую копию в ~ / .svnhome / (задним числом следовало бы назвать ее .dotfiles или что-то более общее). Затем я создаю символические ссылки на файлы, которые я на самом деле использую на этом компьютере, в дом. Например, мои папки .procmail и .spamassassin нужны только на почтовом сервере, поэтому я не связываю их на своем домашнем сервере.

Единственный файл, который имеет некоторые различия, - это файл .bashrc, в котором есть несколько дополнительных строк на моем mac для macports. Таким образом, в нижней части .bashrc я проверил, существует ли .bashrc_local и анализирует ли он.

Это последняя оставшаяся вещь, которую я использую в Subversion (все остальное использует Git, кроме работы). Преимущество svn в , потому что это не dvcs, поэтому мне не нужно беспокоиться о случайной фиксации на одном сервере и забывании нажать на нее.

Я подумал о том, чтобы переместить его в git, чтобы я мог создавать ветки. Используя приведенный выше пример, у меня будет ветвь для моего главного сервера, в которую я добавлю папки .procmail и .spamassassin, но не добавлю их в основную ветку. Но текущая система работала хорошо в течение многих лет - еще до того, как git даже существовал - и у нее нет особой мотивации менять ее сейчас.

Answer 5

Я бы посоветовал посмотреть etckeeper , если вы еще этого не сделали. Он предназначен для управления версиями файлов конфигурации в / etc с использованием системы контроля версий:

etckeeper - это набор инструментов для пусть / etc хранится в git, Mercurial, Darcs или BZR хранилище. Зацепляет apt (и другой пакет менеджеры включая yum и pacman-g2) автоматически фиксировать внесенные изменения в / etc во время обновления пакета. Это отслеживает метаданные файла, которые пересматриваются системы управления обычно не поддержка, но это важно для / etc, такие как права доступа / И т.д. / тень. Это довольно модульный и настраиваемый, а также простой использовать, если вы понимаете основы работа с контролем версий.

Несмотря на то, что он предназначен для / etc, я думаю, что он, вероятно, также будет работать (возможно, с некоторой адаптацией) для домашних каталогов, поскольку основные потребности одинаковы.

Answer 6

Я использую Git для этого. До сих пор мне удавалось синхронизировать домашние каталоги на нескольких машинах без необходимости ветвления и объединения. Вместо этого я использую git rebase. До сих пор конфликты были редки и их легко разрешить.

Я храню файлы, которые должны иметь отдельное содержимое, вне контроля версий, помещая их в .gitignore.

Я сохраняю файлы конфигурации для следующих инструментов в git:

• различные снаряды
• Emacs и приложения, т.е.
  • гну
  • BBDB
  • Emacs-w3m
• собачонка
• экран
• различные утилиты и скрипты

Я храню заметки и тому подобное в подкаталоге, в котором есть собственный репозиторий git.

Answer 7

Один из способов сделать это очень гибко - это иметь каталог сборки под контролем ревизии, а не пытаться создать свой собственный домашний каталог (у которого есть свои проблемы)

так что внутри вы сохраняете структуру типа

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

и make-файл может содержать логику для специализированных файлов (или нет)

может быть тяжелее, чем вам нужно, но если ваша фактическая настройка сложна (я делал это для 3 или 4 разных юнитов одновременно), тогда стоит сделать что-то вроде этого.

Answer 8

git или Mercurials * Дешевое разветвление отлично подойдет для этой ситуации Я начал с Mercurial, потому что он проще, но впоследствии перешел на git.

Answer 9

Вот разработчик Mozilla, который пытался сделать это: Версия, управляющая моим домашним каталогом , в комментариях есть пара предложений.

Answer 10

Программное обеспечение для контроля версий не очень подходит для домашних каталогов. Хуже того, некоторые программы не любят папки .svn или начинают интерпретировать их содержимое. Конечно, вы можете попытаться исправить это с помощью очень сложной настройки зеркалирования, но это сложно.