Wondering how to fix up a category of import failure

[vila]

>>>>> Max Bowsher <_ at maxb.eu> writes:

    > I've come across an "interesting" importer malfunction in some old branches.
    > Essentially, it appears that:

    > 1. the importer has imported a version

    > 2. this version has then been copied into future series branches by the
    > process of initializing new distroseries

    > 3. the importer has then re-imported the same version IN A LATER SERIES
    > ONLY, but with a different dpkg-source -x version or settings with the
    > effect of adding files such as .gitignore to the imported tree, BUT has
    > updated its internal meta.db but NOT moved the tag for the version

    > 4. now it complains that its meta.db and the tag are out of sync.

So either the tag or the meta.db should be fixed right ?


    > Options:

    > A) Move the tag to match what the importer expects. Accept that the same
    > package version tag exists (for example) in the maverick branch pointing
    > to r8, but in the natty branch pointing to r9, which have slightly
    > different trees.

    > B) Push the extra revision back into the earlier branches and move the
    > tag there too. (Even though the extra revision has a branch nick with a
    > later series name than the earlier branches)

A and B are about fixing the tag. Having a weird branch nick can raise
questions but 'nick' is the most reliable indicator either.

    > C) Nuke the entire import, and let the importer do better this time.

This will fix meta.db.

    > D) Something else?

I kind of prefer fixing meta.db. In the long term, the importer should
become more and reliable and some fixes will imply fixing meta.db.

So in the end, my vote is for C as it also means we can use the same
recipe to restore a sane state for the package for different issues.

       Vincent