Re: bzr repository ready?

[Andreas Schwab <schwab@linux-m68k.org>]

Karl Fogel <kfogel@red-bean.com> writes:

>   $ diff -u cvs-all-tags bzr-all-tags | grep "^[+-]"
>     --- cvs-all-tags	2009-11-18 14:54:59.000000000 -0500
>     +++ bzr-all-tags	2009-11-18 15:13:28.000000000 -0500
>     -DAVELOVE
>     +EMACS_20_1
>     +EMACS_20_3
>     -FLYSPELL
>     -ILYA
>     -mh-e-8_1
>     -mh-e-8_2
>     -mh-e-doc-8_1
>     -mh-e-doc-8_2
>     -raeburn-tag-3-for-export
>     -small-dump-base
>     -URL

The raeburn-tag-3-for-export tag only exist in three files, two of which
are not *,v files.  The third file does no longer contain the revision
that this tag is referencing.  So for all practical purpose, this tag
does not exist.  The other missing tags (except for those that appear as
branches, see below) are due to bugs/limitations in cvsps and
inconsistent tagging (parsecvs can handle them much better).  I will
have to manually add them to the git and bzr repo.

>   The two tags that are present in Bazaar but not CVS are particularly
>   mystifying to me.  While 'EMACS_20_1' and 'EMACS_20_3' appear in
>   'bzr tags' in trunk, they do not appear in 'cvs log' output from the
>   top of the CVS tree.  I do not know where bzr got those tags from.
>   Since the CVS tag (e.g.) EMACS_20_2 exists, it is reasonable to
>   conclude that bzr is crazy and is getting _1 and _3 from somewhere.
>   But where?

Those are tags that I added manually.  I don't think that creates any
problems, other tags have been retroactively added in the past.

> * Check that all branches are present.  [?]
>
>   diff -u cvs-all-branches.out bzr-branches | grep "^[-+]"
>   --- cvs-all-branches.out	2009-11-18 16:52:50.000000000 -0500
>   +++ bzr-branches	2009-11-18 16:52:45.000000000 -0500
>   +Boehm-versions
>   +DAVELOVE
>   +FLYSPELL
>   +ILYA
>   +URL
>   -cedet-branch
>   -emacs-unicode

In my git repository, I created merge commits that merges the heads of
cedet-branch and emacs-unicode branch into the trunk and the
emacs-unicode-2 branch, resp.  Apparently bzr-fast-import does not
create a separate branch in such an event, but all the revisions are
present and referenced by the merge commit.  That is, if you removed the
cedet-branch and emacs-unicode heads from the git repo no commit would
become unreferenced.

>   "The Boehm-versions branch was a short-lived branch containing only
>    a gc directory.  It appears to be a mistaken checkin, the commit
>    that deleted the files has the log message 'Not committed to
>    branch, sorry.'."

Actually the Boehm-versions branch is a real branch in CVS, and I have
no idea why it doesn't appear in your list.  The files that are
referenced by this branch also appeared for a single revision on the
trunk, and were subsequently moved to the Boehm-GC branch.

>   He also said: "The Ilya_4_35 branch appears to be the result of
>   another git->bzr conversion bug.  It is an ordinary tag in git."  I
>   wonder if the same applies to ILYA now?  I could find out, but I'm
>   just going to send this mail now because I've been poking around in
>   CVS all day and I want to share some results!

Those extra branches are vendor branches.  They have very special
revision numbers (uneven number of digits, usually 1.1.1) that your
script miscategorized as non-branches.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."