10

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.

LachlanG
  • 4,047
  • 1
  • 23
  • 35
Bascy
  • 2,017
  • 1
  • 21
  • 46
  • I don't know whether Delphi 2007 already supports this, but you could use separate build configurations to handle the different debug settings. – Moritz Beutel Feb 20 '11 at 20:39
  • yes it does, but its a very delicate system, as every change you make to your settings is always saved in the selected build-configuration, no questions asked – Bascy Feb 20 '11 at 20:48
  • Well yes, that's the way it's supposed to be :) – Moritz Beutel Feb 21 '11 at 01:43
  • Problem with that is, that you can't change the compiler options on a temporary basis ... You have to remember to set them back manually. The fact that the dproj has changed is not indication of that, cause it could have been changed for other reasons (new sources i.e.) – Bascy Feb 21 '11 at 08:35
  • also see: https://www.uweraabe.de/Blog/2017/01/18/dproj-changed-or-not-changed/ – Gabriel Aug 30 '19 at 11:54

6 Answers6

7

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.

LachlanG
  • 4,047
  • 1
  • 23
  • 35
  • he only has the problem 'cos he's on D2007! – David Heffernan Feb 20 '11 at 21:21
  • 4
    That's why I wrote a second answer. I don't expect it will help Bascy, unless it helps to convince him to upgrade, but it might help others. Option sets aren't well known but they're really very useful. – LachlanG Feb 20 '11 at 21:26
  • You now have 3 answers. That's stretching it a bit too far. Why don't you edit them all into one. Please! – David Heffernan Feb 20 '11 at 21:56
  • 3
    http://meta.stackexchange.com/questions/25209/what-is-the-official-etiquette-on-answering-a-question-twice – LachlanG Feb 20 '11 at 22:09
  • http://meta.stackexchange.com/questions/60445/is-it-ok-to-post-multiple-answers-to-a-question – LachlanG Feb 20 '11 at 22:24
  • @Lachlan: But did you see Jeff Attwood's answer to http://meta.stackexchange.com/questions/25209/what-is-the-official-etiquette-on-answering-a-question-twice. He directly advised against multiple answers from the same person - he views it as a sign of a bad question. – Marjan Venema Feb 21 '11 at 07:01
  • @Lachlan It just looks like you are hunting for rep. It results in the question becoming fragmented. You've got some excellent stuff here and if you combined it all into one answer it would be a very good resource. You also appear to be a serial offender when it comes to multiple answers to the same question. – David Heffernan Feb 21 '11 at 08:39
  • 3
    @David: I couldn't care less about this silly reputation game. I post multiple answers when it's appropriate because that makes for the best long term resource for others. – LachlanG Feb 21 '11 at 18:44
  • 2
    @Marjan: Yes I did see Jeff's answer and I noted that he received not a single upvote for it. The overwhelming number of answers and upvotes in both meta questions I linked to were in favour of multiple answers when proposing very different approaches. As Jeff Atwood says over and over in his blog, he doesn't run StackOverflow the community does and those 2 questions were the best representations of community opinion on the matter I could find. – LachlanG Feb 21 '11 at 18:53
  • @LachlanG: Was just asking (I did upvote your comment with that link) coz I found it interesting that Jeff's opinion goes against the grain and he's one of the few who certainly won't be interested in rep gain, while almost all others **may** (not saying they do, but they **may**) have that on the agenda... – Marjan Venema Feb 21 '11 at 19:32
  • 1
    @Marjan: Full credit to Jeff Atwood for not overruling the community on a matter in which he clearly disagrees with the majority. – LachlanG Feb 21 '11 at 20:01
  • 1
    @Lachlan @Marjan Actually, on reflection, I'm now coming round to Lachlan's point of view, certainly for these particular answers. They are very distinct and the question does provoke brainstorming. It's not as if there is one single right answer - in fact far from it. I retract my earlier statements! – David Heffernan Feb 21 '11 at 22:19
  • 1
    @David: Thank you for giving the matter your full consideration. Due to timezone differences (most Delphi questions are asked and answered while I sleep) and speedy answerers like yourself there are usually very few questions left for me contribute to. When I do spot one still unanswered and within my range of expertise I like to go all out. – LachlanG Feb 21 '11 at 23:19
  • 1
    @Lachlan Well, you left no stone unturned this time round, that's for sure! ;-) I'm going to take a look at OPTIONSETS some time soon. I've never worked them out but with your tutorial to hand I'll hope to do so this time! Thanks. – David Heffernan Feb 21 '11 at 23:21
4

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.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • The .dproj files get screwed up so often (and that doenst interfere with the build process), we stopped restoring them from the vcs on a regular base. Every now and then i straighten them up and check them in again. – Bascy Feb 20 '11 at 20:20
  • 1
    Do the .dprof files feed into your build? If so then you need them versioned. – David Heffernan Feb 20 '11 at 20:21
  • I'm struggling to understand your issue. If the IDE messes up your files, you need to get them back to a "known good" state. Doesn't the VCS do that for you? – David Heffernan Feb 20 '11 at 21:30
  • Because the dprj files are messed up so often, we've stopped correcting them before we check them in. Like i said it doesnt interfere with the build process, it just looks odd in the IDE. – Bascy Feb 21 '11 at 08:36
  • dproj files, in my experience, only get screwed up when automatic build number increase is active. when both developers build, they will both get incremented and that causes a conflict in vcs. Other than that, you actually MUST add them to versioning, otherwise you lose a lot of needed data such as unit aliases which, when you lose, will cause a hell of a lot problems. – Tuncay Göncüoğlu Jun 16 '15 at 11:10
  • @TuncayGöncüoğlu Well, I wouldn't use any of the IDE's versioning features which I think are no good – David Heffernan Jun 16 '15 at 11:25
  • agreed there, but thats a matter of preferance. I myself am partial to GIT, with smartgit or just its default git-gui, or, even command-line git is great. – Tuncay Göncüoğlu Jun 16 '15 at 11:28
  • @TuncayGöncüoğlu No, that's not what I'm talking about. I'm talking about version info, auto build no. increment. That's what you are talking about. Change control is something else. – David Heffernan Jun 16 '15 at 11:32
2

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).
LachlanG
  • 4,047
  • 1
  • 23
  • 35
1

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).

LachlanG
  • 4,047
  • 1
  • 23
  • 35
  • We're using Starteam, and i'm not aware of a function like this. Would be awsome as I can see it solve several of our problems – Bascy Feb 20 '11 at 21:08
  • 1
    ExplicitHeight can be dealt with by DDevExtensions - you can set an option to exclude those properties when streaming – David Heffernan Feb 20 '11 at 21:10
  • @David thanks for that hint. Finally I know how to get rid of this annoying behaviour – Michael Küller Feb 20 '11 at 21:25
  • 1
    It would be even nicer if the junk changes and the real changes weren't automatically persisted. TBitmap properties are restreamed with a random-seeming hex changes in the images in the DFM for instance, every time you open them and make other changes. – Warren P Feb 21 '11 at 17:08
  • @Warren agreed, but who puts bitmaps in .dfm files? Images and other binary files should be included as resources. Putting them inside .dfm files makes versioning a nightmare. – David Heffernan Feb 21 '11 at 22:17
1

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.

Warren P
  • 65,725
  • 40
  • 181
  • 316
  • That's an interesting idea, generating DPROJ files. Do you know if the DPROJ generation code itself is released as part of the JCL itself? – LachlanG Feb 21 '11 at 19:07
0

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.

Chau Chee Yang
  • 18,422
  • 16
  • 68
  • 132