Notice that if you look at file A you’ll see it has one replicant.
If you look at file AR, it, too, says it has one replicant.
Both are references to a file stuck away in Devonthink’s internal archives. Neither is a real file. Both have a replicant.
If you replicated either of the replicants, then all three would each say they have two replicants. You don’t have to replicate the original, because the concept of “original” has no meaning.
Imagine an SQL database. You run a query of people who are members of the Rotary Club, and there’s old Farmer Brown. You run a query of customers who are Kiwanis members, and there’s Farmer Brown again. If your queries included a count of how many other clubs each person belonged to, both reports would show Farmer Brown is a member of one other club.
Which one is the original Farmer Brown? Neither. He just showed up in two reports.
In Devonthink terms, you had a group of Rotary members and a group of Kiwanis members. You put Farmer Brown in one of them and then replicated him over to the other - but you never put his file in the group. Devonthink parked his file in a safe internal location and then just included him in the roster of files for that group. That’s true for all files in Devonthink.
The real file with your notes on Farmer Brown is tucked away in Devonthink’s internal archives. Both groups showed that file as a member.
Exactly. The concept of the “original” is dissolved as soon as you create a replicant. Both files are red, so they are both replicants. If an “instance” is deleted, one original is created again.
DT should therefore indicate that there are now two replicants (not one). The other “instance” would be a duplicate. In my example, there are 2 replicants and 0 duplicants.
But none of this matters, you just have to understand what the developers actually mean.
I think it’s simpler than that. If Devonthink detects additional references to a file in a group, it prints it in red.
If you delete the other instances, there’s no need to create an original. It never moved. DT just stops printing its name in red.
Even moving a file to the Trash doesn’t move the file. Do a Reveal in Finder. Then move the file to Trash in Devonthink. Do another Reveal in Finder and you’ll find it’s still in the same place it was before.
The members of a group are not determined by where they are on the disk. A group is like a report of what Devonthink has flagged as being a member. Replicating a file tells Devonthink to report it as being in another group.
These mechanisms are why Devonthink’s tagging is so wonderful. Tagging a file creates a reference in a special group for the tag - a tag is a replicant.
Gentlemen thank you all for the interesting discussion. i think we have all understood each other correctly. I just wanted to say: If the number of replicants that DT states does not correspond to the number of actual (virtual) files, then there will always be users who ask for an “original”.
It is an interesting question to the devs and community - do we need to save the “genealogical info” about our files? ))
Say, file A is the original, file B is its rep or dupe, and file С is the rep or dupe of file B. Is there use cases, which could make this functionality worth the development?
“Tree of dupes” could show us the ways how the file evolved with time and context and give a quick jumps to all versions, even if they become very different…
“Tree of reps” - ? Tagging history? Evolution of alternative classifications? The contexts where we used it the most?
A replicant is never a “file”. It’s only a pointer to a file. So,
A is the file, pointed to by B, C, and D. And nothing is ever going to “develop” here because they will all show exactly the same content at any given moment.
And there’s a very important difference between a duplicate and a replicant: The former is a separate file, the latter isn’t. You change A, of which B is a replicant, and B changes accordingly. You change B, which is a duplicate of A, and A doesn’t change. Nor are the two duplicates of each other any longer, strictly speaking.
The files? With duplicates, there is no single file. And you could use versioning, if you really want to see the evolution of your data. Either in DT or with other tools.
Of course I’m aware of it The file is the same, the pointer is different. We can store the info in this pointer or whatever meta address part of it, which is unique to the rep instance. I’d even give user a choice when adding a custom metadata - whether make it unique to the rep instance or apply to all reps, as it is now. And, of course, this changes slightly the current concept of replicants. The question is whether it worths the development.
Again, look a bit wider - you connect all these versions with a single tree of “file/info” evolution. Versioning, you mean, gives you just one path (not even a branch) from this tree. This could be an interesting feature of knowledge management (knowledge is a tree, not a path).
Before C.Darwin, different species were “different files”, but in “Origin of Species” he suggested a “tree” for all of them, made it before DNA became a scientific term, and outrun genetic research.
I’m not sure, and I don’t want to talk nonsense. That’s why I’m asking.
If you search for a file (with reps), DT naturally only shows one instance in the results. If you select the file and execute cmd+R, DT seems to jumps to the group with the “oldest” rep. So the “original” … yes, yes, I know that doesn’t exist. But I have to name it somehow.
What happens if this rep is deleted? Does DT then jump to the “second oldest”?
When you show info on a file that has a replicant, DT states there is one replicant. It’s just DT’s display convention, you’re looking at a file that has one other replicant.
The dropdown “instances” field in the Info shows all instances. A file listed as having one replicant will show two instances in that drop-down.
Regarding how many replicants a file has, wouldn’t it be confusing to show there were two replicants but only show one other instance?
The way it is now you have a file. It has one replicant. The instances drop-down shows your file and its single replicant.
This thread is a bit mind-bending. People do get in a tangle with replicants and duplicates (I did too when I was new to using them). It’s quite simple really:
Replicants are basically a mirror of a file. They’re all identical and any change you make to one replicant affects the file. No One True File exists until all mirrors are deleted. The final location of a previously replicated file will depend on which mirrors you deleted.
Duplicates are clones of a file. All clones exist independently. Deleting one clone does not affect the properties or existence of another clone.
Personally I prefer replicants over duplicates. For me, I find it too risky to have duplicates, where I might amend one file in one location and forget that the change isn’t across all versions of that file. Replicants are useful if you navigate by groups, because you can put a file in multiple places. It’s less important for tagging, where one file can have multiple tags to achieve the same result.
The best way to become familiar with replicants is to play with them.
I like to learn as many details as I can about Devonthink because I use it heavily. Some databases are little more than organized containers of files. Some databases are notes about something I’m learning and help with things like see-also.
At this point, I’m still surprised by new ways to use Devonthink or features I’ve overlooked, but it never surprises me by the way it manages files, tags, groups, or basic structures. Devonthink is consistent, logical, and very reliable. It’s worth it to learn those details.
Drink deeply of this particular Koolaid. It’s nutritious!
The file is the same, the pointer is different. We can store the info in this pointer or whatever meta address part of it, which is unique to the rep instance. I’d even give user a choice when adding a custom metadata - whether make it unique to the rep instance or apply to all reps, as it is now. And, of course, this changes slightly the current concept of replicants. The question is whether it worths the development.
