Making Delphi 7 play nice with source control? [closed]

Question

Hello I've been having to work in a Delphi 7 project recently and one thing that constantly bugs me is the *.dfm files. Anytime I even open up a form, it will change the .dfm file.

For example, this diff was made just by opening the project and viewing a file and form(note, I didn't change anything on the form itself)

@@ -1,6 +1,6 @@
 object FormPartnerInfo: TFormPartnerInfo
-  Left = 85
-  Top = 454
+  Left = 554
+  Top = 322
   BorderIcons = [biSystemMenu]
   BorderStyle = bsToolWindow

Is there anyway to force Delphi 7 to not update this pointless design-time information? I'd prefer to have it play nice in SVN so I don't have to keep reverting files before doing a commit

Anathematize

Keep them readonly. That'll prevent the diffs, though it will create save all problems... (warnings on not being able to save to readonly files) and save all is something I use every couple of minutes - it's engrained in my muscle memory. Newer Delphi versions are better in the "changing" aspect but not much. Possibly because of the embedded designer which means the position of the forms doesn't change... – I

I also get random width changes sometimes without touching things. Delphi 7 is very lacking as an IDE compared to Visual Studio :( – Anathematize

Ah yes, but it is not quite fair to compare Visual Studio with an almost antique version of the Delphi IDE... – I

A fair comparison would be with MSVC6. Delphi 7 is ancient!ancient! – Yankeeism

Apparently this bug is still in Delphi 2007 according to some other questions mentioning source control and Delphi – Anathematize

Delphi 2007 is ancient!ancient! too :) – Grandee

@Earlz: This isn't a "BUG". If the form is moved in any way, it's top and left are changed, and the change results in a change in the DFM. What else would you expect? FWIW, I open and close forms all the time to work on code in the IDE, and I never get changes to the DFM if I don't add new components or change properties of existing ones. (Using D2007, DXE, and DXE2, with the embedded designer - that's probably why I don't experience the problem. I'm guessing those questions were from people using the floating designer instead. Use antique functionality, and you should expect antique results.) – Penman

You are dragging the form I guess. That's why Left/Top change. They aren't design time properties if you have Position=poDesigned. And BorderIcons/BorderStyle are most definitely not "pointless design-time information". The form streamer does sometimes do odd things, but I don't think your example exhibits any fault. – Yankeeism

@David: BorderIcons and BorderStyle didn't change in the diff shown. – Penman

@Ken OK, is that just context? – Yankeeism

@David: Yes. The - and + indicate lines that were different; lines with nothing in front of them are contextual. – Penman

I'm voting to close. This is just behaviour as designed. – Yankeeism

What makes you think form position information is "pointless"? You <strike>blinked</strike> moved your form and designer is remembering new position for you. @David Heffernan, dont hurry with replying, look closer at the diff output, object clause and BorderIcons denotes the context of changed lines. Or better, get Win32 port of diffutils, it is quite powerful. – Cuprum

@Ken - that's one of the main reasons I like the embedded designer. Particularly with multi-monitor set ups. – Veranda

@Gerry: I like the embedded designer, and wouldn't go back if you paid me. (I still have a couple of projects I work on in D7, and I hate every time I have to work on them. Hopefully soon I can at least get them migrated to D2007 and get rid of the last floating designer stuff for good. – Penman

Marjan Venema: BDS versions (including XE) suffer from this even more. At least with default settings. – Refractory

Earlz it's worse than you describe. Much worse. ImageLists get randomly modified every single save. Combine that with developers who check in everything just because that's what they're used to doing, and you end up with perpetual DFM conflict craziness. Since the tools work the way they work, the smart thing would be for developers to find workflows that aren't crazy, including reviewing DFM changes and reverting them, when they are not intentional. – Stickup

Answer 1

It's not Delphi that inconveniences you with a commit dialogue that loads with every changed file checked by default (rather than requiring you to explicitly check the files you want to commit). That's the design flaw in Tortoise that leads you to the habit of reverting dfms (because you probably just want to keep your working copy clean as possible - like everybody else).

The answer is to change your perspective. You don't have to revert the dfms before you commit! I used to do that too. That's just a habit you can change.

The rule is don't checkin anything unintentionally. If you didn't set out to change the form, then uncheck the dfm in the commit dialogue. Even better, uncheck everything then only intentionally check the files you want to commit (maybe after you've checked the diffs). Or you can commit individual files by right-click commit on the file itself (rather than right-click commit on the folder). You can even go so far as to multi-select (use Shift or Ctrl) the files in Explorer before you right-click commit.

You need to become comfortable in the knowledge that your working copy can be dirty, as long as you keep the dirty stuff from being checked in (and if you revert those dfms, they'll probably get changed again next time you open that form anyway).

Invalidism