Often there's the need to transform a type of SegmentStore (e.g. local TarMK) into the exact same counter-part, using another persistence type (e.g. Azure Segment Store). While oak-upgrade partially solves this through sidegrades (see
OAK-7623), there's a gap in the final content because of the level at which oak-upgrade operates (node store level). Therefore, the resulting sidegraded repository doesn't contain all the (possibly stale, unreferenced) data from the original repository, but only the latest head state. A side effect of this is that the resulting repository is always compacted.
Introducing a new command in oak-run, namely segment-copy, would allow us to operate at a lower level (i.e. segment persistence), dealing only with constructs from org.apache.jackrabbit.oak.segment.spi.persistence: journal file, gc journal file, archives and archive entries. This way the only focus of this process would be to "translate" a segment between two persistence formats, without caring about the node logic stored inside (referenced/unreferenced node/property).