Hi
I’ve been trying to get my head around the difference between duplicate and replicate and still can’t see it. Could someone try to explain it simply for me and give examples of when it may be best to use each?
Thanks.
A replicant is a strange beast. There’s really only one file in the database, even if it has been replicated numerous times, in different groups within the database, with very little added overhead — just a few bits — for each instance. If any replicant is modified, all other instances are also modified. Unlike a file and an alias of that file (it makes a big difference which one is deleted), it makes no difference which replicant is deleted. The Name of a document that has been replicated is displayed in red italic font. Suppose a document has been replicated twice. There are now three instances of that document, all displayed in red italic font. It I delete any two instances, there is no longer a replicant and the Name reverts to regular black font.
Duplicating a file results in a new file that takes the same memory and storage space as the original. If there are two duplicates, and one of them is deleted, the Name of the remaining one reverts from bold, blue font to the normal regular font.
Example: When I start a new project in my main database, I’ll often replicate into the new project group some of the important references I intend to use for that project, so they are at my fingertips. But if I want to mark up or summarize or insert my own comments into a reference document, I’ll duplicate it into my project group, as I can “vandalize” the duplicate without altering my original reference documents, which I keep pristine and unaltered. Note: DEVONthink identifies duplicates not by Name, but by content. If I alter a duplicate’s content sufficiently, DEVONthink will no longer consider it a duplicate of the original document, and the Name will revert to regular black font.
Hope that helps.
6 Likes
One way to think about DEVONthink replicants is that they’re sort of like iTunes tracks in different playlists. Both are ways to have a single item appear in multiple locations.
2 Likes
Just to be clear, Bill: Let’s assume I have a PDF, which we’ll call A. I replicate it, and now have replicant B. Even though B is not a full duplicate PDF, even if I delete the original file, A, does B still exist?
Yes. But it can be easier not to think of any single instance of a replicant item as the original. Say you have a dozen replicants of a document, then and delete all but one, then that last one is the “original”.
2 Likes
OK, thanks for that. I suppose in that sense it differs from iTunes, in that one instance of a song in iTunes, in the “top level” Music category, is the original, and as such deleting it will cause a problem.
Right, other than it’s only a problem if you unintentionally delete it. 
You can also Option-Delete iTunes tracks from within playlists to delete them entirely from the library (and all playlists), which is similar to DT’s Data > Move All Instances To Trash (Option-Command-Delete).
All “original” items in iTunes (iPhoto, et.al.) are “stored” in its library and adding them to playlists is sort of an implied replication. I’ve long wished DT could better supported something similar, which has been exhaustively discussed in other threads. You can treat a single DT group as a library and explicitly replicate everything into different/multiple groups, but obviously that quickly gets tedious.
1 Like
Thanks for your replies, I think I have a grasp of it now.
Cheers
If you’ve still got doubts maybe create a “playpen” database to gain some experience using duplicates and replicants before using them for anything serious.
Looking at this more than a decade later, and this was a very helpful reply!
(especially due to the workflow examples)
3 Likes
Indeed. Bill was a brilliant man, a consummate communicator, and a good friend. He is dearly missed.
3 Likes
Ah, got it.
Difference between a copy, a link, and a symbolic link…
A duplicate is a copy, a replicant is a link, and an alias is a symbolic link, then.
That was useful 12 years later, thanks.