Re: Source tree tidy

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 04/03/14 06:27, Ian Campbell wrote:
> On Mon, 2014-03-03 at 11:57 +0000, Andrew Cooper wrote:
>> On 03/03/14 11:51, Ian Jackson wrote:
>>> Andrew Cooper writes ("Source tree tidy"):
>>>> Looking through the root of the git tree, there are some files which
>>>> appear to be remnants of legacy source code management systems, and thus
>>>> are good candidates for deletion.
>>>>
>>>> >From bitkeeper:
>>>> .bk-to-hg
>>>> .rootkeys
>>>> .hg-to-bk
>>> I have no idea what these are but if we think anyone is using
>>> bitkeeper I would want an explanation of what they are and what
>>> implications there might be for removing them.
>>>
>>> But probably no-one is using bitkeeper, in which case we can remove
>>> them.
> I think it is vanishingly unlikely and IIRC the bk->hg transition was
> long before Xen 3.0.0 even.
>
>>>> >From mercurial:
>>>> .hgsigs
>>> Doesn't this latter contain information which hg needs if it wants to
>>> verify a signed tag which was made with hg ?
>>>
>> In theory, yes, although in practice the public half of the key used to
>> sign them doesn't appear to be published.
> Isn't it 0x57e82bd9? That one is on the keyservers. I don't have an hg
> tree handy to check it is actually used (we use it now though I think).

So it is.

>
>> The signed tags cover 4.1.0-rc1 thru 4.2.0-rc4, missing the releases
>> themselves, so are not particularly interesting to verify.
> Since the release (and therefore sigs) would have been made on the
> X.Y-testing.hg tree perhaps the release tags will be in the release
> branch version of the file? Although maybe the original hg->git
> conversion didn't pick that up?

They have indeed, and the 4.1 and 4.2 trees have further signatures in
them.  4.3, 4.4 and unstable hg trees all have the same set of sigs,
which do not include the releases.

~Andrew