“Add relations” option - keep existing relations when "refreshing relations"

[akirot]

The current IMatch implementation drops existing relations (except manual ones) when "Refreshing Relations".

The problem: if one e.g. has moved existing versions outside the version search scope the relation to them is lost when refreshing relations.

The request is to optionally(!) keep existing relations when refreshing relations and just add newly found relations.

[Mario]

The problem: if one e.g. has moved existing versions outside the version search scope the relation to them is lost when refreshing relations.

But in that case I could envision side effects. When you have incidentally broken the relation and you force IMatch to keep the broken relation when you refresh relations, the references and information IMatch has in the database is no longer valid and could cause all kinds of nasty surprises. I have not spend time with this but manual relations (and keeping them) and dynamic relations based on rules are two entirely different things.

[akirot]

A different angle of view might help:

1.) maintaining an existing relation.
Once a relation between a master and a version is established the corresponding (configured) rules determine WHAT is propagated. The propagation itself doesn't know HOW a relation has been established - it is just there (the master/version pairs in the database).
Files can be moved around, file names changed etc.. As long as this relation instance is in the database IMatch finds the corresponding files.
That's how IMatch works - no change required/requested.

2.) establishing a relation.
One obviously manually can define a master/version relation. Selecting a specific propagation rule determines what is propagated later.
One can automate the master/version detection. IMatch does that - that's fine (and could be generalized by using "any" metadata for version detection).
Whatever one does the result is a sum of master/version relations which will be used for propagation later on. The propagation itself does not know (and must not know) HOW and WHY a relation has been established.
Once a relation is established even the criteria WHY and HOW it has been established might change afterwards - it still exists.
Compared with real life it is like a parent child relation - it's always there even if one party moves to a different part of the world or changes name.
When a new child is born it is an additional relation, the existing ones aren't affected.
The same applies to a new version.
In particular: a relation must be broken by intent, never ever as a side effect of establishing new additional relations.

As soon as one notionally separates relation detection and relation maintenance it becomes easy. Changing detection criteria do NOT break existing relations.

An option to only add relations (contrary to dropping all and establishing newly found) can do that. Let the user decide at execution time - one can opt for refreshing (with dropping) or adding (without dropping).

Background:
One's mileage varies...
If you are e.g. in travel photography or document a certain topic over a longer period of time you put together photos from different shootings/travels/years for a lecture or book or website or...
Physically you move the finals to a separate folder, you rename files (because other applications sort by filename or you don't want to share your internal nomenclature...), change titles, descriptions (because you work in different languages)...
Always you want to possibly go back to a master (for e.g. rework to highlight something) or want to see all versions of a master.
If adding a version/relation (as long as one must use the current refreshing) deletes all existing relations per default the whole versioning becomes unusable.

[Carlo Didier]

akirot, you are perfectly to the point. Excellent description!

[akirot]

@ Mario: I understand you are reluctant to implement this feature request because you fear side effects.
I forgot to mention I have all background processing deactivated and only use manual(!) version refresh via the commands window.
To me an additional option in the command window only to only add relations (without dropping any) would be sufficient and help.
(This can't have side effects because all automatic and background processing remains untouched.)
Please consider this approach. (Together with your just announced enhanced version detection mechanism I no longer needed to migrate my core IM5 versioning script. ;-) )

[akirot]

sames as: https://www.photools.com/community/index.php?topic=7942.0

[Mario]

See my reply in the other thread-

[akirot]

Mario,
You wrote: "When you move files to a place where the version rule they no longer detects, they are not versions anymore."

I consider this (location dependancy) as a design flaw.

Yes, you need to know the location to detect(!) a version (one can even do a full scan - what is nonsense performancewise and this is why I don't do it).
No, you don't need the location to maintain(!) a relation once established. Versions remain versions even if moved around. Nothing changes, just the location.

In my opinion you unnecessarily limit the already existing capabilities of IMatch by always deleting existing relations.
Please give the responsible user the possibility to decide (i.e. just make deletion an option).

No, manual versions are not the solution: As the name says, you have to establish them manually, file by file. There is no automatic detection :-(
Technically they do the trick once established. (This is what my script is for: I do a version detection on my own account and establish manual relations.)

[Mario]

I consider this (location dependancy) as a design flaw.

There are two types of file relations:

1. Automatic relations which are generated by IMatch by searching the folders you select for versions. This is a dynamic process. IMatch re-runs the version detection automatically when needed.

2. Manual relations. You designate a file as the master and any number of files as versions. This is a manual process, IMatch will never change the version sets afterwards. You have full control over which files are versions.

I don't see a design flaw.  If you don' want IMatch to automatically detect and update version sets, use a manual version set.
It has the same features as an automatic set, but it does not use regular expressions to find versions in selected folders.

If you setup an automatic file relation and later deliberately break it by moving versions to folders not covered by your file relation, why not just add the new folders to the rule?
If you move final files to another disk or media, you can just include that in the version rule and IMatch will find the versions also after you have moved them.
I don't see a problem with that, and all the features and automatisms stay intact.

[Carlo Didier]

If you move final files to another disk or media, you can just include that in the version rule and IMatch will find the versions also after you have moved them.

That's why I let iMatch look in ALL folders for versions. So I don't have to remember where it looks and add folders one by one. That's the whole purpose of automatic versioning. No manual intervention in any case.

[Jingo]

If you move final files to another disk or media, you can just include that in the version rule and IMatch will find the versions also after you have moved them.

That's why I let iMatch look in ALL folders for versions. So I don't have to remember where it looks and add folders one by one. That's the whole purpose of automatic versioning. No manual intervention in any case.

+1 for this... just point it to the top folder where you photos could be stored and let er rip!  That is how I have it setup as well.