This is just a consequence of how Delphi’s form streaming mechanism works.
When you open a form in the Delphi designer, the .dfm file is used to create instances of each component on the form. In your case, the form designer will instantiate each of the objects in the .dfm file. Each property in the .dfm file will be read in.
Then, if you do anything in the designer that marks the form as having been modified, for example changing the active tabsheet, then the designer will re-create the .dfm file when you save. And it re-creates the .dfm file by asking the in-memory components to save themselves. This saving process makes no account of what the .dfm file on disk looks like. Each component just saves its properties as they are at that point in time.
So, in summary, there’s really nothing you can do to change Delphi’s behaviour. The best you can do is to work around it to minimise the impact.
If your forms have
Scaled=True then you should make sure that all developer machines use the same font scaling. Otherwise when developer A saves at one font scaling, that .dfm file will be completely different from the one that developer B saves at a different font scaling. All positions will be altered. It sounds as though you have some developers that use 120dpi font scaling. And that’s going to give you no end of grief.
If benign edits to the form file result in large changes, commit those changes. Once you have every developer machine configured the same way, you’ll find things settle down. Those benign edits should no longer result in .dfm file changes.
This is just one of the occupational hazards of visual design with Delphi. You need to pay lots of care and attention to your .dfm files whenever you commit. I regularly find myself reverting changes to .dfm files from the Tortoise commit dialog. I also often elect to modify the .dfm file in a text editor rather than using the form designer!