The Problem
Suppose there are two packages which have undergone independent development for a while:
However, suppose that now the developer decides that it's pointless to have these two pieces of code in two separate packages. They would like to combine the two packages into a single one. Maybe they would make package B into a subdirectory of package A.
Unfortunately, they forgot that there was on open branch in package B with an important change:
Now they would really like to merge those changes into the contents of package B, even though they now exist inside package A:
Why is this important?
Several other modern revision control systems support this. But is it worth supporting in a Vesta context?
The commonly cited use-case is making an entire separate project, usually something like a library, into a sub-directory in a project making use of it then continuing to merge updates from the other project into the files in the sub-directory. That's sort of pointless in Vesta, because you could just have the build system do that. In fact, we wouldn't want to put all the sources used by a single project in one package, since they include the entire tool-chain.
However the more I think about it the more I see other potential use cases that make more sense in a Vesta context, particularly as Vesta gains improved merge capability. Currently the division of sources into separate packages in Vesta is shaped by the lack of sophisticated merge capabilities and the locking semantics used to name new versions with sequential integers. Once Vesta has more advanced merging capabilities, it might be very attractive to pull together multiple separately versioned packages into a single Vesta package. That makes this sort of merge-across-package-fusion capability potentially much more important.
Support in Other Systems
monotone (see also ToolComparison/Monotone) can do this with the restriction that one project must become a sub-directory of the other. (In other words, you can't simply throw all their files together in one directory.) A later change could rename the other project's files into other locations, but the operation that combines two projects must place one in a sub-directory of the other. This seems like a reasonable restriction.