Grant Baillie wrote: > > The repository is not intended to be either forward or backward > compatible. However, there are checks in place that are supposed to detect > if you're trying to load an incompatible repository, and put up a dialog > in that case. So far as I know, there is no difference in repository > format between Chandler 1.0.2 and trunk. >
… Jeffrey Harris wrote: > > Generally speaking, this won't work. Certain source code changes > invalidate old repositories. If the source code hasn't changed between a > released version and a later version, you'll get lucky and it'll work, but > don't rely on this. > Thank you both. Below, some background information and just one question re: regaining confidence following an import or restore. I assume now that my use of three versions — * 1.0.2 * Chandler_intel-osx-leopard_1.1.dev-r16593-20080924143343 * revision 16627, patched — with one repository, was contributory to one or both of <https://bugzilla.osafoundation.org/show_bug.cgi?id=12508> and <https://bugzilla.osafoundation.org/show_bug.cgi?id=12509>. Also, <https://bugzilla.osafoundation.org/show_bug.cgi?id=12505> notes that Chandler did not launch properly when I experimented with patched revision 16627. ======== Option A ======== Setting aside the following files/directories: __repository__ __repository__.backup.001 __repository__.backup.002 backup.chex binary_backup.tgz I can launch Chandler 1.0.2, import from the 8.5 MB backup.chex then check and repair the repository. ======== Option B ======== As binary_backup.tgz was only 4 KB I might: 1. later, at home, use Time Machine to restore from an external volume a more complete binary_backup.tgz 2. use Chandler 1.0.2 to restore (from binary_backup.tgz) 3. use Chandler 1.0.2 to check and repair the repository. ================================ Regaining confidence: a question ================================ Following either approach -- (A) import from backup.chex or (B) restore from binary_backup.tgz -- is a subsequent 'Check and Repair' of the repository sufficient to regain confidence? ========== Side notes ========== i) <https://bugzilla.osafoundation.org/show_bug.cgi?id=12343#c3> the three webcal:// subscriptions were those that previously passed at <https://bugzilla.osafoundation.org/show_bug.cgi?id=12439#c7>. All three were relatively large, and two of three were identically named 'Jewish Holidays'. Subscription in Chandler 1.0.2 presents those two without distinction. Comparable subscription in iCal distinguishes one of the two, 'Jewish Holidays 2'. ii) Re option (A) above, almost immediately after a first import, I carelessly crashed the application (bugged by <https://bugzilla.osafoundation.org/show_bug.cgi?id=11696> on my peripheral display with menu bar). During the second run I noted an import of over 29,661 records then dragged the window to the LCD that's integral to my MacBook Pro. (Here, I guess, bug 11696 is less likely to strike.) -- View this message in context: http://n2.nabble.com/Using-a-single-repository-with-both-a-release%2C-and-a-more-recent%2C-version-of-Chandler-Desktop-tp2109519p2117292.html Sent from the chandler-dev mailing list archive at Nabble.com. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
