Learn more about these different git repos.
Other Git URLs
The variables srclblds and dstlblds seem to stand for "source latest builds" and "destination latest builds" respectively. However:
The fact that dstlblds is always the latest builds for the tag causes this command it get things wrong:
This is a follow-up to #916
What should be semantics of cloning tag to populated one? I'm not sure if user has clear and relevant expectations in this case. Maybe it makes sense to raise a warning in moment when there is something in the target tag and refuse to clone. Maybe override via --force?
I think in cloning to existing tag case, we could have those choices below:
There are another problem might occurs:
When build n-v-r is in dstag's parent tag, and this package n is in srctag's package list, but there is no builds of n in srctag, neither n-v-r will be untagged nor n be blocked.
How to deal with this situation?
IMOO, there're probably 3 semantics of cloning tag operation.
No. 2 above seems impossible and meaningless
I think the expectation that a user has in the populated case is something akin to rsync. That is, do what is needed for the target to match the source.
With --latest-only I think we get it right, but without that arg, we're not currently matching order.
Though, you're right, the scope and meaning of the command is unclear. The name of the command does not match what it does.
I see two options.
We decide that this command does not fully support cloning onto an existing tag without --latest-only. We change the command to print a warning about the possible order issues.
We sync the order as we go. That means we account for the order though the process and perform the minimal steps to sync it. So, if src tag has (order latest last):
and dst tag has:
Then the steps we could take for foo are:
So the algorithm would look something like this.
For each package, consider the order of builds for that package in both src and dst tags. Call them order1 and order2 (latest last).
First, we note all builds in order2 that are not in order1. Those need to be untagged. Mark them so, and remove them from order2.
Next, we start looking through order1, starting with the oldest entry. For each such entry,
Then we repeat, moving up the entries in order1. As we go further up the order, all the work above only considers the part of order2 that is after the previous entries that we have already adjusted.
(yes, this is a little complex)
In this process, the relative order of tagging and untagging matters, so we can no longer bundle tags into one bin and untags into another. We'll need to do them as we go, or multicall them together in the right order.
If the dst tag has inheritance, this gets complicated, and might not even be doable. I'm not sure if we want to refuse to try, but we should at least warn about the case.
Or maybe if dst has inheritance, we only allow --latest-only.
Or maybe we ensure that we get latest right, but don't worry about the order of the builds below.
Metadata Update from @mikem:
- Issue set to the milestone: 1.17
candidate PR #1014
Commit 21c5bd3 fixes this issue
to comment on this ticket.