[darcs-users] darcs cp

[David Roundy]

On Sat, Jul 10, 2004 at 01:17:00PM +0100, Ian Lynagh wrote:
> 
> Hi all,
> 
> Why is there no "darcs cp" command?
> 
> If I have a large source file that I want to refactor into two smaller
> ones then I'd like to "darcs cp curfile newfile" before deleting chunks
> from each so that the history of newfile is complete.
> 
> google has just found me
> http://www.abridgegame.org/pipermail/darcs-users/2003/000550.html which
> seems to conclude that darcs cp wouldn't be useful as "if a patch type
> doesn't commute then its only benefit is in reducing repository size",
> but I don't think that is true as there is also the history issue. Or am
> I missing another way to do what I want?

You're right, there is the history issue... when I wrote that, I think
darcs had no way of browsing the history, so that wasn't a big problem.
But the problems involves would be significant.  How would one merge a cp
patch with a change to the file?

Actually, for splitting a file, there's no space gained by using a darcs
cp, since you'd have to delete the unwanted content, which is as
space-consuming as adding it.

The inverse of a copy patch would merge identical files.  In this respect,
it would be similar to the rmfile patch, which can only remove an empty
file.

Now that I think about it, commutation issues may not be so bad.  Any
patches to the original file, when commuted with the cp would give two
patches, one to each file.  Then when they get commuted back, they'd result
in a single change again.  Internally this would be done with "split"
patches, which are used when a commutation of a single primitive patch
produces multiple primitive patches, that need to be combined again on
recommute.  The cp patch still wouldn't support any smart merging, though,
and would definitely complicate the worst-case merge conflict scenarios.

Actually, there are scenarios where a darcs cp with the above-mentioned
commutation behavior *would* simplify certain things.  For example, one
could have a repo with a single "copyright" header, and darcs cp from that
to all new files.  Then a change to the copyright header, in a repo without
any of the darcs cp's in it, could be pulled into all the child files at
once.

I'd rather have, though, an interfile darcs hunkmove.  This would more
often be closer to what one actually wants (although it wouldn't help in
the copyright business), and wouldn't involve splitting or merging, so its
inverse would be the same sort of patch.  But before tackling an interfile
hunkmove, I'd want to have an intrafile hunkmove, which has long been on
the list of desirable patches.  Of course, the trouble with any hunkmove
patch is figuring out how to generate the actual patches.
-- 
David Roundy
http://www.abridgegame.org