In DTPO, I just replicated a tag into a group (where I was gathering replicants of all items on a certain topic)… and that tag suddenly turned (permanently?) into a GROUP rather than a TAG. And now the “Tags List” at left in the main DT window is showing it AS a group, rather than a tag – which means I can’t use it to tag new items!
Hope that’s clear (as mud), and that someone can tell me how to turn that group back into a tag! (I know tags and groups are actually the same thing in the DT architecture, but they function differently in use!)
I’ve attached a screen grab of the Tags List so you can see that it includes a bunch of tags … with one group among them!
I find the easiest way to gather all my material on a given topic into one place is to do a general search of my database for the relevant keyword, then replicate all items of interest into a new group named for that keyword (in this case “Malanga”). One of the items turned up in the search was the Malanga tag, which I then replicated into the new group I had created – so that all items tagged “Malanga” would be in the new group.
That’s where things screwed up, obviously…
Aha – Thank you, Korm.
A question: Does DT distinguish between the “original” version of an item, and replicants then made from it? That is, if I have two replicants of an item, and delete one, at random, does the remaining one simply then become the same as the original item? Or in general do I have to take care to treat the “original” item differently than subsequent replicants? (The way aliases and originals are different in Mac OS).
For the purpose of your situation, korm’s reply is completely accurate-you can delete either instance of the replicant(s) and not affect the other(s).
Having said that, there are a couple of situations where there is a difference between the original and all replicants. First, documents returned in a search or smart group will always give the location of the ‘original’ (for lack of a better term) document. If multiple replicants are created and the ‘original’ replicant is deleted, then the new ‘original’ will become what was the first replicant (now returned in searches and smart groups) that was created, and the second replicant becomes the first replicant, and so on. Not really a significant difference, but if you’ve ever wondered why a particular replicated document’s path appears in a search, this explains it.
The more important difference is when documents are indexed in the database. It is possible to index a ‘FolderA’ from the Finder, replicate some of the folders contents into other groups in the database, and then delete the ‘original’ document from ‘FolderA’. Now the contents in the indexed group (FolderA) no longer match the contents of FolderA in the Finder, which can cause confusion at some point. So in the case of indexed documents, I have found it best to delete the replicants as needed, but always leave the ‘original’, indexed document in the groups that matches its location in the Finder.
All VERY interesting – Although I could swear I have noticed (and been surprised) that later replicants’ have been returned in searches, rather than the “original” doc. But is that simply impossible, and my memory is playing tricks on me?
That would be true, for example, when doing a search from the toolbar and selecting the option ‘In selection’. However, the Global Search window (in my experience*) will return the ‘original’ document.
Hey Gents – So I just tried a search, in both the toolbar and global search window, and BOTH attempts most definitely pulled up the most recent replicant of the searched-for item, NOT its “original” version!
So my memory ain’t faulty (on this single occasion, at least).
I agree it WOULD make sense if it pulled up the original, but that don’t seem to be the case (unfortunately). Maybe a fix is needed in next release?
(Screen grab attached – the second item is what I was looking for, and you can tell its a later replicant because it’s in the folder where I store such marked … “replicants”!)
That’s not something that will be fixed, as I’m sure DEVON doesn’t think it is broken. Do you have a screen shot of the Global Search window results for comparison?
I’ve attached a screen grab of the global search (relevant item is the third one down), and also the “get info” screen for that item, which shows it replicated to three places, the “original” one being in the folder “lesser primary bio texts.”
Guess it isn’t that big a deal, but I wish it did work as you thought it did, Greg!
You might want to experiment with this some more, preferably using new documents that were never before replicated and affected by the tag turned group issue that you originally reported. It’s also a good time to check on the health of your databases by running Verify and Repair. I’m allowing for the possibility that DEVONthink doesn’t work 100% of the time as I thought, but in nearly 15 years of using DEVONthink I’ve never seen the replicant behavior not work as I described.
Nevertheless, if you create two groups “A” and “B”, create, import, or index a document into “A”, replicate that document to “B”, and then inspect the instance of the document in “A” using Show Info > Path and do the same for the instance of the document in “B”, the Path is the same.
Document groups, Tags groups, Smart Groups – all of these in DEVONthink are fictions – they have no physical reality on disk, they merely have a presentation in the UI. Neither group “A” or “B” has a location in the file system. Only the document at the Path shown in Get Info has a location in the file system. “Original” probably has no meaning other than a process for DEVONthink in the background to keep track of replicants and duplicates. “Original” does not mean there is a path in the database that is “more real” than another path. Each replicant has the same physical path.
If you delete the instance in “A” the instance in “B” remains. If, instead, you delete the instance in “B” the instance in “A” remains. The only physical “original” in the file system is the file stored at the location shown in Path. (For created/imported documents, Path is a location within the Files.noindex hierarchy within the database package. For indexed documents, Path is the location of the document in the file system outside of the database package.)
That is correct, and (unlike deleting instances of replicants of documents imported in the database), deleting instances of indexed documents can result in a changed Path location of the document in the file system. This is possible today with triggered scripts, and will certainly be true in the future if DEVONthink adopts a more ‘Finder-like’ behavior with respect to indexed documents, as has been discussed. There can be unexpected consequences when deleting replicants of indexed documents from the group that was initially indexed.
