Хранить в svn конфиги серверов.

С свн до этого не особо работал, но разберусь :)

Лучше git или mercurial.

Лучше завести конфиги в puppet, а вот конфиги самого puppet в git или mercurial, да. :)

Есть еще etckeeper, как удобная надстройка - http://evilrouters.net/2011/02/18/using-etckeeper-with-git-on-ubuntu/

По поводу svn вообще никаких приличных слов в голову не приходит. С гитом/меркуриалом разберёшься, ничего архисложного. Возможно, для руления категориями и серваками ветки окажутся полезными.

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

Первое что хочу сказать - ну слушай этих фанатов git и mercurial. Они кроме распределенных систем ничего не видят и о недостатках говорить не любят.

Лично я пользуюсь svn. Из достоинств:
- простая для понимания (git, говорят, по началу моск ломает)
- делает все, что нужно (пользуюсь с двух компов)
- централизованный репозиторий; как по мне удобно с точки зрения администрирования и когда захочется забекапить; в репозитории хранятся все версии, на локальном - только последняя (в децентрализованных, как я понял, ты конфиги всех компов будешь хранить на всех компах, пусть меня поправят, если я не прав; особенно пухнет если много бинарных данных)
- кросс-платформенность: хорошие клиенты (в т. ч. WEB, где-то видел плагин для dolphin, встраивается в MS Windows explorer), такие плюшки как преобразование символов перевода строки, полезно если захочешь Линуксовый конфиг посмотреть в Windows.

Недостатки:
- да, для работы с репозиторием нужно подключение к нему по сети
- медленней по сравнению с децентрализованными (если лишние 5-10 секунд для тебя принципиально).
- если будешь переименовывать/перемещать файлы, то в CVS нужно лишние телодвижения чтобы оно отследило эту операцию, иначе будет трактовать как удаление + добавление. В git или mercurual оно, AFAIK как-то это отслеживает.

Как по мне для твоей задачи SVN самое оно.

Это мое ИМХО. Послушай и других. Дальше решай.

Если устраивает (а меня даже очень), то вперед.

А из best practices - там все просто. Рекомендую почитать svn book: http://svnbook.red-bean.com/

Советы:
- настрой список файлов, которые нужно игнорить - например файлы типа abc.txt~ - бекап, созданный kwrite
- проследи чтобы нормально определяло текстовые и бинарные файлы; например, по началу оно у меня XML почему-то воспринимало как бинарный. Да и вообще проверь mime-types.
- настрой чтобы оно конвертило end-of-line символы при переносе на другие платформы.
- рекомендую делать отдельный репозиторий на один комп/набор конфигов.
- перед комитом делай svn status, ну, а если у тебя все будет в одном репозитории (но в разных каталогах), то svn update
- обязательно пиши осмысленные комментарии коммитам.

Если что, обращайся.

простая для понимания (git, говорят, по началу моск ломает)

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

делает все, что нужно (пользуюсь с двух компов)

Я за месяц так и не нашёл возможности посмотреть всю активность в проекте (все коммиты во всех ветках)

кросс-платформенность: хорошие клиенты (в т. ч. WEB, где-то видел плагин для dolphin, встраивается в MS Windows explorer),

Все пункты есть и для гита, но интеграции особо и не нужны, ты сам описал почему.

преобразование символов перевода строки

Тоже настраивается в гите, но не нужно, редакторам давно плевать на такие мелочи, если это не блокнот.

В git или mercurual оно, AFAIK как-то это отслеживает

Вроде никак не отслеживает, ему откровенно пофиг что ты делал с файлами, важна только разница во время коммита.

...Звучу как фанатик, знаю.

Да, да, конечно, используйте svn, а еще лучше cvs :DDD

Не вижу причин чтобы не использовать SVN.

• У серверов права только на read конфиг файлов.
• У каждого сервера checkout только своей/своих директории
• Коммитить можно только с локальных мест администратора.
• Puppet - это следующий шаг, как и OpenLDAP
  
  

  GIT в этом случае не предоставляет никаких преимуществ

Спасибо, большое!

...Звучу как фанатик, знаю.

Есть такое.

Честно, не со всем согласен, но не хочу начинать холиворов.

Ты бы лучше расписал плюсы и минусы git/mercurial , т. е. взвешенную оценку. От человека, который этим пользуется, это будет более объективно. А остальным полезно. Чтобы лучше понять когда использовать, а когда нет. За одно из категории «фанатики» выпадешь :P

готовся к .svn в каждом каталоге

меня это не пугает

Да, и готовься к кривому мерджу, а значит и ручному слиянию веток, если работаешь не один, готовься к тормозам и к тому, что svn в наше время умерло тоже готовься :)

простая для понимания (git, говорят, по началу моск ломает)

git clone git@server:config.git

изменения...

git add .
git commit -m "обновлен конфиг nginx"
git push

Ломает, да.

Мержить у нас никто не будет. Организация работы такая. Хорошо это или плохо, но это так

Ну я же говорю, тогда используйте CVS! Зачем, вам современные фичи?))

dbzer0 Если ты считаешь что необходим git вместо svn, то обьясни, пожалуйста, причины?

