Re: bzr repository ready?

[Karl Fogel]

Jason,

The conversion seems to have a tag problem: there are a bunch of tags
that are in CVS, and that made it into Git, but that do not seem to be
present in the emacs-merges-ce Bazaar repository.

To see the list of missing tags, visit

  http://www.red-bean.com/kfogel/emacs-bzr-switchover/sanity-checks.txt

and search for "Check that all tags are present".  That section shows
how I generated the lists of tags, and how I compared them, and shows
the results of the comparison.

(I also want to look more closely at the "Spot-check a branch-sync change"
section in that file, but the tags thing is most important right now.)

Thoughts?

-Karl

Karl Fogel <address@hidden> writes:
> Andreas Schwab <address@hidden> writes:
>> Karl Fogel <address@hidden> writes:
>>>    "Spot-check a branch-sync change."
>>
>> This is another merge commit that your tool appears to mishandle.  When
>> checking out the cvs trees before and after the change I see no
>> difference to the corresponding git trees, except that the files that
>> were renamed in this merge appear under both names in the older CVS
>> checkout.  The latter may be a limitation of cvs when checking out a
>> date, or it could be due to an invalid direct manipulation of the cvs
>> history (manually adding a branch tag instead of going through cvs
>> add/rm).
>
> Or more likely, direct manipulation of the files in the CVS repository
> (i.e., renaming).
>
> Thanks.  I probably could have done the same checks you just did, but I
> have to admit that by that point I was ready to be doing something else
> for a bit (these verifications take a lot of legwork :-) ).
>
>>>    "Check that all tags are present."
>>
>> These tags are all present in the git tree.  May be a bug in the
>> git->bzr conversion.
>
> Yup.  We'll look into it.
>
>>>    "Check that all branches are present."
>>
>> Likewise, the branches are all present in the git tree.
>
> Okay, thanks.
>
>> The master-UNNAMED-BRANCH contains changes belonging to revisions that
>> are unreachable from any branch tag.  The name was constructed by
>> parsecvs since such unreferenced commits cannot exist in git.  Actually,
>> this branch combines several such anonymous branches, but parsecvs could
>> not tell them apart.
>
> I never would have thought of that.  Hunh.  Thanks.
>
> -Karl