@KeithRJ I was writing the following when your post arrived so I will try to cover some of the same ground plus what I also wanted to add to my post.
Hopefully from my post above it should be clear that if you take a laptop with PL5 loaded on holiday/to a shoot etc. then photos can be imported onto the laptop, PL5 can be directed to navigate to the photos, presets and other editing applied, plus Ratings and Tags and if it fits your workflow keywords etc also applied.
At some point the Photos, DOPs and ‘xmp’ sidecars etc. can be copied to the main system and PL5 navigated to the directory and iff (if and only if) the database has never seen those photos in that directory before all can be imported successfully into the second/main database, which appears to be what @mikemyers is describing in the post that came in while I was writing this!
I believe that they come in with the Uuid in the DOP I described in my post and that Uuid will be stored in the database. But any change made on the main system or on the laptop will change the respective DOP Uuids and Virtual Copies are then inevitable if any attempt is made to take data in either direction, main to laptop or laptop to main.
Hence the suggestions being made to “trash” the database or rather manage it because as long as you keep a log of what was in each database it can be saved and restored later. I have “trashed” the PL5 database perhaps 20 times since PL5 release because of the testing I have been doing. Life becomes a little more complicated if keywording etc. is being used but providing that is written to the sidecar file or JPG or whatever then it is secure and the loss of the database may not be significant.
DOPs do now contain keywords but I have no evidence that PL5 is doing anything currently other than storing them in the DOP. ‘Ratings’ are in the DOP but also in the ‘xmp’ sidecar, Tags seem to be in the DOP only.
I partly agree with your notion that the split would make synchronisation simpler but to be honest providing you ensure what is in the PL5 database has been reflected in the external elements then you need the photo, DOP and ‘xmp’ sidecar and you are good to go. Except don’t go anywhere near a PL5 database that knows the photo (in the directory) or wallow in VC “heaven” or “hell”.
What is actually needed are some additional data management commands that allow VCs to be “promoted” on a single photo, selection of photos and entire directories and subdirectories basis, i.e. select an entire quarters worth of photos that have loads of VCs and “promote” them!
Except as was well pointed out by someone in another post (it’s late so I will look up the reference tomorrow) how do you distinguish between the VCs caused by importation versus those created deliberately as part of the editing process (the context of the original post was with respect to mass deletions of the VCs, except of course that the imports may actually be the edits you want to keep)!!
This means that the importation process would need to be enhanced to provide the automatic promotion but the advantage of trying to sort it out after importation is the ability to review and control what stays, the import or the existing database and what about “legitimate” VCs for one photo it might be possible to have the [M] and [1] in the database and [2] and [3] come in as part of the importation process could that ever be resolved by any bulk process!?
It is a minefield and I need to be up early tomorrow!!
