Крэшей сервера не было, а обрывы связи были...
Но даже не в этом дело. Обычно один коммит - это группа изменений в
нескольких файлах (например someclass.cpp + someclass.h) и несмотря на
то что это несколько файлов - логически это должен быть один коммит и
один revision.
ну не знаю... а как тогда жить, если изменения затрагивают несколько
классов - тут фикснули что-то, и там фикснули что-то, а фикс относится к
одному и тому же баг-репорту. получается, что на несколько классов одна
ревижн?
может я слишком долго с cvs работал, но мне как-то его система ревижинов
роднее.
Плюс мне очень важна поддержка svn из Eclipse, а там она еще не
совсем полноценна.
А что не так с subclipse? А то я собирался попробовать eclipse+pydev для
разработки на python...
хмм... забираю слова обратно - они теперь используют JavaSVN. Когда-то,
когда я смотрел на него он работал через JNI и был глюкавый.
Единственное, что пока смущает - это факт, что в Eclipse приняли
Subvesive, а не Subclipse. Но с другой стороны это пофиг - файлы на
диске не меняются. Но я пока жду, когда мы на svn перейдем - тогда и
буду тщательнее тестировать.
Если найдешь софт который может экспортировать данные из одной
базы, то написать батник который будет пробегать все
поддиректории особого труда не составит.
В svn можно этот батник вставить, например, в pre-commit hook для
пущей автоматизации процесса.
И он вместо бинарника в репозиторий запишет текстовый файл? А назад
как? Или я что-то не так понял?
Просто при каждом коммите проекта будут проверяться изменения в базе, и
вливаться в этот же репозиторий ;-)
А что будет с теми, что делает checkout из репозитория?
Роман
