Миграция с CVS на bzr + странные хотения с ограничением видимости некоторых файлов по http
Ivanov Anton
1) Мигрирую как лемминг, исходный CVS репозиторий довольно простой
(одна ветка).
Поставил bzr-cvsps-import, даже залил себе локально CVS-репозиторий
(в /Archive/cvs), настроил на него CVSROOT, пытаюсь конвернтуть
~/tmp$ bzr cvsps-import /Archive/cvs/ aivlib aivlib.bzr/
Creating cvsps dump file: aivlib.bzr/staging/aivlib.dump
и оно вот так вот висит зараза, хотя было бы чего конвертить... ЧЯНТД?
В принципе я готов и просто закатать под bzr текущее состояние, забить
на историю и начать жизнь с чистого листа, но может таки выйдет...
2) Скажем у меня есть некий проект, ветка со стабильной версией живет
на сервере, ее копия (другая ветка?) лежит на другом сервере для
раздачи через http посредством bzr. Но есть одно но - некоторые файлы
должны быть под bzr, но не должны тянуться через http. Скажем
исходники документации (картинки и .тех) - они безусловно должны
лежать под bzr в общем проекте для разработчика, но пользователям они
не нужны и даже мешают (лишний объем), а вот собранную в общий pdf
документацию разработчику под bzr хранить глупо, но пользователям она
нужна. Как это решить? Ветка на сервер для раздачи отправляется
скриптом
А..
Alexander Belchenko
> Доброй ночи всем.
>
> 1) Мигрирую как лемминг, исходный CVS репозиторий довольно простой
> (одна ветка).
> Поставил bzr-cvsps-import, даже залил себе локально CVS-репозиторий
> (в /Archive/cvs), настроил на него CVSROOT, пытаюсь конвернтуть
>
> ~/tmp$ bzr cvsps-import /Archive/cvs/ aivlib aivlib.bzr/
> Creating cvsps dump file: aivlib.bzr/staging/aivlib.dump
>
> и оно вот так вот висит зараза, хотя было бы чего конвертить... ЧЯНТД?
> В принципе я готов и просто закатать под bzr текущее состояние, забить
> на историю и начать жизнь с чистого листа, но может таки выйдет...
Я посоветую вам взять другой инструмент для миграции: fast-import плагин.
Пару лет назад я смог успешно конвертировать с его помощью один из
проектов. Вот мой опыт:
https://lists.ubuntu.com/archives/bazaar/2009q4/063651.html
Также имеет смысл ознакомиться:
http://doc.bazaar.canonical.com/migration/en/data-migration/index.html
--
All the dude wanted was his rug back
Alexander Belchenko
> 2) Скажем у меня есть некий проект, ветка со стабильной версией живет
> на сервере, ее копия (другая ветка?) лежит на другом сервере для
> раздачи через http посредством bzr. Но есть одно но - некоторые файлы
> должны быть под bzr, но не должны тянуться через http. Скажем
> исходники документации (картинки и .тех) - они безусловно должны
> лежать под bzr в общем проекте для разработчика, но пользователям они
> не нужны и даже мешают (лишний объем), а вот собранную в общий pdf
> документацию разработчику под bzr хранить глупо, но пользователям она
> нужна. Как это решить? Ветка на сервер для раздачи отправляется
> скриптом
Самый простой способ: это держать и исходники документации и готовую
документацию в одной ветке и не париться по поводу того, что они
пользователям мешают.
Другой вариант: разделить проект на подпроекты, исходники документации
будут подпроектом, который пользователи вытаскивать не обязаны.
Для работы с подпроектами будут полезны плагины bzr-externals или scmproj.
Ivanov Anton
Спасибо большое! Однако оно тоже не работает, но уже по другому:
/tmp$ bzr fast-export-from-cvs /Archive/cvs/aivlib project.fi
Executing cvs2bzr --dumpfile project.fi /Archive/cvs/aivlib ...
ERROR: Git output requires a default commit username
Export to project.fi exited with error code 1.
Попытка сконфигать git (указать ему user.name, хотя причем git вообще
здесь? O_O) ничего не дала.
Ivanov Anton
> документацию в одной ветке и не париться по поводу того, что они
> пользователям мешают.
Э... у меня большая часть проекта (по размеру) это .pdf с
документацией. Включение в раздачу ее исходников размер закачки практ.
удвоят - не то что там очень много, но это оскорбляет мое чувство
прекрасного;-)
Мне пока в голову приходит при заливке на сервер заливать все, потом в
ветке на сервере игнорить исходники документации, добавлять .pdf и
коммитить (все равно заливкой скрипт занимается). При следующей
заливке предварительно делать uncommit, тогда версия на раздаче будет
на единичку отличатся от того что реально в разработке, это можно
пережить. Хотя может есть какие то более прямые пути?
>
> Другой вариант: разделить проект на подпроекты, исходники документации
> будут подпроектом, который пользователи вытаскивать не обязаны.
> Для работы с подпроектами будут полезны плагины bzr-externals или scmproj.
Вот этого я немного побаиваюсь. Во первых я не силен во всей это VCS-
кухне, во вторых версия документации ИМНО должна быть четко привязана
к версии исходников, я стараюсь их править сообща.
Ivanov Anton
наводит на нехорошие мысли, что ж они импорт из cvs нормально сделать
то не смогли;-(
Alexander Belchenko
> Уфф... справился, спасла конвертация cvs->svn->fi->bzr. Но вообще то
> наводит на нехорошие мысли, что ж они импорт из cvs нормально сделать
> то не смогли;-(
Что-то у вас не очень хорошее с оригинальным репозиторием было.
А CVS просто уже не акутальная система. Поэтому инструменты не слишком
хорошо развиваются.
>
> On 21 фев, 11:42, Ivanov Anton <aiv.r...@gmail.com> wrote:
>>> Я посоветую вам взять другой инструмент для миграции: fast-import плагин.
>> Спасибо большое! Однако оно тоже не работает, но уже по другому:
>>
>> /tmp$ bzr fast-export-from-cvs /Archive/cvs/aivlib project.fi
>> Executing cvs2bzr --dumpfile project.fi /Archive/cvs/aivlib ...
>> ERROR: Git output requires a default commit username
>> Export to project.fi exited with error code 1.
>>
>> Попытка сконфигать git (указать ему user.name, хотя причем git вообще
>> здесь? O_O) ничего не дала.
>
Alexander Belchenko
>> Самый простой способ: это держать и исходники документации и готовую
>> документацию в одной ветке и не париться по поводу того, что они
>> пользователям мешают.
>
> Э... у меня большая часть проекта (по размеру) это .pdf с
> документацией. Включение в раздачу ее исходников размер закачки практ.
> удвоят - не то что там очень много, но это оскорбляет мое чувство
> прекрасного;-)
Может быть вы пытаетесь решить не ту проблему? Может быть пользователям
не нужно получать новый софт из ветки по http и они будут вполне
довольны использовать какие-то инсталляторы, или менеджеры пакетов или
еще что там есть нативное для вашей ОС? А может просто актуальная
документация в виде pdf должна быть всегда доступна на вашем сервере в
pdf виде, а из самой программы вы сделаете ссылку на документацию?
> Мне пока в голову приходит при заливке на сервер заливать все, потом в
> ветке на сервере игнорить исходники документации, добавлять .pdf и
> коммитить (все равно заливкой скрипт занимается). При следующей
> заливке предварительно делать uncommit, тогда версия на раздаче будет
> на единичку отличатся от того что реально в разработке, это можно
> пережить. Хотя может есть какие то более прямые пути?
Не делайте так, пожалуйста. Это верный способ в скором времени огрести
кучу граблей, плюнуть на всё и начать рассказывать какая bzr кривая система.
Если вам нужно держать вещи раздельно -- то и держите их раздельно, не
занимайтесь рукоблудством, даже если это делает скрипт на сервере.
Понимаете, даже тот факт, что вы на серевере заигнорите и удалите
что-нибудь, это будет уже в новой ревизии проекта, но старая-то история
проекта останется нетронутой, и если ваши пользователи вытягивают ваш
проект с историей, то они постоянно будут вытягивать даже то, что им не
нужно.
При этом конечно снаружи чувство прекрасного будет якобы не нарушено, но
внутри то по прежнему будет бардак.
>> Другой вариант: разделить проект на подпроекты, исходники документации
>> будут подпроектом, который пользователи вытаскивать не обязаны.
>> Для работы с подпроектами будут полезны плагины bzr-externals или scmproj.
>
> Вот этого я немного побаиваюсь. Во первых я не силен во всей это VCS-
> кухне, во вторых версия документации ИМНО должна быть четко привязана
> к версии исходников, я стараюсь их править сообща.
В exrernaks/scmproj привязка обеспечивается если вы фиксируете (commit)
проект с подпроектом вместе. Вобщем такой подход требует определенной
дисциплины, это да. Поэтому лучше не делить, а держать все вместе, пока
вам на САМОМ ДЕЛЕ не будет ТРЕБОВАТЬСЯ обратное, так что иначе вы не
сможете с этим жить. Поверьте мне, я проходил уже оба варианта. Везде
какие-то грабли есть.
Anton Ivanov
> Может быть вы пытаетесь решить не ту проблему? Может быть пользователям
> не нужно получать новый софт из ветки по http и они будут вполне
> довольны использовать какие-то инсталляторы, или менеджеры пакетов или
> еще что там есть нативное для вашей ОС? А может просто актуальная
> документация в виде pdf должна быть всегда доступна на вашем сервере в
> pdf виде, а из самой программы вы сделаете ссылку на документацию?
Можно и так, можно и так, можно еще как нить наверное. Мне пока интересно, чем
тут может помочь bzr;-)
У меня есть регулярно обновляемая последняя версия проекта. Оформлять ее в
виде rpm или deb пакета я не готов, хотя бя потому, что у разных польщователей
разные дистрибутивы с разными менеджерами пакетов. У пользователя есть
развернутая рабочая копия, и ее желательно именно обновлять с сервера, что бы
потом пересобирать не все (это длительный процесс) а только то, что нужно.
Т.е. именно VCS тут и карты в руки.
Ну и плюс описанные выше проблемы с документацией, которые возможно и
надуманны.
>
> > Мне пока в голову приходит при заливке на сервер заливать все, потом в
> > ветке на сервере игнорить исходники документации, добавлять .pdf и
> > коммитить (все равно заливкой скрипт занимается). При следующей
> > заливке предварительно делать uncommit, тогда версия на раздаче будет
> > на единичку отличатся от того что реально в разработке, это можно
> > пережить. Хотя может есть какие то более прямые пути?
>
> Не делайте так, пожалуйста. Это верный способ в скором времени огрести
> кучу граблей, плюнуть на всё и начать рассказывать какая bzr кривая
> система.
>
> Если вам нужно держать вещи раздельно -- то и держите их раздельно, не
> занимайтесь рукоблудством, даже если это делает скрипт на сервере.
>
> Понимаете, даже тот факт, что вы на серевере заигнорите и удалите
> что-нибудь, это будет уже в новой ревизии проекта, но старая-то история
> проекта останется нетронутой, и если ваши пользователи вытягивают ваш
> проект с историей, то они постоянно будут вытягивать даже то, что им не
> нужно.
Да, я об этом не подумал:-( Спасибо!