Darcs repository to CVS ?

Боюсь, это в принципе невозможно. Но можно попробовать tailor.

А почему именно CVS? Есть куча более современных и более юзабельных систем. Mercurial, например.

Nekotorie kollegi na cvs sidyat... X Ya darcs pol`zuyu. Nestikovka malen`kaya ... Spasibo, Vic.

Понятно. Лучше перетаскивай их на что-нибудь современное (но _не_ Darcs). А так - совет в силе: попробуй tailor. У автора есть пример 2-way sync, правда, между Darcs и SVN, IIRC. На самый крайняк можно попробовать импортировать патч за патчем 8)

> Лучше перетаскивай их на что-нибудь современное (но _не_ Darcs).

А чем так Darcs не угодил?

>> Лучше перетаскивай их на что-нибудь современное (но _не_ Darcs).

>А чем так Darcs не угодил?

Darcs - хорощая система, но 1) по словам ее же автора - экспериментальная 2) остановилась в развитии, наткнувшись на серьезную проблему - алгоритм patch commuting, который лежит в ее основе, имеет очень нехорошее (экспоненциальное время/память) поведение в некоторых редких (но регулярно встречающихся на практике) случаях. Пока что эта проблема не решена (уж то ли год, то ли два). Это, так сказать, принципиальные возражения. Есть еще по мелочам - плохая поддержка двоичных файлов, не самый эффективный формат хранения, общая тормознутость (ну, по крайней мере раньше так было), отсутсвие инструментов типа mq (уже не представляю, как я без него обходился).

Есть еще возражение для данного конкретного случая - мне кажется, что если переходить на 3-ю систему (т.е. не-CVS, не-Darcs), коллегам psi не будет казаться, что он "тянет одеяло на себя". Может, его шансы на успех повысятся.

> отсутсвие инструментов типа mq

Что за mq?

И какая реальная альтернатива дарксу (желательно распределенная)?

> Что за mq?

Mercurial Queues, патч-менеджер из системы mercurial, http://www.selenic.com/mercurial/wiki/index.cgi/MqExtension.

> И какая реальная альтернатива дарксу (желательно распределенная)?

Соответственно, mercurial. =)

> какая реальная альтернатива дарксу (желательно распределенная)?

Вдобавок к посту от ero-sennin: есть ложка дегтя в этой бочке мёда - сейчас Mercurial (и mq) не поддерживает русский язык. То есть 1) русские имена файлов лучше не использовать (умеючи - можно, но всё равно не советую), 2) ты можешь писать лог-мессаги по-русски (скажем, в koi8-r), но они будут сохранятся в репозитории именно как koi8-r, а будущий стандарт i18n - это utf-8. У меня есть патч, который позволяет задавать рабочую кодировку, но он для Mercurial 0.8.1 (текущая версия - 0.9.1). Чем грозит хранение мессаг в koi8-r? Отсуствием интероперабельности с Виндой, и тем, что, когда будет реализован "официальный" i18n, "hg log" будет выдавать ошибку при попытке отобразить мессаги в koi8-r. Поправить мессаги невозможно.

И самое главное забыл - размер репозитария под hg :) Он растёт че-то очень быстро и для кода 1 Mb сейчас у нас где-то 14 Mb. Можно представить, что будет если большой проект там хранить.

> И самое главное забыл - размер репозитария под hg

Нет, этого я не забывал. С размерами репозитория - всё нормально. У нас: исходников 10М, репозиторий 20М. У Mercurial всегда эффективный формат репозитория, в 0.9 стал еше лучше. Так что ищите в своих usage patterns. Например, если часто переименовываете (особенно большие) файлы - так оно и будет. Это да, засада.

И вдогонку...

> Можно представить, что будет если большой проект там хранить.

Представлять - не нужно. У меня есть зеркало hg-репозитория Linux: 240М исходники, 323М репозиторий. При этом учти, что это - Mercurial 0.8.1, до появления нового формата репозитория. Этот формат на некоторых патологических репозиториях (много мелких файлов/переименований в пределах одного каталога) может дать выигрыш в разы. У вас какая версия?

[все цифры - от du, учитывают slack]

Вообще-то ядро не 240 метров занимает, а порядка 40 :) в сжатом виде. Я-то как раз про сжатые в tar.gz репозитарии говорю. Распакованные, понятно, меньше занимать будут.

http://linuxtv.org/hg/v4l-dvb - 14 метров в tar.gz, 2.4 метра без каталога .hg

Я против mercurial ничего не имею, но некоторые решения технические у них спорные, например, невозможность внесения изменений в один только файл или возможность напутать с логами, версиями.

> ядро не 240 метров занимает, а порядка 40 :) в сжатом виде

То есть ты сравниваешь архив, в котором несколько десятков тысяч версий, к каждой из которых возможен быстрый доступ - с архивом, в котором одна версия? Причем доступ к ней невозможен без предварительной распаковки. Странное сравнение - любая VCS в таком проиграет.

> некоторые решения технические у них спорные, например, невозможность внесения изменений в один только файл

