SVN for Delphi Developers

Question

I have posted a question before, Moving away from VSS, in which I asked about the best VCS control for Delphi developers who were using VSS. Most developers seem to use svn with TortoiseSVN. I tried this for few days and I think it's the best route to go with.

However, I still have some confusion about the way that svn works so here are a few questions that I'd like answered:

1. Can I work with old lock way(checkout-modify-checkin) that vss uses?

2. Delphi forms have two files (MyForm.pas, MyForm.dfm). When I add any control to the form, both files will be modified so I want to commit "myform.pas" and have "myform.dfm" commit with it too. Am I missing anything here?

3. The same applies for the Delphi Project file. Because this links with other files, all of them should be committed when I change the project file.

4. What files do you have marked to be ignored in TSVN, so TSVN will not look for these files like (.dcu,.exe, ...), and can I export it from one Pc to other?

I now have to change the way I'm thinking in vss style, and need to change it for SVN style, but with vss, all things were managed within the IDE, which was fantastic ;-).

UPDATE:

5.If I commit the Delphi form(.pas & dfm) and found some one already updated the version before, how do you resolve the conflict if there some new controls and events added to that form and unit(this require Delphi developer with svn).

Answer 1

Here's what we see with DFM file behavior: * regardless of the Delphi version in question, the IDE likes to prompt the devoloper to 'save' a form, even if no true changes have occurred in the DFM level of the PAS level. Example: developer has slightly repositioned the design window for formX in the IDE, but has done nothing else to formX. Under VSS, the readonly property on the files acted as police-- made sure no 'non-change changes' became candidates for checkin. * under D2006, and possibly under cousin IDEs such as D2007 and D2009, something worse is afoot, in our experience, for developers sitting at WinVista or Win7 boxes. certain actions with the form, in design mode, will "shift' pixel values in the underlying DFM. and shift by small enough values (2,6) that the developer MIGHT not take notice. Panels and scroll boxes seem especially vulnerable. all this without intent of developer. under VSS days, this was small nuisance, since only DFMs explicitly checked out were at-risk regarding the "shifting'. under SVN/Tortoise, this problem grows, as there is no readonly attrib protecting files. Yes, true, ultimately the develper is responsible at check-in time for closely examining what's changed, at the DFM as-text level. But this is a hassle, adds overhead to the dev cycle, and we sure wish this was not so. Interestingly, this "shift" does not occur at WinXP workstations. WHY THIS MATTERS, for the SVN/Tortoise community. Anyone checking in DFMs in a hurry, for whatever reason, risks letting the "shift" take over effective command of their UI. And makes one nostolgic about the brute-force VSS read-only attrib; even to the point of considering use of the svn:needs-lock property mentioned above. MISS I HAD SOME SOLUTIONS TO OFFER, but so far we find ourselves only with variables, and are game-planning how to minimize DFM issues with our SVN/Tortoise implementation. FYI, we see no Embarcedero posting on the "shift" symptom, at this time.

Answer 2

DFM files do not change on their own, for me.

I'm not sure what other people are doing to their dfm files, or what settings in Delphi might cause this. I have no problems. Only the dfm files I change are listed (as changed) in the Commit dialog. I am using Delphi 2007 and Delphi 7.

Answer 3

I usually use this little python script before updating from SVN, in order to clean my source tree.

I store the .dof files in SVN so I need to commit manually any .dof change before cleaning the source tree.

import os
import sys

exts = ['.~pas', '.~dpk', '.~bpl','.dcu', '.~dcu', '.dcp', '.~dcp',
        '.dof', '.cfg', '.res', '.~res']

def mydir():
    if __name__ == '__main__':
        filename = sys.argv[0]
    else:
        filename = __file__
    return os.path.abspath(os.path.dirname(filename))


def clean_dir(arg, dirname, names):
    for name in names:
      if os.path.splitext(name)[1].lower() in exts:
        file2delete = os.path.join(dirname,name)
        print os.path.join(file2delete)
        os.remove(file2delete)


if __name__=="__main__":
  print "Cleaning Tree"
  os.path.walk(mydir(), clean_dir, "a")

Answer 4

You could us SourceConexion. It integratesin the Delphi IDE. It supports locking of files so that you don't end up in trouble with the DFM files.

I use TortoiseSVN when working with C# but in Delpi I find it good to be using SC since I ended up with corrupt DFM files after more then one developer had done changes in them..

Answer 5

Re 5.: You should try it out. To limit the conflict potential it is a very good idea for the active developer to commit often, and for all others to update often from the SVN. Setting up email commit notifications can help a lot, so that all people know when to update. But having said that - you will find that the simple act of deleting a control and all its event handlers, or adding a control and a few handlers will not lead to conflicts that you need to resolve manually.

Edit: This answer by DiGi states that Delphi modifies the DFM even when the user did not. This is not true IMO, as a simple change in the timestamp of the DFM does not qualify as a local modification of the DFM file, and SVN will not commit a new revision. One has however to be careful to not move the forms in the Delphi IDE, as this will change the Top and / or Left properties of the form. Similarly changing the active page of a page control would count as a local modification. Before committing it is therefore a good idea to examine all local modifications, and revert all those that are merely accidental.

Edit 2: As onnodb pointed out in his comment there seem to be properties of the form that are indeed modified automatically, at least with Delphi 2007 (and probably later?). This would underline the importance of checking all local modifications before committing.

Answer 6

Developers can use CommitMonitor to receive information about new commits.

ad 5: It is bad if two or more developers are using same .dfm. Simple modifications can work (merge) fine. it is important to commit only if you are really made difference in files. Delphi usually modify .dfm even you don't change anything.

Answer 7

Also see How do I start with working Sub-Version + Delphi? for some SVN tools which also integrate into the Delphi IDE.

Answer 8

1. Yes, you could still lock files, but it's not recommended. You have to set the svn:needs-lock property on all the files you might want to lock so they get the readonly flag set when you check out. But again, that's not the recommended work flow for text files. Just give the modify-merge work flow a try!
2. Since you're using TortoiseSVN: right-click on your parent folder, choose "Commit". In the commit dialog, you will see all files that need committing. Just check both the myform.pas and the myform.dfm file for the commit. All checked files will get committed together, no need (and definitely not recommended!) to commit each file individually!
3. See 2. - But you should read the wonderful Subversion book first to get familiar with the concept. You should always commit all files that belong to a logical change. For example, if you add new controls to your form and implement the code to handle it, you may have more than just the form files modified but several files more. Always commit all those files together since a commit is a logical entity.
4. You don't have to 'export' ignore settings. Just add the svn:ignored property. That's very easy to do with TortoiseSVN as explained in the docs.

Answer 9

1. Yes.

2. TortoiseSVN automatically marks all modified files under version control when you commit.

3. See 2.

4. It's very easy to create an ignore list. Just right click a file and you get an option to ignore all files of that file type.

If you're using Visual Studio, you can use Ankh SVN for IDE integration.