OK, here is text from my duplicate uservoice:

Add "Copy" to commands in Items view.

In the Items view, we can Cut and Paste but there is no Copy command. Cut+Paste will cause a Move operation.

Optimally, I'd like to be able to "fork" an item (at least a file) by creating a new Copy/Clone of the item that shares a common history with the original item from the cloning point and backward in time, but that has its own unique history from the cloning point and forward in time. (This was possible in SVN, where it was possible to trace the history of a copied file back into the original file where it was copied from.)

AFAIK, such a Copy operation seems to be missing from Plastic which can only do a move operation. I can see that there may be technical reasons for this, but it would be very nice to have that feature in Plastic. And possibly, implementing such a feature may provide a key to solving the problems described in the following popular uservoice:
http://plasticscm.uservoice.com/forums/15467-general/suggestions/3311147-possibility-to-merge-independently-added-files-dir

That said, even if you are not going to implement a true Clone/Copy operation you could still add a Copy command in the Items view. It would then simply Add a (history-less) copy of the item when doing Paste (just as in Windows File Explorer). It would make these operations more symmetric and consistent. After all, it's a bit strange that we can Move an item inside Plastic but we need to go to the Windows File Explorer to make a simple copy of the same item...

More info about this on the duplicated entry: http://plasticscm.uservoice.com/forums/15467-general/suggestions/10882362-add-copy-to-commands-in-items-view

I've found another other feature request in User Voice: Support merging across files

This was raised after this one - and I think it would address the use-case better. I'm taking my 3 votes off this feature and putting them on the other.

Wow, I totally missed that there was a follow up comment.

Ultimately, I just to be able to trace the history when I see any end point file. How it works under the covers is less of an issue, so long as it's not too obtuse to make happen.

I've voted for this too: some things to bear in mind:-

1. Let's say the file 'foo.cs' is split via copying by somebody else on a separate branch - so I still see just 'foo.cs' on my branch. If I make commit modifications to it, then if the other person merges in my branch changes, they should get the opportunity to 'multi-merge' my changes made on 'foo.cs' into their 'foo.cs', foo2.cs', 'foo3.cs'.

2. This is a generalization of the idea of merging through file moves.

3. There should be some way of merging a split committed by somebody else into my own workspace with local uncommitted changes, similar to #1.

4. Mercurial also has this functionality. It allows a 'one-off' merge into each copy - once the merge is done though, subsequent changes to the original file are not merged in during later branch merges.

Hi Alex,

Well, it is a nice idea. This way when you look into file history you can see how a file was split into two or more...

It is not the first time we consider it. Old SVN had it too (some option in the copy command).

I'm thinking about how to implement it: maybe some sort of:

cm split foo.c foo-partial.c that simply links the two files or something similar.

Then some sort of special link between the revisions so that history can follow the links and so on... would it be fine? All including some sort of cool GUI :)

Maybe instead of cm split, some sort of "cm link" to add a "history link" between two revisions... what do you think? Sounds lower level but doable too :)