[devel] CVS import again (Re: [d-kernel] RCS files for kernel CVS)

[devel] CVS import again (Re: [d-kernel] RCS files for kernel CVS)

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 3701 bytes --]

On Tue, Nov 07, 2006 at 06:24:53PM +0300, Dmitry V. Levin wrote:
> On Tue, Nov 07, 2006 at 05:34:11PM +0300, Sergey Vlasov wrote:
> > Можно ли получить файлы *,v из kernel CVS с целью импорта их в git
> > частями?  Предполагается положить в отдельный репозиторий скрипты для
> > сборки; modules/*, вероятно, тоже придётся распотрошить по отдельным
> > репозиториям (но это будет несколько позже).
> 
> Попробуй rsync.altlinux.org::kernel-anoncvs

Попробовал.  Долго плевался.

Во-первых, обнаружилось, что changelog в некоторых случаях содержит явно
неверную информацию.  В частности, коммит с сообщением:

    Make maintainer scripts more friendly w.r.t. duplicate packages.
    build-packages.sh: when processing a package, move all versions except
    the current one to a dedicated old/ directory. removepackages: new
    script -- removes packages from the local root. installpackages:
    before installing a packages, remove other versions (use the new
    ./removepackages).

помимо файлов, которые им должны были затрагиваться (build-packages.sh,
installpackages, removepackages), также присутствует в файлах .cvsignore и
README.koi8 (причём у нормального коммита автор imz, а у этих - ns и vsu).
Правильный текст changelog для этих коммитов удалось обнаружить в архиве
cvs-kernel@altlinux.  Повреждённые коммиты датированы 2004-07-20 и
2004-07-23, а коммит, сообщение от которого заменило чужие - 2005-02-10
(при этом в архиве cvs-kernel@altlinux для него сохранилось совершенно
другое сообщение, содержащее мусор, похожий на содержимое буфера pcl-cvs).

Во-вторых, git-cvsimport даже на таком небольшом наборе файлов, как
содержимое корневого каталога kernel cvs, работает с вопиющими ошибками.
В частности, ветка std-2_4_22-patches после git-cvsimport отходит от
коммита "fix existing package check in build-packages-hasher (use aptbox
instead of system apt-cache)" (2004-04-03, на этом коммите стоит тег
std-2_4_25-alt6), в то время как parsecvs и cvs2svn начинают эту ветку от
коммита "more nodeps hacks" (2004-02-04, std-2_4_22-alt17), что вроде бы
соответствует реальности.

Наконец, структура бранчей в cvs в некоторых случаях вообще не поддаётся
описанию.  В частности, бранч maintainer-tools-local-buildtools с одной
стороны вроде бы отпочковался от бранча maintainer-tools-no-dup-pkgs - в
build-packages.sh,v написано:

	maintainer-tools-local-buildtools:1.11.2.1.0.2
	maintainer-tools-no-dup-pkgs:1.11.0.2

С другой стороны, если посмотреть на содержимое buildmodules,v:

	maintainer-tools-local-buildtools:1.11.0.2
	maintainer-tools-no-dup-pkgs:1.10.0.4

получается, что бранч maintainer-tools-local-buildtools вырос из trunk
позже, чем maintainer-tools-no-dup-pkgs.  Эту ситуацию parsecvs и cvs2svn
обрабатывают по-разному:

 - parsecvs производит maintainer-tools-local-buildtools от
   maintainer-tools-no-dup-pkgs, но при этом добавляет в тот коммит,
   который был сделан в бранч maintainer-tools-local-buildtools, изменения
   в файле buildmodules, сделанные между его версиями 1.10 и 1.11;

 - cvs2svn производит maintainer-tools-local-buildtools от более позднего
   коммита из trunk, при этом создаваемый cvs2svn в начале каждого бранча
   коммит "This commit was manufactured by cvs2svn to create branch..." в
   данном случае получается непустым - он содержит все изменения из
   maintainer-tools-no-dup-pkgs.

Впрочем, это уже скорее ситуация типа "garbage in - garbage out".

Кроме того, в этом же районе parsecvs создаёт ничего не меняющий коммит с
сообщением "file removepackages was initially added on branch
maintainer-tools-no-dup-pkgs"; git-cvsimport и cvs2svn не создают такого
мусора.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]