I’m not certain just when it started (2.0 or later), but when I perform a merge that includes replicated files in DevonThink Pro Office 2.0.3, I wind up with replicants of the merge result scattered around my database. I haven’t tested it thoroughly, but I assume that replicants of the merged file are being created wherever you’d find another replicant of an existing file. For example, if I have several files in two folders, and most are replicants that show up in both folders, then when I merge all the files in one folder a copy of the merge is replicated to the other folder.
Is this expected? If it is, can I turn it off? I have, er, a lot of these merge replicants scattered around now.
Merging retains the tags now, this has been requested by our users. To disable this, you could exclude groups from tagging (see Database Properties panel) or simply remove the tags via the Tags bar after merging. This should “kill” the replicants.
The tags are getting replicated, but that’s not the issue (I think). The folders that are getting the replicants of the merges aren’t sorted by tags or anything. The contents are manually added and organized.
If the tagging of the replicants is causing the merged file to replicate itself across other folders, what was the reasoning behind that feature? I always figured tags as labels that could be used for scripts and sorting, is there more to them than that?
In case of DEVONthink, tags are groups (and vice versa) and therefore tagging means replicating (and vice versa). If you don’t like this behaviour, you can disable this via the Database Properties panel and then all groups outside the “Tags” groups are excluded from tagging. Or you can exclude individual groups from tagging via the Info panel.
Fair enough. So long as I can work around it I’ll be happy.
Maybe I’m looking at the purpose of merging differently from what is intended. Rather than merging with the goal of removing the original components, I merge to create one article out of several component sections. I keep the sections around so they can be edited and updated as needed (with different versions of the article for different platforms, which is why some sections are replicants and others are standalone files). Once updated I re-merge so I can just replace the whole thing rather than searching for the particular section on the site’s editor.
I’m guessing the purpose of replicating the merge is so that after a merge you can safely do a “remove all instances” of the components and not lose them from any groups they were replicated to.
I have, er, a lot of these merge replicants scattered around now.