import: check if an orphan tag matches the imported tree in all cases
If we attempt to use an import tag, but the tree does not match, we will
orphan, but it's possible this is the *second* time seeing the same
publish event, in which case we should possibly use the orphan tag's
tree this time.
This assertion is complementary to the other. Also add a test.
---
Originally, I had included a change that automatically set the native
variable based upon the version passed in (so you only had to specify
one of version or native), but I'm no longer confident that is what you
want the API to be. This change is sufficient to catch the issue and
ensures 100% code coverage with the test.
git_repository: drop ensure_importer_branches_exist
Much like 1d658869b56b ("Create dsc branch on first use"), create the
pristine-tar necessary branches on first use, which all occurs within
the context manager in git_repository.py.
This should not result in any functional change, but should ensure there
are no side-effects of simply instantiating a GitUbuntuRepository
object and the helper function is no longer necessary.
LP 1733895
---
It is a separate issue as to whether these branches need to exist or
not.
It is possible that any given version might be an orphan import (due not
finding any changelog parents). When this happens, we want to ensure
that when importing the same (to-be-orphaned) publication record for a
different series, we simply use the same logic we have now for import
tags. That is, when determining what to do with a given published
version:
1) If there is a corresponding import tag for version
1a) If the tag's treeish matches, just move the branch
1b) If the tag's treeish does not match, orphan this publish
2) If there is a corresponding orphan tag for version
1a) If the tag's treeish matches, just move the branch
1b) If the tag's treeish does not match, fail (unhandled still)
3) If there is a corresponding upload tag for version
1a) If the tag's treeish matches, incorporate the rich history
1b) If the tag's treeish does not match, emit a warning but ignore this tag
2) is inserted by these changes.
A similar change should be done in the lookup of the unapplied changelog
parent itself, which previously only searched for import tags, but should
search for import or orphan tags. It is not incorrect to use an orphan
tag as a changelog parent, it just implies there is a break in the
publishing record relative to the changelog.
When os.path.join is given an absolute path as any component,
it resets the computed path to that value. This is obviously
the case in our usage (since we are appending a system path to
the snap's path). Fix this by abstracting out the root path and
appending the same relative path in both cases.