С учетом моих комментариев

У серверов права только на read конфиг файлов.
У каждого сервера checkout только своей/своих директории
Коммитить можно только с локальных мест администратора.

умерший SVN?

откуда дровишки?

зы: ты свое сообщение снес дабы модераторы за провокацию скор не порезали?

вот почему не будем использовать CVS,

• Невозможно переименовать файл или директорию так, чтобы это изменение было отражено в истории.
• Ограниченная поддержка юникода и не-ASCII имен.
• Публикации изменений не атомарны.
• Наборы изменений не поддерживаются.
• Неэффективное хранение бинарных файлов.

если было бы, то может и использовали бы :)

А зачем 3 команды чтобы сделать коммит?

Хранить в git конфиги серверов.

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

//тред не читал

Не понимаю, о чем Вы коммит делает 1 команда:

git commit -m "обновлен конфиг nginx"

умерший SVN?

откуда дровишки?

Продукт умирает тогда, когда его не используют новые пользователи

Все просто, git не имеет минусов, в отличие от svn. Для чего использовать заведомо худший продукт?

Ушел от SVN 4 года назад на Git и очень рад этому до сих пор.

В git хочешь использовать с централизованный репозиторий - используй - это всего лишь уровень абстракции.

Хочешь мержить - мерж сначала у себя, чтобы не ждать 3 часа мерджа в удаленном репозитории SVN.

Push изменения когда тебе нравится.

конфиги однотипные чтоль

200+ штук, разбитых на ~40 категорий

вообще паппеты есть всякие еще

• Puppet - это следующий шаг, как и OpenLDAP

  уже написал

GIT в этом случае не предоставляет никаких преимуществ

Главное и основное - распределенность. На всех серваках хранится полный реп конфигов для всех других. Если у тебя падает SVN-хост, конфиги ты будешь собирать по кусочкам со всех хостов заново (ну или копаться в бэкапах). В случае гита - поднимаешь сервак обратно, git clone с любого работающего и вуаля

таки две.
git add nginx.conf && git commit -m «обновлен конфиг nginx»

В git или mercurual оно, AFAIK как-то это отслеживает

Вроде никак не отслеживает

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

--similarity

add - добавляет файл в индекс commit - коммитит

-am

это пофиксили вроде с 1,7 версии

Не понимаю, о чем Вы коммит делает 1 команда:

git add .
git commit -m «обновлен конфиг nginx»
git push

Что из add, commit, push делает коммит и зачем тогда нужны остальные, если я просто хочу сделать коммит?

можно и одной коммандой git commit -am «обновлен конфиг nginx»

add - добавить файл в индекс

commit - СДЕЛАТЬ КОММИТ

push - ЗАЛИТЬ в удаленный репозиторий, если надо

PS: если хотите, я лично для Вас напишу скрипт, делающий это все одной командой :)

Продукт умирает тогда, когда его не используют новые пользователи

По данным статистики использования пакетов Linux-дистрибутивов Debian[9] и Ubuntu[10], количество активных пользователей Subversion примерно такое же, как у Git, и превосходит аналогичный показатель для CVS, Mercurial и Bazaar (по состоянию на июнь 2011 года).

http://ru.wikipedia.org/wiki/Subversion

Вы очередной раз пропустили слово НОВЫЕ :)

В последних версиях это вылечили, кажется

это пофиксили вроде с 1,7 версии

у меня 1.6.18, надо будет глянуть

Вы очередной раз пропустили слово НОВЫЕ :)

т.е. Вы хотите сказать что старые пердуны по привычке сидят на загнивающем svn, а продвинутая молодежь юзает гит?

-a разве не добавляет untracked файлы в индекс заодно? это не всегда нужно

Все просто, git не имеет минусов, в отличие от svn.

В git уже можно сделать clone только для поддерева (не всего репозитория), что-то поменять и сделать push?

Толстые бинарники со всеми своими версиями лежат в каждом клоне, занимая много места, разве это плюс?

У тебя было «обновлен конфиг», а не добавлен. :)

В git уже можно сделать clone только для поддерева (не всего репозитория), что-то поменять и сделать push?

Конечно же нет и никогда не будет, ибо он распределенный, а значит всегда содержит полный реп и это плюс.

Толстые бинарники со всеми своими версиями лежат в каждом клоне, занимая много места, разве это плюс?

А для чего хранить бинарники в git?

Неправильно прочитал, нет не добавляет, комитит только изменения в трекаемых файлах.

<troll>Зачем эти костыли?</troll>
Для задачи ТС это не нужно.
Перестаньте совать git во все дыры!

Это вы перестаньте откапывать svn :)

Конечно же нет и никогда не будет

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

А для чего хранить бинарники в git?

Т.е. версионировать нужно только plain text, для остальных сложных документов вроде картинок/звуков/... это типа «не нужно»?

Т.е. версионировать нужно только plain text, для остальных сложных документов вроде картинок/звуков/... это типа «не нужно»?

Вы сами себе враг. Вам следует переделать систему сборки пакетов. Все бинарные данные должны вливаться на этапе сборки/тестирования. И уж точно не надо их хранить ни в одной из VCS.