[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)


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


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.)



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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]