Same working environment on two Macs?

Hi, I am new here, testing DTP (trial period).

I have a home and a work Mac, they are synched via iCloud (so the Document and Desktop folders have the same content, and also folders are on the iCloud account, Photos, Movies etc. are also synched via iCloud). I want the same working environment on the two Macs.

How should I set up DEVONthinkPro on the two Macs especially as concerns synching, so that I can work on the same databases on both Macs?

Note: It is not optimal to add your Photos library to a database. In fact, you should be curating your database, not just adding data because the data is there. DEVONthink is not a Finder replacement.

PS: I have responded in your support ticket.

1 Like

That is clear now, and many thanks for solving the problem, Jim!
If I don’t sync content of indexed files (which was my second mistake – the first was to index everything :slight_smile: ), the two Macs will see the same databases including embedded items. DEVONthinkPro will take care of synching the the databases between Macs and Apple iCloud service will take care of synching documents in Desktop and Documents folder and media files. So, I think this is the answer to my question.

I am testing the Devonthink for my purposes…
May I ask for some elaboration and advice about this scenario of two MACs please?

I have iMAC and MBA and a NAS storage where I keep everything.
so i understand that i need to create SyncStore.
will place it on the NAS.
on my local iMAC DB I want to see everything. I will have both imported as well as indexed documents and other stuff.

so if I sync all the local iMAC DB that means I will have ALL THE FILES inside the syncStore ?!
if I have 10TB of stuff on the NAS and for the argument sake I index all of them. that means the SyncStore will be 10TB size ?

if so, than the way to bypass this is to divide the stuff I really need on the MBA to be placed inside separate DB (on iMAC) and sync only this DB?
basically the question is whether i can control the sync only on the DB level? not on Group Level or tag levels? right?

in addition I have a dropbox with stuff. as I have a home NAS , I dont really need to use the dropbox as a syncstore location. but I do have files there. and in principle I would like to avoid duplicity in files and storage. so I am confused as to whether I need to create a separate DB for dropbox inside the iMAC DEVON instance ? it will be synced with MBA db via the sycnstore I assume.

any suggestions are welcomed in terms of how to go about all of this.
feel a little lost and confused…

thanks

I was hoping that you could explain why it is not optimal to add your Photos library to the database? I think this may have been where some of my hard drive difficulties came from. I did this and then deleted that database and now my photos won’t work on my macbook air computer

My comments were regarding a practical view. See:

How did you add the library to your database?

I had actually indexed it, for a specific reason I can no longer remember anymore. I guess I somehow thought that it would help me to keep my photos organized, and I think I was curious about the AI capabilities in relation to grouping some of my photos together for me as opposed to having to do the grunt work of maintaining it myself. I didn’t notice any difficulties with my photos through icloud until I had deleted that database and everything in it that hadn’t already been uploaded to my photos app, which is the only app I use anymore, especially now that they added aperture capabilities to it.

Well, indexing the Photos Library.photoslibrary would require descending into the internals of the package and indexing particular parts of it.

Not only would this be very dangerous with the tighter Finder integration in DEVONthink 3, I hope @cgrunenberg will detect or disallow this kind of indexing. Modifications, reorganizing, and deletions in DEVONthink would affect the original files, like this renaming.

Just as people shouldn’t mess about in the internals of a DEVONthink database, this is a bad idea as well.

Duly noted, lesson learned…hopefully anyways. Thankfully I didn’t really mess around with anything in there too much, and if I did I just haven’t noticed how it’s messed with my data yet.