Replicants are very useful. You can place it where you think you will need it, especially if you use groups as tags - very handy. You know that you can change any rep and be sure to see these changes in all other places, that you don’t even remember where. But here comes a question:
If you get the same source file (like that in the database) new version with multiple changes (say, by email), you can: find all these changes and make them with the same file in database. It is ok if there are not many of them, they are quick, and you see all of them, but what if not?
If not, you end up with two possible ways:
-
Reimport new version into database, and replicate it once again. It may be hard if you have many reps, and don’t remember where (you have to look into the info panel and replicate it one by one)
-
Just open the location of the source file in the Finder and replace the old version with the new one, with exactly the same name.
So, which way is right? Is there any downsides of the Way 2? Maybe there is some third way I don’t know of? Or it is possible to automate such a task?
You can’t “change the source file” of a replicant as there is no source file. Each replicant is the original or a clone.
Option 1 would be possible, if laborious.
Option 2 would not work since the new file is not the old file, regardless of the name or location.
It would be possible to index a file in a Finder folder and make replicants of it. Then if you replaced the file in the Finder, obviously by answering the “A file named ___________ already exists…”, the file would update in DEVONthink and the replicants would logically update as well.
Well, actually you can, and technically I wonder what is the difference between these two options:
(a) Open, say, MS Word file via the database (double-click). And changing it as we want. Then saving and closing.
and
(b) Taking already changed MS Word file with the same name (not from the database), and overwriting the file in the database (we open the location of this file using command “Show in Finder”, and then just copying the new file there, Finder asks if we want to overwrite, we say yes)
I tried it with a slightly changed file - it works, tried with completely different file (just changed the name) - it works too.
It seems to me that technically there is no difference for the database, but I’m not sure… Maybe it can wreck the database in some way? Or this new file will not be indexed in a proper way?
Option (b) may be much more simple if you have many reps, but I have to be sure that there is no any difference between (a) and (b), and I will not interfere with the base integrity.
Option A is using the term “change” in a different context. Obviously you can make changes to a file that has been replicated.
Option B would not be presented because it is not something we would advocate to anyone. So while it may be “technically possible”, it is inadvisable behavior. People should not be messing about in the internals of a database.
Your original statement was unclear whether it was an imported or indexed file.
Option B may or may not work, but I expect if it does work all replicants will be moved from their respective groups to the Root level of the database. I suppose one could experiment with this, but I agree with Jim that that the health of your database is more important than taking the risk of corrupting your data.
I’m sorry for unclear questions, Jim. I don’t want to put my base at any risk and mess around its internals, you are right.
But the task remains and needs to be done correctly and effectively. What if there be a new feature? To update the file in the database, if it had changed somewhere outside of it.
The situation:
You work with your file normally in the database, it has many reps in different places. Then you decide to send this file to your colleague. He (she) edits the file substantially, and sends it back to you. So, you need to update your version with a minimum hassle possible.
The solution:
You drag this file to your database (holding some modifier keys) and drop right over the file that needs to be updated (over any rep). Then the database does everything the rest: replaces the source file with the new one, holding all reps, reindexes it and does whatever else it needs to do. Nice and easy. Undo would be very welcome here, cause you can accidentally drop your file over some wrong one. And, of course accompanying menu command.
No worries.
The best option - and this is a very specific situation you are describing, not a general “everyone’s doing it!” situation - would be to index the file in the Finder. After you receive the file back from your colleague (ensuring they didn’t change the filename at all), you’d replace the file in the Finder folder. Then you’d select the file (or parent group) in your database and the file would be updated, along with all the replicants.
Thank you, Jim
Would it ba a good practice to make some folder on, say, DropBox like SharedDocs, which would allow a joint editing of documents.
Then find this folder on the Mac and index it in DEVONthink. This way any change in such docs (except change of the path and name) would be automatically reflected in DEVONthink.
PS
though I am a bit surprised that the situation I described is something rare… I do it often, and I know many people, who do it the same way… You send your docs for review, you receive periodically a kind of updated schedules, lists and so on, where you don’t need any versioning, you comment a PDF and send it back to the author… many different cases. May be my workflow is wrong or rare… Is there a place where we can ask people if they want this feature?
Sharing of documents that are on a cloud service and indexed in a DEVONthink database works fine. I do it with a group of us that are on the board of directors of a non-profit, using Dropbox. I also have done it with my wife as we collaborate on projects, by sharing the documents on iCloud Drive. I find it is also easier to roll back to a previous version of a document when using indexed vs. imported files (assuming the team is not using a unique document naming convention to identify revisions).
The “rare” thing I was referring to was your suggestion of dragging and dropping changed files into a database and having to update replicants / clean up, etc. That is why I suggested indexing, corroborated by Greg (who knows indexing into DEVONthink better than anyone outside our company).
A collaborative situation like yours is a very common use of indexing Dropbox folders.
If you were receiving files via a non-cloud method (like email), if the filename isn’t changing the OS will ask you to replace the file in the indexed location and that would also update the file in DEVONthink, along with its replicants.
Thank you all! I think this is a good solution with indexing Dropbox shared folders.
