Chain versioning

[sinus]

Hi all,
Sorry, I see something in this thread
https://www.photools.com/community/index.php?topic=3633.msg24298#msg24298

about chain versioning, and wanted write down my opinion. But since this other thread is a bug report, I wanted open a new thread.

At early in the beginning of IM5 (phew, quite a while since then), when versioning was there, I used also chain-versioning.
But I had some troubles (do not more know what), but in generally it worked, but was too complex for me, and if thinking deeper, it is not logical to me.

But finally, from a logical point of view, how I see it, a master is always a master. If I create a psd from a master, and a jpg from that psd, finally the psd and the jpg are versions from the master.

When you for example creates a new psd from that jpg, because you worked hard for it, then you would have again a master and so on.

I found it good and logical, also for example for strangers (or employes), when I can show them the version-panel, and show, look, this is the master and this master has 5 versions.

If I remember correct, if I had a chain-versioning, I could not see all versions with the master in one panel, except an image was a master AND a version (what is also possible, but ways to complex).

Maybe KISS is a key here.
My KISS is maybe not that smart, because at the moment I do some stuff with the filenames and it looks very good (saved me BTW to get back some lost collections).

20140908-1117-239774-s-coo-bachfisch_a.nef (this _a is a raw, not used, means there are no versions)
20140908-1117-239774-s-coo-bachfisch_m.nef (this _m is a used raw, hence a master)
20140908-1117-239774-s-coo-bachfisch-suessigkeit_m_v1.jpg (this _v1 is a version from the master)
20140908-1117-239774-s-coo-bachfisch-suessigkeit_m_v2.psd (this _v2 is second version from the master)
20140908-1117-239774-s-coo-bachfisch-suessigkeit_m_v2_k1.jpg (this _k1 is the first copy (version) from the second version)

This seems also complicated, not KISS. 
But it looks first for sure complicated, but it is quickly done with the power of IMatch.
And because I use a strict workflow, it is always the same.
Usually I have only a master and one version:

20140912-0911-240669-s-sin-hasenzucht_m.nef
20140912-0911-240669-s-sin-hasenzucht_m_v1.jpg

With this system I can also search and see very quickly, what a file is. This works also in backups or outside of IMatch, mostly I can say, ahhh, this file is a version, this a master and so on.

I am happy not to use chain-versioning, though it was fascinating.

[Damit]

Thanks sinus.  I do find this post helpful.  I had this same exact conflict in deciding exactly how I am going to create a naming scheme and how to use it with buddies and versioning. It has been 6 months but I am just starting to grasp some things in iMatch. 

Do you still use this method or have you evolved to something else? I assume you set up .psd and .jpgs as versions, with the "_v" signaling to iMatch that a jpeg is a version of one without the "_v" correct?

By making all these versions of one master file then you can use the naming scheme to keep things in order, including the source of the version. If you made another .jpeg version of the m_v1.jpg, I assume you would name it _m_v1_k1, signaling that the version came from the m_v1 file?

Also, if you made another jpeg from the _m.nef, after you have made all the versions above, you would then call it _m_v3?

The only thing I do not think I would employ is the _a designation. I would just leave the filename as is with no modifier in the end, as nothing has been done to it, but if you have a reason why that would not work and the _a modifier performs some function for you, please enlighten me.

I am doing A LOT of thinking on this subject the past two weeks because this will for a foundation for the way everything relates to each other and organizes itself within iMatch, so any perspective really helps challenge my thinking and bring in fresh ideas.

[sinus]

Wow, you grabbed out an old thread.   But if it could help you ab bit, cool. 
Basically it is, like you wrote, I do the same still today. 

I think, it is very good to think about this carefully, because it is one of the basics of a DAM (like folder/name-structures).

Hmmm, give one, two days, then I will answer you a bit more specific. 

[sinus]

OK, found time (instead drinking two coffees with cake). 
Here we go:

All new raws (in my case nef) get a _a at the back.
This means that they are (currently) unused and may remain unused.
20230209-1322-445578-s-coo-baecker_a.nef

If I decide to edit a raw, I replace the _a with an _m
20230209-1322-445578-s-coo-baecker_m.nef

