1) что для меня будет лучше cvs или svn если я:
а) один разработчик, проектов много
думаю, что пофиг.
Нет. Неатомарность коммитов в CVS - это плохо даже в случае одного
разработчика. По крайней мере, для меня это так ;)
У тебя часто случались крэши сервера во время коммита? У меня за 6 лет
работы с ним еще ни разу (и на работе по локалке, и в Firebird по
интернету, как дайлапу так и ДСЛ)... так что я пока этот аргумент
серъезным не считаю. Но это лично мое мнение.
svn лучше в другом - переименование объекта не приводит к пропаже
истории изменений, как в cvs. Но я пока на svn не перешел - на работе и
cvs хватает, а Firebird еще на svn не переехал (но планируется). Плюс
мне очень важна поддержка svn из Eclipse, а там она еще не совсем
полноценна.
Для Николая: если переименовать файл в cvs, то его старая версия будет
обозначена как уделенная, а новый файл придется добавлять в репозиторий
начиная с версии 1.1. Вся история изменений до переименования будет
привязана к старому файлу, а посему нельзя так просто ее добыть.
2) есть один проект на двух-трех клиентов, для каждого клиента надо
вносить незначительные изменения именно под него. Как это можно
проконтролировать кроме как заводить разные каталоги с исходниками.
>>>
Не каталоги, а разные branches (ветки). Хотя с точки зрения организации
кода - неправильный подход. Проблемы начнутся, когда надо будет
синхронизировать ветки (например фикс бага, который надо дать всем
клиентам).
В svn для этого есть команда merge. Т.е. можно, например, изменения,
сделанные в одной из branches начиная с revision X по revision Y влить в
trunk или в другой branch.
Угу, в CVS она тоже есть. И что? Если у человека 5 веток от HEAD и он
внес в каждой из них свои особенные изменения, а потом глобальные в
HEAD, то сливать это ручками совсем не так просто (см. исходную
предпосылку - "каждому клиенту - свою версию"). А если речь заходит о
branch от branch, то можно запутатся, особенно если модули в cvs между
собой завязаны (например основная программа и библиотеки, утилиты,
компоненты).
Если найдешь софт который может экспортировать данные из одной базы, то
написать батник который будет пробегать все поддиректории особого труда
не составит.
В svn можно этот батник вставить, например, в pre-commit hook для пущей
автоматизации процесса.
И он вместо бинарника в репозиторий запишет текстовый файл? А назад как?
Или я что-то не так понял?
Роман