Pack and Go is Super - but MERGing DBs would be even better.

[ubacher]

The new Pack&Go feature seems to have been made just for me.
(I travel 5 months of the year (Winter of course) and have so far kept
my travel pictures in separate IM3 databases. I never got around to merging
these databases. Maybe after IM5 conversion?)

Analyzing Pack and Go I see the following difficulties:

I need to transfer my desktop database (not yet converted, 100000++ pictures) to the laptop
before I go on a trip and add to it during the trip. The size of the database is one (minor) problem
but I worry more about performance. With the current performance I had to stop using IM5 on the laptop for "real" work because it was just too cumbersome/slow. ( And I had only a few thousand pictures.) 

Then there is the CACHE. I would not want to copy the cache file from the desktop as I assume it will be very large. (And the laptop has only a 256G SSD). So I will start a new cache file on the laptop. But I will have to discard this cache file when I move back to the desktop since I can not merge the (laptop) cache file with the (huge) desktop cache file. I will have to recreate the cache
files for the laptop images once I am back on the desktop. Only a matter of available computing time. (At least this is how I understand its functionality.)

All in all I would still prefer to have also a MERGE databases function.  It would be quite helpful now, during the beta testing. One could do new work on an IM5 DB and later merge it with the converted  IM3 DB. And to overcome the current performance squeeze one could work on smaller DB's and later merge them. 

We have the Export/Import categories (with file references) function now. If we could also have an
Export/Import Attributes and an Export/Import Collections function then we would have enough tools to merge most databases. Export/Import Metadata functionality (unwieldy I suppose) would only be needed for those who populate metadata but don't write it to the file. How many do this?  Have I missed something? (Annotations maybe)
A program to merge the cache files would be nice but is only needed to speed up the merging work.
But it probably would be the easiest of the all the merge programs to write.("Most bang for the buck")

[Mario]

If we could also have an Export/Import Attributes

Edit > Preferences > Edit Attributes offers this functionality already. See the IMatch help for details.

xport/Import Metadata functionality (unwieldy I suppose) would only be needed for those who populate metadata but don't write it to the file.

That's the idea behind metadata like IPTC, EXIF, GPS and XMP. It travels with the file. Just write back modified metadata on your laptop and it will become immediately available on your main computer when you import the files into the other IMatch database. No need to add a separate export/import feature for standard metadata.

and an Export/Import Collections function then we would have enough tools to merge most databases. E

Rating and Label are part of the XMP metadata anyway. Which leaves only flags, dots, bookmarks and pins.

For the rare case (I make an assumption from experience here) that a user really needs to transfer flags or pints from one database to another, he can do so with a few steps:

1. Create a category and name it "Bookmarks"
2. Select all bookmarked files in the Collection View and assign them to the "Bookmarks" category.
3. Export/Import files and categories as usual.
4. Select all files in the "Bookmarks" category and press <B> to bookmark them.

Using the same steps all collections can be transferred between databases using the normal Category Export/Import.

If this is a workflow problem faced by many users, we'll see many +1 in response to this post. Usually users find it easer to just copy the database between the two computers. No need to migrate, copy, export or import anything. All the data just travels with the database.

[ubacher]

I was thinking that a user could specify that metadata NOT be written out to file.
( If s/he really does not need it in the file and does not want to take the performance hit
which writing the metadata causes. I think somewhere you (Mario) actually recommended such a usage.
(But you probably thought along a different, less radical line).  I had actually considered this option.)
Such a user could still define Title/Description, Labels/Ratings and Keywords and have them only in the DB. No?

This consideration made me think that such a user might want a Metadata Export/import .

[Mario]

It makes no sense to re-invent the wheel and work around a "no-problem" by spending time implementing an export/import function for file-based metadata. The potential usage scenarios for such a feature are so sparse, it's better to tell the user to write back the changes into the file before importing the file into another database. Remember that most users have to keep the files updated anyway, because only then the metadata can be viewed and processed by other applications.