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

по состоянию на июнь 2011 года

1. Это было полтора года назад. Сейчас гит раза в 1.5 популярнее svn
2. При этом, за полтора года, прирост гита раз в 10 больше прироста свн
3. В статистике учитываются даже те, которым от svn нужны только svn co и svn up (скажем, я из транка собираю mplayer и vcmi)

Так что таки доля svn среди новых проектов близка к 0.

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

Ресурсы для разрабатываемой игры тоже не надо хранить в VCS? Или просто doc/xls/vsd файлы?

Ресурсы для разрабатываемой игры тоже не надо хранить в VCS? Или просто doc/xls/vsd файлы?

Я же выше написал, что это дурной тон, все ресурсы, картинки, музыку, third party бинарники, видео все это соединяется на билд системе, которая компилит и тестит проект и не нужно их хранить ни в git, ни в svn, ни в любой другой VCS, они для этого не предназначены.

все ресурсы, картинки, музыку, third party бинарники, видео все это соединяется на билд системе

Вопросы:

• Откуда все это берется в «билд системе»?
• Как следить за изменениями во всех эти вещах, если для них не используется VCS?
• Как воспроизвести результат сборки на другой машине?

Мы используем jenkins, раньше hudson для билда, все ресурсы подтягиваются сценариями при сборке.

все ресурсы подтягиваются сценариями при сборке

Откуда подтягиваются? Как там версионируются ресурсы (ведь это же очевидно нужная вещь)?

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

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

В git нельзя клонить к себе куски репозитория????
*Полное непонимание*
git для меня не подходит.

Откуда подтягиваются?

Все просто, через сценарий у нас они сливаются через webdav.

При попадании на webdav сервер старые, заменяемые файлы, переносятся в old каталог скриптом, в формате /old/<имя_проекта>/<стуктура_каталогов>/file.bin.<timestamp_создания_файла>.

Плюс снимаются ежедневно инкрементальный бекап.

Но это в любом случае просто 2 бекапа. Не представляю, что Вы подразумеваете под версионностью бинарников, вы же diff глазами не читаете.

Как верно заметили, лучше git/mercurial. Там есть инструменты для внесения в репозиторий всех изменений в каталоге.

Все просто, через сценарий у нас они сливаются через webdav.

При попадании на webdav сервер старые, заменяемые файлы, переносятся в old каталог скриптом, в формате /old/<имя_проекта>/<стуктура_каталогов>/file.bin.<timestamp_создания_файла>.

Это же какой-то самописный костыль вместо системы контроля версий. Получается, что нельзя из одного репозитория воспроизвести сборку определенной версии, нужен еще какой-то «webdav сервер», который может быть не доступным или не содержать нужных версий файлов?

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

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

Но если Вас не устраивают бекапы, вы всегда можете добавить в этой схеме любой уровень «версионности» любой технологией, начиная хранением .patch заканчивая снапшотами FS.

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

Факт.

От себя могу добавить, что в git изменения коммитятся осмысленными блоками проделанной работы. Ну если коммиттер не безалаберный раздолбай конечно.

Если взять в качестве примера тот же nginx - админ приходит добавить новый vhost, с ssl, он выполняет несколько операций: добавляет ключи (два файла), создаёт конфиг в sites-available, делает для него симлинк в sites-enabled, проверяет конфиг, убеждается, что всё работает, и коммитит всю проделанную работу разом с единым человекопонятным описанием: «добавил vhost my.site.bla.ru, настроил для него ssl». В истории видна вся проделанная работа.

Админские правки обычно не так велики, если хочется, то и svn вполне сгодится.

svn управляет версиями отдельных файлов

Вы с CVS не путаете? это в нем как раз версионность по файлам ведется, а не репозитария.

В svn можно сделать update разных файлов в рабочей копии на разные ревизии, и svn status не будет показывать никаких модификаций, т.е. svn следит за каждым файлом в рабочей копии индивидуально.