@platypus and @RexBlock and @anyone who is interested I should have quit while I was ahead!
New bug detected (I believe) causing Virtual Copies to be created:-
I went back to the original directory and wrote the metadata back to the image
I had missed setting the data in one of the images and missed exporting that image which contained nothing new anyway.
I then copied the images and DOPs to another directory and all hell broke loose @sgospodarenko!! I also failed as a tester at that point because I had wondered if I should secure the original directory before exporting the metadata so I had a copy of the original data to refer back to but I didn’t do that!
The reason for the ‘Virtual Copies’ I discovered some rime ago when I took a DOP from one photo that was currently in the PL5 database and added it to another and then “discovered” the new combination. Because the DOP has a UUID the same as one already in the database PL5 automatically protects the original database entry and the incoming DOP data by creating a ‘Virtual Copy’.
I don’t believe that this should happen in any circumstances when a directory is being “discovered for the first time”! “Yes” I am using an image with a name already in the database and “Yes” I am using a DOP with an identifier (UUID) which is already in use and assigned to another photo also in the database but these are both in the context of a new directory which should automatically control any tests conducted by PL5 and also cause a new identifier (UUID) to be allocated to the DOP of the incoming image (I would contend).
I will agree that this kind of problem is being caused by testing with the same images again and again and again and … but …!
In addition why did it not happen in the previous test!?
In addition why is the actual data not quite as might be expected, i.e.
-
Image 1 has a [M]aster thumbnail that is the original photo without corrections but with a ‘Rating’ that was only added as part of the corrections applied to all the photos (as a group, excluding the last photo)
-
The same thing has happened with some but not all of the images.
Is this a database fault, no, I would contend that it is a programming fault, i.e. possibly it is a test done in the wrong order or a flag not set that indicates a new directory has been discovered so ignore checking the UUID and allocate a new one, the program has taken the wrong path for some reason in this particular case when it didn’t take that path in the previous test!
It is certainly not a typical use of the program unless you are trying to stretch the program in the ways that I tend to do (mostly by accident as in this case) but if the program can hold up to that kind of “abuse” then it should offer a reliable experience in most normal circumstances.
In all cases the Tag survived in VC[1] where it had not survived at all in the basic test in the previous post. All tests where the Tag has been involved have not shown the Tag when a copy of the photo has been re-imported in a new directory.
I have been asking for the ability to “promote” a VC[1] or VC[2] etc. for some time, either "promote or swap with the master or delete the master but keep the copies with the first becoming the [M]aster or any other combination you can think of that just isn’t available currently.
I could copy the metadata from VC[1] to [M] and then copy the corrections from [1] to [M] and then delete [1] but it would be so much easier to have a single menu command to do that!
Please note that it is possible that I have completely screwed up the test and if that turns out to be the case I apologise in advance.
PS I repeated the test and got the following which is what I had expected. But this time no Tag anywhere!!