This means that a raw file either has a _a at the back, in which case it is unused.
If it has a _m, then one or more versions exist.

I usually only make a jpg as the version, which means there is a new jpg with _m_v1.jpg at the back.
20230209-1322-445578-s-coo-baecker_m_v1.jpg

Since I still have to make many pictures that are transparent (or simply on a white background), I use an additional letter _f (f for freistellen (German)) at the back for this.
20230209-1322-445578-s-coo-baecker_m_v1_f.jpg

If I make another format like tif as version instead of a jpg, it still gets _v1
20230209-1322-445578-s-coo-baecker_m_v1.tif

If I make a second version of the raw, it gets _v2 etc.
20230209-1322-445578-s-coo-baecker_m_v2.jpg
20230209-1322-445578-s-coo-baecker_m_v3.tif

If I make a new version of the already existing version, then this version is the source for me, so the version at the back gets _c1 (c for copy, I used to have k).
This means that if it has a _c at the back, I know that this is an image created by a version.
20230209-1322-445578-s-coo-baecker_m_v1_c1.jpg
20230209-1322-445578-s-coo-baecker_m_v1_c2.png
20230209-1322-445578-s-coo-baecker_m_v1_c3.png

**********
This may sound a bit complicated, but it has worked for me for many years.
In addition, I usually have only 3 states from an event (a photo session).

20220415-1845-346235-s-kun-erdbeerkuchen_a.nef (not used)
20220415-1845-346235-s-kun-erdbeerkuchen_m.nef (master, has version/s)
20220415-1845-346235-s-kun-erdbeerkuchen_m_v1 (version)

I didn't have the _a (as unused) at the very beginning, looong ago.
But somehow it didn't fit for me. I don't remember whether I had also found a reason for it (which I can't think of now).

In any case, this way my search is also simple.
When I edit e.g. 200 pictures, I often have them in a result window (underestimated, very cool).

Then I can use the File Windows search to quickly and easily find all the unused ones (_a).
Or all used masters with _m. (with the point) and all versions with _v
And only _m brings me all masters with all versions.

For the versions, I then search only _v, because it could have several versions.
Or I search for all exempted versions with _f or all versions of versions 😊 with _c

Hmmm, I hope I have written down more or less everything and have not made any mistakes, because that can happen with such a list.
Oh yes, but that's just by the way, I also distinguish these states by different colours in the thumbnail (background), so I can see immediately whether a picture is used or not.

And when everything is done, all the photos of a photo session are stacked and as the top stack I choose a picture that I can remember well.
I have found this works with thousands of photos, even x years ago, as soon as I see a picture I (almost) always know immediately what it was about and can open the stack if needed.

Hope this helps.
Good luck!
In the attachement you can see an example, left not used, middle is the master, right the version.

[Damit]

Thanks sinus.  Yes, it was very old (evidence I do use the search function, though at times it may seem I do not) but it contained information I found useful and perhaps others, who were not around back then, could as well, which is why I decided to respond to it, rather than just send you a private message. I was very curious if you had changed the system, and it seems as though the only real change was using c instead of K.  I am doing a lot of thinking on this subject and trying to come up with different scenarios and figuring out what I want to buddy, version and what information I would like to propagate. It is hard to do it before the fact, hindsight will always win, which is why I have researched naming schemes here.  Once I have finished figuring this out, I will post my scheme. If there are any caveats hopefully someone will point them out.

[sinus]

Thank, Damit
You are correct, I changed only the _k to _c 

What I tried to look also, for the naming scheme, that I can search for things, what are unique. Althoug we have a lot of search/filter - possibilities in IMatch, I like to search also for names.

Hence e.g. in my filenames _c or _f or _v are unique, I have no files with this combination, therefore a search for _v1 will not bring other files as versions. 

I can only stress, that you do it right, from my point of view, to think very good about such things. It may be time-consuming and sometimes frustrating, but once you will have a good system, you will work with it for a long time. 

Hence it is worth to look at it deeply.
Yep, once you have done it, your system would be intersting for other people, I am sure, at least for some people, like me. 

Good luck.

[Damit]

I would also be interested in what you propagate, but perhaps that should be addressed under another thread?