Propagating in version

[Rene Toepfer]

I try to understand how the propagation of versions is working.
As first I have set a relation for versioning which works fine. In versioning I have checked "categories" and other items (see attachemnt). When I run the relation the related files will be versioned - so far so good.
Now I want to adjust/propagate the keywords from master to version. The command "Versionen|Propagieren" at right mouse button in viewer is greyed out. If I change a keyword in master it will not be propagated to the version.
Unfortunatelly https://www.photools.com/help/imatch/#rel_versions.htm#a_prop?dl=h-23 did not help, except to know that it shall be possible to propagate.
How can I make it work to propagate keywords too?

[Mario]

Make sure you enable the propagation of keywords.



Categories are not keywords and you most likely don't want to propagate all categories like that.

[Rene Toepfer]

Unfortunatelly it does not work.
Afterwards I have changed the relations, I have refreshed them. Now I have checked a keyword in Master but it will not be propagated to the version.

[thrinn]

One possible pitfall: Metadata propagation takes place when you write back changes to the master. Please check if you performed a write back after you changed the keyword of the master.

[Rene Toepfer]

The propagation must be started manually. I understood https://www.photools.com/help/imatch/#rel_versions.htm#a_prop?dl=h-15 that it will be done automatically. But it makes sense that it will not be done automatically because I could have different keywords for different purposes.

[Rene Toepfer]

One possible pitfall: Metadata propagation takes place when you write back changes to the master. Please check if you performed a write back after you changed the keyword of the master.

That's it! If I start the write-back manually everything will be copied.


Thanks to both of you!

[thrinn]

That's it! If I start the write-back manually everything will be copied.

As in many cases, IMatch has an option to switch between automatic write-back and manual write-back. There are different opinions what the better approach is (that's why there is an option).
Be also aware that information that exists only in the IMatch DB (like categories) can be propagated without a write-back. Metadata, on the other hand, requires a write-back. In the screenshot posted by Mario you will see a star after "XMP Keywords". The meaning of the corresponding "foot note" at the bottom is exactly that a write-back is needed.

[Rene Toepfer]

Is it possible to write back metadata from version to master? My keywords are at a JPG but now I would like to try a RAW with the JPG, where the RAW is the Master and JPG the version.
Another issue, I have not found a solution in the help: How can I remove version links in general? For manual links I've found it but not for automatically generated. I did a mistake and place a manuall l ink of a master to another master and now I cannot remove this link anymore. This is my problem: Image 7295 is a master and version

[Mario]

Write back is done from master to version. You cannot change the direction.
But you are free to choose what you consider a master and what a version.

Propagation is performed automatically. You don't need to do anything.
But keep in mind that metadata is propagated during write-back. First the master is written and updated. Then metadata is copied from the master to the versions, new digests and timestamps are generated etc.

How can I remove version links in general? For manual links I've found it but not for automatically generated.

You cannot remove version links which have been created based on your file relations. That's the trick - they are fully automatic.
You cannot tell IMatch to consider blah.jpg is a version of blah.raw. And then tell it "but not this blah.jpg".
This would make things much more complicated and create many new ways for users to shot themselves in their foot. And they will.

If you don't want a version to be a version anymore, rename it or move it to a folder where it will not be detected by your file relation rule.
If you see a need to do this, please rethink your workflow or file relation setup. Forcefully breaking version chains like this is usually never needed!

[Rene Toepfer]

But you are free to choose what you consider a master and what a version.

Where can I change what is master and version?


I try to find my workflow with version in IMatch.

[thrinn]

Where can I change what is master and version?

There is no checkbox or similar for this. Your File Relations define what is a master and what is a version. Basically, files that are grabbed by your Master Expression (on the Detection tab), are potentially masters. For example, all .nef and all .nrw files. Then then Link Expression defines what will be identified as versions. Note that this is a simplified description, without taking account all options you have.

If you want to have .JPG as master and .nef and .nrw files as versions, you basically exchange Master and Link Expression.

[Rene Toepfer]

Sorry for confusing you, I have two scenarios.
1. Only JPG, as master and version
2. RAW as master and TIF and JPG as versions


The relations are fine and the "collecting" of the files works fine.


For 2 will be defined by the relation. I will create a specific relation where JPG is the master and RAW are versions. Closed.


Now 1.
I have selected a folder containing JPGs and ran the relation. All JPG in the selected folder became the master. And now my question: Can I change the "master JPG" afterwards manually or do I need to re-run the relation with another "master" folder?

[Mario]

The master is solely defined by your master expression.
To use another master, 1) Change the master expression in your file relation, 2) refresh relations.

As I said above already, It is quite uncommon to have to change the master or break version chains like you apparently need to do for some reason...
I would suggest you rethink your workflow and file organization. It is very easy to shot yourself into the foot by making this too complex.

Keep it simple.

Keep files you don't want to version outside folders you use for finding versions.
Avoid using the same file extension for both master and version unless you have very clear and always enforced naming conventions. You don't want to create infinite loops in your version chains or self-referring chains where a master suddenly becomes a version of itself. IMatch has checks but cannot pick up everything.

[Rene Toepfer]

As I said above already, It is quite uncommon to have to change the master or break version chains like you apparently need to do for some reason...
I would suggest you rethink your workflow and file organization. It is very easy to shot yourself into the foot by making this too complex.

I am looking for a possible workflow with the versioning concept of IMatch (I have started to evaluate versioning yesterday night). Based on this (and because it is a more complex topic than expected by me) a lot of questions are raising up. I can only make a decision of changing my workflow earliest if I understand how the versioning concept of IMatch works. Maybe I need to restructure my files or my workflow, maybe I waive the using of versioning. I am open mind with this.

Keep files you don't want to version outside folders you use for finding versions.
Avoid using the same file extension for both master and version unless you have very clear and always enforced naming conventions. You don't want to create infinite loops in your version chains or self-referring chains where a master suddenly becomes a version of itself. IMatch has checks but cannot pick up everything.

This is a good comment which will help me with my decision. Additional tests will check what happens to my files.

[bekesizl]

If you want some more examples of file relation rules, here is my thread about my rule set.
It is broken down to more simpler rules.

My database is also RAW Master + JPG (newer photos) version and JPEG Master + Version (older+smartphone photos) mixed.

https://www.photools.com/community/index.php?topic=10996.msg78383#msg78383

I defined, that the name of a JPG Version of a JPG Master has to be appended with some string.
The order of the relations is like listed in the thread, buddy first, version second.
You most probably should exclude the "Mylio XMP files (buddy)" rule from your set.