Two machines, 1 DevonThink repository?

I’ve used DevonThink on my desktop machine for some time now & quite like it. However, now that I’m using my portable machine over half the time (often unconnected to the net), keeping things up to date has become more difficult. I’m writing to find out if there’s a better solution than I have right now.

I use DT to keep track of the odds and ends of daily work including a daily log. I’ve been keeping the log up to date by keeping open an email message on my portable machine during the day and emailing it at day’s end. Then I have to merge the stuff into my regular documents on DevonThink later. With the pressures of the day, it often doesn’t get done for a while. It’s also not searchable when I can’t reach the desktop machine. In other words, it’s not working nearly as well as it did when I was on one machine.

I’m looking for some way to have separate copies of the database that can be automatically synchronized. Does anyone have any experience with this kind of situation that might help me out?



Dave, I’m not aware of any automatic two-way synchronization for DT databases that I would trust with my own data.

But I sometimes do modify the same database on two different computers, and then wish to send the changes to each database.

I use Tools > History. Just remember the date at which the last ‘equalization’ was done between the two copies of the database. Now on your notebook computer select all of the items that were added or modified after that date, and use File > Export > Files & Folders to a new folder created in the Finder to hold that exported material.

Perform the same operation on your desk computer. Now import (File > Import > Files & Folders) the exported material from the other computer into each of your copies of the database.

Suppose you were writing an essay and have made different changes to the document at different times on each computer. After the ‘equalization’ process you will have two copies of that document, which is proper. A simple overwrite would have lost information that might be useful to you.

I use ChronoSync … rview.html

While it will not let you recover two edits like Bill’s process suggests, you can have some excellent control over the backup of not only your DT files, but also any others. I am able to synch my mail, address book and cal so it is basically like I am carrying around my iMac when I have my MBP.

Thanks for the quick replies. It sounds like I can use ChronoSync to do what I want, esp. if I’m careful to sync work from the portable before making changes on my desktop.

Has there been any further word on DEVONthink Enterprise? It sounds like it may be an even better solution going forward.

Thanks again.


Just a quick note about ChronoSync, you will want to select “dissect packages” from the Option screen and I think you may then also have to select the packages box from the Analyze screen (not sure on that one). This allows ChronoSync to only sync changed files in the package of the DT database, if you do not check the dissect button it will back up the entire db and that can take a while if you have large files.

Sorry, do not know anything about the Enterprise edition.


I use backup software, and as a matter of fact I’ve got ChronoSynch.

But I’m not ready to trust it for two-way synchronization of my DT Pro databases between two computers.

All of the text-based file types are stored in the ‘monolithic’ body of the DT Pro database. Which is to say that they are not recognizable by another application as individual RTF, HTML, etc. files.

It’s true that ChronoSync can recognize problems when a file has been changed on both computers. " If both files have changed, several options are given so you don’t copy over a file you need". Which means that I would have to dither over the range of options offered, while not being wholly confident that those options cover the range of logical options that may be appropriate. If a choice is requested, I would be operating in the dark, as I can’t ‘see’ the impact of the option in a particular case, especially for the monolithic body of the database. :slight_smile:

My DT Pro databases are more valuable to me than any other data on my computers. I want to know exactly what’s going on with them.

So I do incremental ‘equalization’ of my DT Pro databases, moving only the added or modified content between two computers, using the History tool to identify them for export/import to the other computer’s database.

All I need to know is the base date at which the content of the two versions of the databases diverged (I can figure that out, if necessary, but it’s faster if I make a note to myself). The the process of equalizing the two databases goes very quickly, even with large databases.

Perhaps one of these days I’ll come to trust an application that does true two-way synchronization between copies of a database that have been modified on two computers. I’m not there, yet – but it would be nice. :slight_smile:

Full instructions here: … &view=next

Has worked flawlessly for me so far.


Yes, that procedure with ChronoSynch should work well for incremental changes to a copy of the database that hasn’t also been modified (i.e, as one-way incremental synchronization).

Eric uses rsynch in a similar way, with success.

I’m not ready to recommend (or use) automatic two-way synchronization of two modified versions of a DT Pro database.

BTW, if you simply want to transfer a working copy of a database from one computer to another, but you’ve got a multi-gigabyte sized database and your transfer rate isn’t all that great (e.g. an 811.b wireless LAN), here’s another suggestion.

Use DT Pro’s Scripts > Export > Backup Archive. I recommend it anyway, as it runs verification and optimization, then makes current backups both internally and externally. Those are Very Good Things, and I recommend saving that external archive to another computer or storage medium for safety in the event of something like a hard drive failure on your computer.

