с одной стороны - маленькая группа разработчиков (не линукс-кернель однако), также проекты HDL-ные и ответственность за блок (файл) обычно закреплена индивидуально и conflict/merge возникает редко

но с другой стороны, Торвальдс прав - система контроля версий должна быть графом, а не деревом - то есть после слияния ветки должны сходится

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

вот думаю - стоит ли пытаться и если стоит, то какую
git или bazaar?

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

Я Mercurial использую. Никаких особых "за", никаких особых "против". Интерфейс у командной строки у него на SVN похож.

Ещё сталкивался в плане использования сторонних проектов с darcs.

Я подозреваю, что вы не до конца понимаете смысла сказанного. Системы управления версями могут быть построены по разным моделям, и при этом работать корректно.



Пожалейте свой моск -- берите Базар. При использовании bzr-svn есть возможность работать с существующим главным SVN-репозиторием, при этом не вынуждать всех разработчиков переходить на другую систему за один день. Т.е. переход можно сделать плавным, запустить параллельный базаровский репозиторий.

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

это дополнительно, но кажется полезное и достаточно очевидное для контроля версий свойство git-a - то есть если ветки слиты, то система должна об этом помнить, чего SVN не делает
сужу я об этом по известному ролику с горячим шведом. но разбираться с git-ом пока не начал




если я не ошибаюсь, Вы принимаете участие в Bazaar-е?

существующий проект в любом случае будем держать под svn-ом (ну или откатимся под cvs - см. проблему http://electronix.ru/forum/index.php?showtopic=55422)

это я хочу в своих проектах/подпроектах попробовать (потестировать/посмотреть) более продвинутую систему, для следующих проектов
так я сделал с svn (прошлые проекты был под cvs, но ряд "фич" достал)
но опять же - пока я один возился с svn - никаких проблем не было (хотя принципиальных плюсов перед cvs нет) ряд плюсов я нашел
сейчас, пока ревизии еще "ф сотне" и файлов пол-сотни вылезли всякие неприятности (в основном винда и глюки тортозы)

поэтому меня интересует не сиюминутная простота перехода, а некая перспектива, хотя может это и маразм

--------------------

git меня привлекает популярностью - милионы мух не могут ошибаться

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

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

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

-------------------

вопрос: bazaar придерживается такой же системы как svn? то есть число бранчей только увеличивается со временем?

вопрос: графический клиент для него существует?

_____________

вобщем надо пробовать - осталось определить, какой порядок

Долгожданный релиз svn 1.5 кажется уже начал сохранять какую-то информацию о проведенных объединениях. Правда до судя по описанию -- до удобства распределенных систем все еще далеко.



До апреля 2008 я принимал активное участие и был куратором windows-версии.



Не понятно что вам даст откат на CVS. Вроде как симлинки и CVS -- две ортогональные вещи.



Да, тестировать лучше на каких-то небольших вещах. Если у вас есть время и желание, то попробуйте все 3 системы: git, hg, bzr. По крайней мере сложившийся рейтинг популярности в linux-мире у них именно такой.



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



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



DAG там (как и в hg и bzr и mtn) используется как оптимизация выполнения. Это упрощает отслеживание объединений. Однако это усложняет такую операцию как cherrypicking. Так что не стоит так идеализировать графы.



я не спец в svn, однако скорее нет, чем да.



Один писан на GTK, другой на Qt. В настоящее время я учавствую в развитии Qt-ного варианта. На его основе делается TortoiseBzr. Однако работа еще в процессе, поэтому сравнивать с TortoiseSVN и делать смелые и решительные выводы, что это все г, наверное, не стоит.



1) инсталлировать продукт
2) читать доку
3) пробовать
4) спрашивать

спасибо за подробный ответ



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

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

вопросы по bzr можно задавать и там: http://groups.google.com/group/ru_bzr

Если симлинки вам нужны именно для этого, то svn:externals вас спасет.

нет, это я пример привел, что CVS не знает что такое линк вообще

проблема с линками в рабочий копии : из одной директории в другую
смысл - проще мне иногда для сборки не искать файл, а иметь его "здесь"

решу скорее всего скриптом для генерации линков под линуксом и копировании файлов под виндовзом
имхо, так проще