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:

• clean all existing builds without inheritance, and then add builds(latest when --latest-only) from srctag as if dsttag is new one.
• use --force to force tagging builds which are in dsttag already. and clean/block builds whose pkg_name is not present in srcbldswith inheritance
• compare builds between srcblds and dstblds which are not only latest, whatever if specifying --latest-only, and then do the corresponding [un]tagging operation. Some builds in dsttag should be force-tagged to preserve the order.

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.

1. only keeping current pkglist, pkggrps, latest builds, configs are the same as srctag's, but any changes further on srctag and dsttag may cause different results. should it truly mean --latest-only?
2. ditto, but with the full builds(latest=False,inherited=True?), all changes should only occur inside dsttag. Without --latest-only?
3. totally same pkglist, pkggrps, builds, configs even parent tags except tag name itself.
   like:
   A1(inherits B,C) to A2(inherits B,C)

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.

One

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.

Two

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):

foo-3-1
foo-4-1
foo-5-1

and dst tag has:

foo-1-1
foo-3-1
foo-5-1

Then the steps we could take for foo are:

• untag foo-1-1
• untag foo-5-1 (avoiding require use of force tagging)
• tag foo-4-1
• tag foo-5-1

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,

• if it is also the oldest in order2, then we don't need to adjust
• if it is in order2, but the wrong place, then everything in order2 before that needs to be untagged. Mark them so and remove them from order2.
• if it is not in order2, then it needs to be added, and everything earlier in order2 needs to be untagged.

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.

candidate PR #1014

Commit 21c5bd3 fixes this issue