Wondering how to fix up a category of import failure
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. 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) C) Nuke the entire import, and let the importer do better this time. D) Something else? Max. signature.asc Description: OpenPGP digital signature -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Wondering how to fix up a category of import failure
Max Bowsher _...@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 -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Wondering how to fix up a category of import failure
On Thu, 23 Jun 2011 10:48:05 +0200, John Arbash Meinel j...@arbash-meinel.com wrote: I personally like C when reasonable. However reasonable means that nobody else has started working on the project (since creating new revisions will break their existing changes). Otherwise, I would go for B. branch-nick doesn't mean all that much. I agree that B is likely the best option here. Thanks, James -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
