Re: bzr repository ready?

[Karl Fogel]

Thanks for the analysis, Andreas.  There appear to be no problems here.
You're right, I forgot about vendor branches (that part wasn't really a
script, I just of waved 'sed' and Emacs macros around in various ways,
but I forgot to account for vendor branch numbers).

-Karl

Andreas Schwab <address@hidden> writes:
> Karl Fogel <address@hidden> 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.