[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bzr repository ready?
From: |
Karl Fogel |
Subject: |
Re: bzr repository ready? |
Date: |
Fri, 06 Feb 2009 15:19:07 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
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