Backup Archive produces the smallest possible compressed and dated external version of your database. As it is zipped and contains no internal backup folders, the file size will be much smaller than if you were to merely zip-compress your database package file. That means it will transfer much more quickly over a slow network. To use it on the other computer, just double-click once to decompress it, then double-click the database package to open it under DT Pro on the second computer. If you wish to keep the same database name on the second computer, just rename the package file before opening it.

I think the only safe way to “synch” two copies of DT is to designate one as the master copy and make the other a backup. You can do this very quickly with a utility like Synchronize! X Plus from Qdea.

As Bill has noted, you can’t make an incremental backup of DT because of its current unitary structure. I make nightly backups to a Firewire Drive and they never take more than a few minutes.

If you want a database that’s available at two separate workstations, then you need a central server to house your DT application and datafiles. Network speed will govern the quality of service.

An alternative is to copy DT files in the Library: Application Support folder and swap them back and forth between the workstations, via an external drive.

I agree with Bill on the value of the Script -> Export->Backup Archive option. I use this daily to move the most recently updated version of my DTPro database to one of the two other computers I might be using that day. While my database (DEVONthink.dtbase) is 138MB, the exported backup (zip) file is only 51MB. Right now I’m able to use .mac as a place to store this file for pull down on the other machines but other times I just put it on a flash drive.

If I understand the History->import method, if you deleted a document in the database it doesn’t reflect this in the history file…so the database you update would still have the doc you deleted in the other file, right?

Think of the History tool as a flat-file view of the contents of your database. Although by default it’s sorted by the Age of items, you can use View > Columns to add additional sortable columns. Example: If you need to find all of the image-only PDFs in your database, sort by Kind and scroll to view PDF files (as opposed to PDF+Text files).

So you are correct in that History can’t ‘see’ into the other copy of the database. If you deleted a file in the copy that’s exporting changes to the other computer, that file will remain in the receiving computer’s database.

Normally that wouldn’t bother me. I’d rather have “too much” data than too little.

One more caution about using backup or synchronization software to backup or move a database to an external drive: the database should first be closed, in case there’s still something in RAM that hasn’t been saved to disk. Otherwise, errors could accumulate in the backed up or synchronized copy. That’s not a problem when using the Backup Archive routine. But it’s one of those little things that one should keep in mind, as some backup software isn’t smart enough to close files or databases before copying them.

I have not querried the ChronoSync folks about sync of mods on two computers to the same file - I will. In my case I would NEVER do that anyway, my action is to only work from one computer at at time, I leave home, I synch, the first thing I do when I get back is synch and then use just one computer. Seems to me that doing your approach Bill is just as time consuming as mine?


Perhaps, but my approach can handle situations such as those occasions when I’ve got another person working with me to add content to a project database, on two computers at the same time.

Next time that happens, though, I’ll probably experiment with having the database on a network server. NOTE: Only one person at a time can access a database; concurrent usage isn’t allowed. But I will play with one-way synchronization from each of the two modified versions to the copy on the network server. That may or may not prove useful.

Ah, now I see. Frame of reference thing - I do not yet enjoy the ability to have help in my research so it did not occur to me that this was your environment.

Still waiting for the ChronoSynch folks’ response.

As promised here is the unedited respone from ChronoSynch along with my question -

Does ChronoSynch facilitate updating two files that have been
modified in both places or no? If so, how do we set the synch up?

I will transfer your response to the forum as I am sure that many
will be interested and also to ensure those using your tool
understand the proper practice in order to preserve the integrity of
their files.

First I should state that my experience using DevonThink is limited, at best.
However, I think the scenario described is general enough to apply to many
applications. My comments will likewise be general enough to be applicable to
many different applications.

Most sync applications simply compare the modification dates of a pair of
files against each other, picking the most recently modified file as the
“correct” one. This could be disastrous because there’s no way to detect when
both files have changed. The most recently modified file will always prevail,
but that may not be the file that contains the bulk of the changes.

Instead, ChronoSync compares each file against it’s last known state. This
includes modification date and numerous other metadata - all of which is saved
in a synchronizer document. This allows ChronoSync to dutifully detect when
conflicts occur, providing the user with the option of deciding which file is
the “correct” one (you could also tell it to just use the most recent file, if
you’re lazy).

This said, there is always an inherent danger whenever synchronizing a set of
files that are actively being modified on both computers. If changes are made
on the left computer AND on the right computer before synchronization takes
place, there are going to be conflicts. The user will have to decide which set
of changes to use. No matter what, something is going to get the lost because
the user will have to pick one set of changes over the other. Hopefully, they
choose wisely!