Не понял. У меня некоторые changeset'ы меняют только 1 файл. Примеры можешь привести?

> возможность напутать с логами, версиями.

Примеры?

> То есть ты сравниваешь архив, в котором несколько десятков тысяч версий, к каждой из которых возможен быстрый доступ - с архивом, в котором одна версия? Причем доступ к ней невозможен без предварительной распаковки. Странное сравнение - любая VCS в таком проиграет.

Я бы не стал так окрашивать. Речь идёт о том количестве мегабайт, которое должен скачать новый разрабочик, чтобы начать разработку. У CVS отношение рабочая копия/чистые исходники около 1. У subversion примерно 2. У mercurial отношение доходит до 10. Это сильно затрудняет участие в проекте.

> Не понял. У меня некоторые changeset'ы меняют только 1 файл. Примеры можешь привести?

Иногда изменения вносятся в несколько файлов сразу, а в upstream нужно закомитить только 1 файл. В hg в отличие от svn это тяжело сделать.

>> возможность напутать с логами, версиями. >Примеры?

Ну вот эта ветка например

http://marc.theaimsgroup.com/?l=linux-video&m=114296301603779&w=2

> Речь идёт о том количестве мегабайт, которое должен скачать новый разрабочик, чтобы начать разработку. У CVS отношение рабочая копия/чистые исходники около 1. У subversion примерно 2.

[под "чистые" ты понимаешь "последняя версия, хорошо упакованная", так?]

Нууу, это просто нечестно ;) CVS - каждый diff путешествует по сети, да только за счет этого ты проиграешь по трафику (в SVN это поправили). По экономии трафика SVN может быть впереди Mercurial, да. Но даже это не очевидно - в Mercurial ты один раз скачиваешь весь репозиторий, а потом - только обновления; в Subversion ты лазишь в сеть за каждым log, не-локальным diff, update. В общем, я бы не стал утверждать, что по трафику Mercurial намного расточительнее. По занимаемому на диске месту - я бы сказал, он примерно наравне с SVN (там коэффициент на самом деле не 2 - больше, потому что кроме text-base хранятся проперти, создаются служебные каталоги).

Не говоря уже, что для работы с CVS нужно постоянное подключение к сети (любой diff, log, update, commit), с SVN - очень хорошо бы иметь такое подключение (нелокальный diff, log, update, commit), а Mercurial это почти не нужно (push/pull). Так что при отсуствии связи - только Mercurial.

> У mercurial отношение доходит до 10.

Оно примерно такое у всех DVCS

> Ну вот эта ветка например

> http://marc.theaimsgroup.com/?l=linux-video&m=114296301603779&w=2

Я помню эту ветку! Там так и не выяснили, в чем была проблема, так? Цитата из Мауро: "I can't determinate the root cause of this breakage, but it seemed to be associated with merging handling at stg or git." В любом случае, это было на грани hg, git и stgit - вряд ли вина Mercurial. Или ты подписан на девелоперский лист, где таки докопались до причин, и виноват был Mercurial?

> Оно примерно такое у всех DVCS

Это да, вобщем hg хорошая штука, я сам использую. Особенно хорошо что можно снапшоты из web-интерфейса качать легко. А с DVCS проблема в том, что обычному разработчику проекта не нужны _все_ версии, обычно только несколько последних, ну или последняя + возможнось взять избранные.

> В любом случае, это было на грани hg, git и stgit - вряд ли вина Mercurial. Или ты подписан на девелоперский лист, где таки докопались до причин, и виноват был Mercurial?

Я уж и не помню, давно дело было. Скорее всего проблема была в Мауро, тяжело ему из одной VCS в другую гонять.

> не нужны _все_ версии, обычно только несколько последних

Вот именно, _обычно_. Но иногда приходится организовавать исторические изыскания - и тогда наличие всех версий греет душу и помогает делу. А если ты еще в этот момент и без связи... 8)

> тяжело ему из одной VCS в другую гонять

Да, меня всегда удивляло, что люди используют Mercurial при взаимодействии с git-проектами. Неужели не я один ниасилил git? %)

Кстати, если ты в курсе дел с v4l-dvb - есть ли новости о поддержке Pinnacle PCTV USB Stick PRO?

> Кстати, если ты в курсе дел с v4l-dvb - есть ли новости о поддержке Pinnacle PCTV USB Stick PRO?

Это от usb id зависит, не совсем понятно что за девайс. Stick который Hybrid (TV+DVBT) поддерживается, обычный я тоже думаю работать будет. Может быть нужно будет поснифить немного.

> от usb id зависит, не совсем понятно что за девайс.

eb1a:2881 eMPIA Technology, Inc.

Как раз Hybrid TV+DVB-T

Он в общем репозитории уже?

К сожалению 2881 ни о чём не говорит, просто заглушка. Тогда тяжелее будет

http://linuxtv.org/v4lwiki/index.php/Em2880

вот здесь написано что supported, значит должно работать либо с главным, либо с http://linuxtv.org/hg/~mrechberger/v4l-dvb