Delphi 7 .dof and .cfg's: should I track them under version control?

Question

I have in my current Delphi 7 project (named, say, Project1.dpr), two files (Project1.dof and Project1.cfg) which my team and I can't decide to put under version control (we use Mercurial btw).

The matter is this: within the two files above are indicated some library, components and extensions paths which are related to the system the programmer is on.

My team is composed of some guys using 32-bit Windows XP and some guys (me included) using 64-bit Windows 7.

So this brings up the question: since on 64-bit Windows 7 Delphi extensions, components and libraries are located under c:\program files (x86)\... and on 32-bit XP they are simply under c:\program files\..., committing changes to those files would result in breaking other colleagues' project configurations.

Does somebody have some suggestion for a situation like this?

Answer 1

First of all: I fully agree with Warrens suggestions.

If you still want to stay with your current system, you can use $(ProgramFiles) as a prefix for the library pathes. This should work on both OS flavours.

Answer 2

If you're staying on Delphi 7, or even if you're not, I suggest that you check in your .DOF files, but that you also consider NOT relying on them for your final builds. Update: the OP decided not to check in .DOF files, and use final builder.

It is also trivially easy to ask your 64 bit people NOT TO CHECK IN THEIR .DOF CHANGES. Even if they do sometimes forget that they should not commit "local hacks", It is easy enough to make a small utility to read and fix your .DOF files for your local case. Run it each time you pull changes from other peoples repositories.

Second brilliant idea is to check in a .dofdefault file, and have your Build.Bat file copy project.dofdefault to project.def if it does not exist. Problem solved.

For final builds, and to keep your "builds from breaking for stupid reasons", I suggest you look at Final Builder, and that you check your final builder scripts in to version control, and only release to customer builds that have been through Final Builder. That way you won't have to worry about sending your customers mystery builds that you cannot account for.

How for example do you currently associate exact mercurial changeset revisions (md5 hex values) with the code that contained it and the options used to build it?

An even smarter idea would be to drop Delphi 7, which is now over 10 years old, and consider moving solidly into the 21st century.