The key to all of this is to discipline yourself to synchronize before
switching over to the other computer and vice versa. If/when you happen to
forget to do this, it’s nice to know that ChronoSync will step in and report
the conflict, alerting you to the situation.

A couple other aspects of ChronoSync that are relevant in such situations are:

  1. Package handling. Some applications store their data in “packages”, which
    are basically folders disguised to like like files. I believe DevonThink does
    this. ChronoSync’s default behavior is to respect packages, thus it treats it
    as a single file. ChronoSYnc detects changes within a package and propagates
    them up to it’s root level - the package as a whole would be considered
    modified. This results in it being copied as a whole. This is very important
    to maintain the integrity of data within the package. If this weren’t done, a
    sync application may mix & match the contents of the package, since some files
    on the left would be more recent than on the right, while others could be the
    reverse. This might be the issue that concerns the DevonThink guy the most.
    It’s really a non-issue as long as you don’t override ChronoSync’s default

  2. Archiving. ChronoSync has the option to archive files that are replaced
    and/or deleted. This feature is intended as a safeguard against accidental
    deletion/synchronization, although many users take advantage of it as a form
    of version control. Anyway, this pertains to our discussion because if the
    user were to “choose wrong” when resolving a conflict, an archived copy of the
    file that was accidentally replaced would still be available. It’s worth
    noting, however, that archiving replaced files is NOT ChronoSync’s default
    behavior whereas archiving deleted files is.

If I read this correctly, it is ill-advised to use the “dissect packages” option (regardless of the bi-directional option). What a pity. On the other hand: I just tried Bill DeVille’s recommendation via History, and I must say that this works great and far less cumbersome than I anticipated. Thanks for the tip!

I usually synchronize manually (using my iMac as the main workstation), but sometimes I forget this rule, and I discover that I must have been working on both machines without proper syncing (I have several databases, together >17 Gb).

That’s not how I read it at all :slight_smile: It’s ill-advised if you don’t know what you’re doing, hence the default in Chronosync is to treat a package as a single file. All I can tell you is that I’ve been using bidirectional sync on DT daily for at least a couple of weeks now. I add stuff, I delete stuff, I move stuff around, I add and remove external references. No problems at all.

The database on each machine works as expected. I never edit on the two machines at once (for obvious reasons) and so have never had Chronosync flag a conflict. If it did, I’d have to pick one as the “source” and tell Chronosync to copy all changed DT files from source to destination. There’s a possibility that some external references would get messed up by doing that, which is why I NEVER work on a database on two machines at once.

As far as I can tell, there’s nothing magical about the way DT stores its files. The .dtBase package contains .database files that MUST be treated as opaque for the purposes of synchronisation. There’s a Files directory that can be treated like any other directory. Some backup directories and a .plist file. DT is no different to iMovie, iDVD or iWeb in that respect (and I’ve been syncing those apps for about 18 months now; apart from iWeb which hasn’t been out that long).


I use unison to sync between my PowerMac, MacBook, iMac at office, and a Western Digital Passport (pocket hard drive). Unison can detect newer version and copy the latest one to the other machine. It gets confused when two versions are both newer than when Unison saw them last time. In that case you can tell it which way the data should be copied.

The problem is that you have to make sure Devonthink is not running on both computers.

If database file is updated while Devonthink is running, the new version will be lost when the open database is saved next time. Or some other problem may occur. I strongly wish that DT would detect when the open database is modified on disk, and given an option to reload the database from the disk, or override the file change with the currently open version.

I now understand why: you use bidirectional, but only to avoid making two separate synchronizers, for in fact you do use them one way each time, right? The key is to work on one copy at a given time.

Of course, I sometimes forget this - probably because I’ve got several databases. One database simply got far and far too slow to the point that I was no longer using DT often anymore (iMac G5 1.6Ghz 1Gb RAM). But syncing them was slow, as the files are large; hence, I did not do this on a daily basis.

As a result, I do have two databases at times, both of which have been modified. And whilst Bill’s method works bullet-proof, I am lazy enough to want a one button-solution. So that 's why I read the earlier post as “ill-advised”: you can’t use it bidirectional if both databases have been modified.
But your method gives me an easy way to sync the databases and do it often! I have now made sure that they are all the same. Now I can use ChronoSync in each direction, as I do with my documents on a daily basis.

So thanks for the fruitful discussion and explanation!

oh, one more question. Do you have to select “dissect packages” both in

Chronosync > Preferences > Document

and in the synchronizer,

Options > Special File/Folder Handling?

Because I do not want all my synchronizers to dissect packages, especially not in my documents.