Advantages of NOT versioning .dproj

Question

I read in a blog about Version Insight (http://www.delphifeeds.com/go/s/77066) that (among others) JCL doesn't have its .dproj files under version control and i was wondering what the advantages of that would be.

Especially since me and my collegue developer often "bug" each other with checking in project files with our own favorite debug settings (he likes optimization on, I want it off). And because of the regular hick ups of Delphi 2007 that screw up the dproj file with all kinds of faulty dependencies. Does not versioning help in anyway with these things?

We are using Starteam as our VCS at the moment.

Answer 1

I store, in my .dproj files, settings that are used by msbuild for my build process. For example, conditional defines, compiler settings, etc. If you do the same then you need to version them.

If you are using a version of Delphi where the IDE breaks the .dproj file on a regular basis, then surely revision control will help you fight back.

I can't see any advantage in not versioning them.

Answer 2

If you're using Delphi 2009 or later Option Sets are a perfect solution for this problem.

Option sets are basically collections of settings that would normally reside in the DPROJ (which you do version) but instead stored in a .OPTSET file (which you don't version).

Make your DPROJ contain the settings that are common to all developers, that nobody is allowed to change unless it's an agreed across the board change.

Next in the project manager (D2009 and above) on first the DEBUG configuration node and then the RELEASE configuration node, right click and select "New Option Set". Call this option set something like "Local Developer Debug Settings.optset" and "Local Developer Release Settings.optset".

Now commit only your DPROJ to version control as it now refers to these .OPTSET files. You must name your option sets exactly the same on each machine for this reason.

When you want to make a local change to your project configuration rather than editing the project configuration, right click on the Option Set in the project manager and select "Edit Option Set".

The IDE will apply the changed settings from the option sets without modifying the original DPROJ. Settings are applied hierarchicly with option sets being the last to be applied.

Answer 3

If you choose not to version your DPROJ, when creating your release builds I recommend you use a separate build script of some sort that you do version e.g.

• a batch file that calls the command line compiler and specifies the compiler options and paths required.
• a Finalbuilder project (much easier than a batch file)
• an msbuild script (never done this myself but I assume it would be possible).

Answer 4

One solution for this issue is to be more discerning about what parts of the DPROJ (and also DFM files) you allow to be checked in.

You don't mention what version control system you're using but TortoiseHg has a hunk selection feature as part of it's commit process which lets you select individual lines within a changed file to be committed and still leave other lines uncommitted.

I use this method to never check in junk changes from the DPROJ (such as changing the active config from RELEASE to DEBUG) and the DFMs (e.g. changes to ExplicitHeight and ExplicitWidth properties).

Answer 5

The only reason i can think of to NOT version control DPROJ files is if, like the JCL, you can regenerate them as part of your build process. The JCL is a class library (code-library) not an application, and it targets multiple versions of Delphi with differences in their .dproj files. In fact, versions of delphi prior to 2005 didn't use .dproj files at all.

Answer 6

Later version of Delphi XE4, 5, 6, and XE7 are very stable constructing the .dproj XML files. I have no complain using git to version .dproj and .groupproj files. Updates to these files using the IDE editor result to expected neat and clean changes only.