For any individual file, last merge wins. Until SolidWorks develops a way to merge the contents of two files, merge in PDM is just creating copies of the master file and then replacing it with the copy later. You can do the same manually.
hopefully Diaval jumps in but from what I can tell, Branch always uses the latest, will not use old version even if you have old versions in local cache. If I’m testing it write and not missing some option the merge will always use the latest version of the branched file(s) and put them in as a new version of the master.
Always using the latest on branch seems ok, I think, because I think the master would be in Released state so we would want to be using latest version. As I type that exceptions come to mind… 
For merging, we consider the file that’s being merged in to be a “test” or “prototype” of the proposed changes, so there could be iterations on that part that would make revisions of that file as it goes through workflow. There could also be sibling branches if we want to test or prototype multiple options in parallel. In that case, only one branch would be merged. Either way, making some version the latest version isn’t terrible, hopefully it’s not a regular occurrence to want an older version in this case.
If there are multiple changes made to a file in parallel only one will win. CAD files cannot merge changes like text files can do. So if a file is branched to A then that same file branched to B whoever merges last will win. So if B merges then A merges; B’s changes will be lost and A will go. This can get messy because it could be possible that the master could be released for production (depending on your workflow and drawing publishing) after B is merged and before A. So B’s changes could be implemented for a while, then the master go from Released back to WIP for A to be merged, that that point B changes would be revoked and A would be implemented. Confusing.
The branching dialog has the option to create the branch using latest version or referenced version for referenced files.
PDM is only handling the reference tree and file metadata with branching and merging. It is not able to do any kind of merging of SW features inside the files themselves.
Because merge is only looking at the reference tree of the source and branch files directly involved in the merge, care would have to be taken when making multiple branches of a files that will have different changes made when needing to merge them together. Multiple merges back to a single source file overwrite the changes made from the previous merge.
In the merge, the physical source file is replaced with the physical branch file for all files in the ref tree using the default Merge option. References are updated based on the selections made by the user in the Merge dialog for each reference (Merge, Use source, Merge as new, Create as new).
The administrator has the ability to define how the variables are handled in the branching and merging of the files similar to how they can be defined for Copy and Move Tree operations.
Branch files are treated as independent with their own lifecycle in the vault. The only difference between Branch and Copy Tree is that branch will maintain an internal PDM source/branch reference for each file in the branch to enable the ability to merge the file back to the source. Because of this, when you merge, it is important to know what variable values should be taken from the original source file and what should be taken from the branch file. For example, the Revision variable should always be taken from the source file to keep the variable value in sync with the actual PDM revision of the source. Any variable values that have been updated for the change in the branch file that should be reflected in the final version should be set to copy from the branch file on the merge.
SPR 532438 is about needing the ability to select what ref tree should be retrieved when opening files from the vault in SW. Currently PDM always gets latest without any option to tell it to get me the referenced version or even better the option to tell it to get latest released versions based on a defined Released state in the PDM workflow.
This is just PDM saying that the selected PDM operation will be running a Get and will overwrite the modifications in memory on the file,
I understand. Since we must manually get by referenced version every time we open an assembly it get’s old. I was taught that the UI shouldn’t pop up dialogs unless the user is off the normal, expected workflow. Users follow path of least resistance. If there are popups on the regular, expected process users are trained to ignore them and click “ok” then when there is a legit need for a popup they click “ok” before reading and understanding.
Ah, I understand now. If this is your standard workflow I can see how frustrating it would get to be prompted with this all the time. Sounds like this dialog needs a “Don’t show this message again” option. Check out SPR 784509
you are like a Rolodex of SPRs!
image.png
I like to keep tabs on enhancements that have been requested. 
Does anyone have any word about if this feature is added in newer versions of PDM? We are getting hammered with lost time and errors due to CAD users having wrong version cached when viewing, reviewing or editing and checking assemblies in. I hear discussions in the room every day about cached version, some of them indicate an understanding of what’s going on and some do not.
Some users are pushing to clear cache daily. We looked into clearing cache options with our VAR, working through scenarios and it would boil down to clearing cache every time the file is unloaded in SW. Not having cache is not the solution; getting referenced version of the files every time an assembly is opened is the solution.
I have a couple saved email drafts to send to our VAR about getting some kind of push going, but I know that will take many hours of our time as we must justify the request, yet it still might end in a “NO” from Solidworks.
I wouldn’t hold my breath. I think a custom add-in would be required. We wrote one for CVD files which we use for ECOs. Since there there is no file behind it and its just ECO meta data, we wanted the data card to always reflect the “Latest”. The add-in clears the cache on the CVD after they check it in. I think it also intercepts them trying to “Get” versions, just insures they have nothing cached.
I’m turning blue…
I’ve actually played around with this a bit with a PDM add-in. It will essentially get the latest production release of a part/assembly unless you specify an Engineering Change number(s) then it will get the very latest draft of those since they’re the in-process pieces you want in your assembly. I haven’t fully debugged it though since there seem to be a lot of cases of assemblies referencing an older released revision of a part as well. I was discouraged after a while since there isn’t an easy way to determine every use case and program it in to the software.
I wish the company that created the software would be the ones writing this stuff…
Yes, we have looked into various methods of getting the reference tree by referenced version. One obstacle is there’s so many things a user can do that triggers (or should trigger) a get file action. Everything from double clicking to opening files from the open file dialog, or replace file dialog, Connisio links in emails, it seems nearly endless the entry paths. I think the only way to handle all of them is right at the get file hook. I’ve poked around using the EdmCmd_PreGet hook but I’m not smart enough to determine if that is really going to accomplish what I want or if anything I do (such as get the all the references by version) will be overridden by PDM after I return from the add-in. Perhaps the Post-get would be better but then I’m likely getting many of the files twice; PDM gets the latest if there is no local copy then my add-in would get any files that are not the referenced version. But what if the file is open in Solidworks? What if a where used of the file is open so SW has the file loaded? Then eDrawings, I’m lost as to how or if it uses referenced files, I have the setting for file types that viewing doesn’t need to cache referenced files, but AFAIK that only applies to right click → View File in vault view. What if the non CAD user has the .sld% file types set to open in eDrawings and they just double click? What does PDM do then? What if the referenced file is already open in eDrawings? Will it be locked? I just don’t have the means to know how to deal with all the what-ifs that I ran into during planning stages of the add-in. The more I researched the more unknowns I ran into, tricking PDM into getting referenced file versions is just beyond my abilities. If someone wants to give me a price on writing an add-in that will work for all the various cases I would be happy to discuss that option with them.
You must be in Offline mode. 
I $#!* you not, I just replied to another email concerning versions and updating where used and what version to have of what… Nearly every day. It’s like I’m speaking Greak or Latin or Groot to them. 
It used to get my blood pressure up, but now I’ve come around to the point of “comfortably numb”.
I’ve found that the occasional meme at the top of the reply helps me to feel better. Something like:
Edit: I just got the blue folder ref. nice. Fortunately, with the work from home wound down we have fewer users on crappy VPN connections.
I wonder if the DB is structured for doing this efficiently. Say I want to “Get Latest Released”, the codes needs to retrieve all version with the highest “Revision” label. On a really large assembly this could be time consuming as it must query each file’s history.
In Windchill, this seems to be handled by what they call “'Baselines” which is a snapshot of the BOM structure when it releases. You can retrieve “latest” or “baseline” or 'latest release". The GU stinks and the users get confused on what to select but the capability is there.
That said, to make this work efficiently, you would probably need a custom add-in along with storing data in a second custom DB.
That’s why we use “Always works with latest”. There is a small window for error with assemblies but with hundreds of people, there is a greater risk they are opening an old cached version.
We worked through a few examples of that and it would wreak havoc on our assemblies, due to transients of migrating our entire data set into SW (many SW models needing to be redone but they already used in many places) as well as continuous flux of our data set due to legit ECOs.
Users are opening drawings and assemblies much more often and they’ll just get latest (which gets latest of the entire ref tree) then most of the time the assemblies are bad with rebuild errors. We just need PDM option to “Always work with referenced version”
We’re putting together a financial impact for our VAR to hand off to SW to see if we can get something. I’m scared we’re going to find out that there will be endless problems if we cannot just always work with latest.
Are you saying there is no way to force an assembly to use the referenced revision and not latest? That seems like pretty basic functionality. 
Teamcenter defines it as “precise” vs. “imprecise”. A precise assembly (or component) stays at the specified revision and does not change unless it is explicitly commanded. Imprecise assemblies update based on the active revision rule.
Oh yes, we can get the files by referenced version, but It must be done manually in SW PDM Pro. It seems the “Best Practice” is to always work with latest version, as if always work with referenced version isn’t really supported.
Edit: After rereading your question I would have to say you are correct, there is no way to force PDM to cache the referenced versions of parent files. Can only force to cache latest version.
With the 101 ways to load a parent file it’s difficult to get the users to always manually get the referenced files by referenced version first. Some users kinda get it but there are a few that just do not understand it. One of the 101 ways that I saw a user doing the other day that I didn’t think of when considering an API solution is drag from vault view/search tool into an assembly. I never got into the habit of doing that but to maybe half our users that is the DeFacto method of adding a part or subassembly to an assembly. Well of course PDM will use any locally cached versions and get latest of the rest; both of those are wrong, we need it to get referenced of all the referenced files.