I have read the DT manual multiple times. Can some soul explain what the meaning is of the “replicate” command, and how it could be useful.
I have no idea whatsoever what to do with it.
Suppose I’m delighted with the results of a Search and would like to make a new group in my database that contains those results. But I don’t want to remove the documents from their locations in my database groups.
I’ll create a new group folder to contain my Search results, then select all the results and Control-click, choosing the “Replicate To…” option with the new group as the target. Presto!
Or suppose I would like to ‘file’ a document in more than one group within my database’s organization. Select that item, Control-click, choose the “Replicate To…” option and select the next group that should incorporate that document. Using “Replicate”, there’s still only one copy of the document in my database, but I can assign as many group locations to it as I wish.
TXS for the explication.
Using “Replicate”, there’s still only one copy of the document in my database, but I can assign as many group locations to it as I wish.
Which means practically that I can “tag” a document to appear in different groups, without moving the document in the database or duplicating it.
Yep, that’s correct. There are some limitations, such as:
• Renaming a replicated item changes the name for every replicate.
• Searching will only return a match for one instance of a replicate (which I believe is the original instance in the database). You can navigate between instances of replicates using Go > Next/Previous Replicate, however:
• Replicate navigation seems buggy since a Next followed immediately by a Previous doesn’t return to the replicate where the Next originated although its group opens (if closed)
• Rebuilding a database may cause issues with replicates; I’m still investigating that.
I’ve previously written about how DT might work using an extended iTunes/iPhoto model, with groups being like playlists/albums (hierarchically organized if desired) and items added to them having “implicit replication”. I think something like that could simplify some of the scalability issues with managing larger databases that I’ve encountered. For example, you’d know that every item in a database is safely stored a single “library” and items could be organized by “replicating” them from that library into different structures instead of copy/moving the original items. Deleting groups/items wouldn’t remove the real items unless you explicitly wanted to. As it is now, there’s an overdependence (IMO) on the hierarchical structure of the database that can cause items to be unsearchably misplaced or even accidentally deleted. Making that hierarchy a virtual construct would be an interesting alternative.
I’ve been experimenting with using that sort of iTunes/iPhoto-like model in DEVONthink Pro the last few months by leaving most items in a single group and replicating them elsewhere as desired. It sort of works but the UI isn’t designed for that. For example, I’d like to be able to delete groups without accidentally deleting any non-replicate items that might have wandered into them.