fully working move --from --to (not release quality)
authorJoey Hess <joeyh@joeyh.name>
Mon, 23 Jan 2023 19:36:06 +0000 (15:36 -0400)
committerJoey Hess <joeyh@joeyh.name>
Mon, 23 Jan 2023 20:12:33 +0000 (16:12 -0400)
commitf5f799f17e8749c2ee6ceba29d2d18a644e8710e
tree6a91ee305bb017b014e776264732d0988d8c9ccc
parent1abd457e98dbe3b7d96227f16dc79fde6f5b59b8
fully working move --from --to (not release quality)

When the destination already has a copy, it behaves the same as
drop --from really, but display it as a move and implement it
reusing the factored out code from fromPerform.

(Note that willDropMakeItWorse never returns DropAllowed in that
situation, because it's told that dest has a copy. So numcopies is
always checked.)

And when only the source and not the local repo or destination have a
copy, do the full copy from source to local, then copy from local to
dest, then drop from local, then drop from source dance.

This is complicated by fromPerform being hardcoded to assume there is a
local copy, but the local copy has already been dropped. That's why
it uses cleanupfromsrc RemoveNever to avoid the code that makes that
assumption, and finishes with a call to dropfromsrc.

And, since the location log has not yet been updated, checking numcopies
was not working, until I added UnVerifiedRemote dest to the list of
things to check.

This is not yet quite mergeable though. There are two things in the
comment above fromToPerform that are not implemented yet: Checking the
location log before dropping the local copy, and locking the temporary
local copy for drop.

Sponsored-by: Dartmouth College's DANDI project
Command/Move.hs