Monday, April 30, 2007

Parallel or Serial...

Steve Trefethen has been posting some great information about our use of the Subversion source code control system and Cruisecontrol.NET.  One thing that I've noticed is that over the years version control systems are becoming more and more sophisticated and have finally begun to realized that version control is not just about files.  It is also about configurations.  They're also starting to realize that files are islands unto themselves.  How many larger projects have you worked on where adding a feature, fixing a defect, or refactoring operation affected only one file?  Project changes come in the form of “change-sets” or a group of interrelated files and configurations.

Prior to coming to work for CodeGear (and Borland), I was using a stand-alone version of PVCS and was manually doing check-ins and check-outs on a per-file basis.  So I already knew the value of version control systems, even ancient and early systems like PVCS and it's predecessor, RCS.  One of my first tasks on the day I arrived at work, was to “check out” the development tree from the PVCS archives.  What was different was that there were a whole suite of internally developed tools and wrappers around the PVCS command-line with other command-line tools.  These tools allowed “scripting” of the check-in process whereby the developer would fill in a “script” text file that contained the references to all the files to be checked in along with a space for a comment associated with each one.  There was also a global section for adding a summary comment that was a suppose to describe in higher-level terms what was included in this check-in.  This information was appended to a running log file that was used by QA to assist them in figuring out what R&D was actually checking in.

The one key point to all of this was that we never employed any kind of locking model that seemed to be so prevalent among the vast majority of version control systems, including PVCS.  So I learned the modify-at-will and merge-when-needed mode of working with the source trees.  I remember getting into philosophical discussions with folks regarding the overall merits of the lock-modify-checkin modal compared to the modify-at-will model.  I came to refer to these models as the Serial and Parallel models, respectively.  Over the years, there was a lot of effort put into layering tools over the existing version control systems in an attempt to “fix“ many of their drawbacks.  When working in a parallel model, nobody is ever blocked from making changes, but that does require a little bit more from the tools.  The issue of an atomic checkin becomes way more important since the archives can be changed by one person while another is in the midst of a bulk checkout.  The chances of getting a partial check-in has greatly increased.  Some folks tend to use these “drawbacks“ as a reason for staying in the stone ages of lock-modify-checkin.  However, with the proper discipline, toolsets, and overall mindset, the parallel model is very liberating for a team.

It seems that after many years of debate, the parallel model is beginning to hit more mainstream.  It kind of started with the introduction of CVS.  However, CVS suffered from one major problem; the lack of an atomic check-in model.  It also suffered from not being able to handle binary files in a very efficient manner.  Subversion was introduced to solve these (and other) issues.  In fact, Subversion's main charter was to supplant CVS as the dominant open source (or otherwise), version control system.  I must say that after using Subversion on the Developer Studio team for a little over a year, they have a real shot at retiring CVS.

So, how does your team work?  Serial or Parallel and why?  I do understand some of the virtues of the lock-modify-checkin model.  But as your team grows and/or becomes more geographically disperse, you may begin to notice that team members are forcefully breaking locks in order to get their stuff checked in.  One bit of advise I can give you and your team should you ever move to a parallel model is to get yourself a very good source code differencing/merge tool such as Beyond Compare or Araxis Merge.  Make sure *all* your .dfm files are checked in as text (this allows easy diff'ing and merging of changes).

So, there's your assignment.  Let me know how your team works, what version control system you use and why?  One's choice of VCS systems can sometimes elicit nearly the same passionate responses as one's choice of development tool.  I'm looking for objective analysis and an understanding of why you came to that descision.  Things like, “I use XXX because everything else sucks!” are simply not helpful. 

I'll start with why we chose Subversion.  It closely matched our overall development process, had true atomic check-ins, extensive and growing number of supporting tools, it also handled renames, moves, and deletes very well.  Every check-in is represented by a single revision number which can be used to check-out the entire source-code tree by using only one number.  No need to use error-prone dates or create a tag/label for every checkin.  It was also a natural fit for our extensive use of CruiseControl.NET continous integration server.


  1. We use SourceGear Vault. We were previously using SourceSafe, but basically we didn't trust it.

    We chose Vault because it had good distributed support (our repository is on a server in Japan, we have developers in New Zealand!), atomic check-ins, and a very similar UI to SourceSafe, which we were familiar with.

    We also considered StarTeam and Subversion. Frankly the UI on StarTeam left a lot to be desired, and Subversion missed out because we were happy with the SourceSafe based UI which we were already familiar with.

    We use a lock-modify-checkin approach, but we do use the non-exclusive locking, so I would consider it a hybrid serial/parallel approach. We use Araxis Merge for diff/merge.

  2. We use JEDI VCS to develop JEDI VCS and it does support only the Serial model so far.

    Currently the Serial model is no problem for us, but however we've planned to support the Parallel model in the future.

    I personally don't prefer the Serial or the Parallel model, but I have to say something additional to your advise regarding the diff/merge tools.

    If I haven't missed anything then all these tools treat the files as text and that can be a little problem in my POV because for example .dfm files represent objects and should be ideally treated as objects.

    Furthermore form files consist of at least two files (.pas/.dfm) which has to be in sync. I don't think that the diff/merge tools can asure this because they don't know about this relationship.

    Everything gets more and more complicated if you use form inheritence...

    BTW, thanks Allen for the Open Tools API.

    For the 3rd party source control integration it would be very nice to resolve QC 44457 (QC 37904).

  3. I would be more interested in hearing why the DTG group dropped or passed over StarTeam - I can't imagine upper management was very happy about it.

  4. We use Subversion (and TortoiseSVN, of course). Prior to that we used VSS, but we were fed up with how often it corrupted our repository, and with having the entire team idle for most of a day while it was repairing the repository.

    We looked at several different source-control systems, but Subversion won out. Atomic commits were a *big* reason for that; I was really pushing for that feature. It's surprising how few revision-control systems have atomic-commit support (Vault was the only other one we looked at that supports it). The repository-wide versions, cheap branching, and price tag (or lack thereof) were also important factors.

    The transition to a "parallel" model was far smoother than I had expected. There was a learning curve for all of us, of course, but now I can't even imagine doing a lot of the things we do with a "check out each file" model. We can do big refactorings that would have been a real pain with VSS.

  5. Our team uses VSS but we are evaluating Subversion now.

    I personally use Araxis Merge - I don't know how any developer could function without an application like that.

    I vastly prefer the parallel model - I could never do the major refactorings I do without it.

  6. I sorta dragged our whole team from SourceSafe over to Subversion. The impetus was the inability to easily host a SourceSafe repository on the web and I grew tired of a co-worker or myself forgetting to do a check-in thus bringing development to a screeching halt.

    The big reasons for picking subversion for us were:

    1. Easily make repositories available via the web (tcp\ip). The built in svn server was a huge asset as well, no Apache or IIS config to worry about.

    2. Solid support for renames/moves while keeping history.

    3. How tags/branches are just diff copies so tags are super cheap.

    4. Easy to script for automated builds using command-line.

    5. Easy to setup on build machines, no license issues or activations to worry about when setting up a virtual build image or a separate build box.

    6. Great UI with TortoiseSVN, integrates nicely with Explorer.

    7. Great support for bug tracking integration with the bugtraq properties. We went with trac.

    We use subversion to manage almost everything, and that includes all our websites, all our desktop apps and even all of our third-party components. The only issues we had were are first, before people were used to the morning update, nightly commit cycle.

    I do run into some Delphi-specific annoyances, like the fact that every time you compile a COM DLL it re-writes the date/time into the comment section of the _TLB.pas file, which then makes it seem like the file needs committing or learning how to manage the .RES file, which again always changes. Now we just don't add the .res to the repository and instead build everything from .rc files. Those really have nothing to do with svn, just little quirks in managing a VCS.

  7. We use FreeVCS/JediVCS for a long long time now; reasons where that it was free, but most important it allows you to directly get at the checked in files in the Database, which is nice if something goes horribly wrong.

    That it's possible to store the archive in an Oracle DB was the ultimate argument for us, since we already have the infrastructure for Oracle up and running, including automated backups.

    Since then we're kind of stuck with it, as we have so many projects in it. We've considered switching to other systems now and then (CVS earlier, SVN more recently), but our problems with JediVCS aren't big enough to make us actually switch.

    Besides, the integration of SVN into the Delphi IDE isn't as good as what JediVCS has to offer. (At least the last time I checked, please correct me if I'm wrong.)

    We prefer the serial model; but that might simply be that we're so used to it; a lot of my colleagues aren't trusting in the (automated) merging systems you have to use when going parallel.

  8. daniellodeito lodeiroMay 1, 2007 at 3:44 AM

    which are the reason to CodeGear don't use starteam?

    is subversion + TortoiseSVN a better solution that Starteam?

    kind regards


  9. Hello.

    There is a very nice, open source visual diff program for Windows:

  10. David R. RobinsonMay 1, 2007 at 6:14 AM

    We used VSS briefly where I am now. We used it extensively where I used to work. VSS was great in its day, but MS basically bought it and did nothing with it. We used the serial method when using VSS.

    We started using SVN/TortiseSVN over a year ago and now use the parallel model. I was used to the serial approach and had concerns about the parallel approach, but I am totally sold on the parallel approach now.

    We have every source file needed to create our product including 3rd party Components in SVN now. The only source that is not in SVN is the VCL source--which we rarely modify--but have on CD if we need to reinstall from scratch. We have our Delphi source, MSVS Source, Installer (Inno) Source, Final Builder Source, Documentation Files, etc. all in SVN.

    Our build process is integrated with SVN in that it automatically checks out the HEAD from SVN, builds the files, and then updates the SVN database with the version info that was used to create that build. This way we can easily revert to the entire source used to create any revision.

    Where I was before, we had large VSS databases and they would get corrupted frequently. Unfortunatlye, We have had corruption in our SVN database as well.

    The main thing that I wish was different about SVN is that uses a file based proprietary database (just like VSS does). If SVN used a real SQL server like MS SQL or InterBase as the database, it would be perfect.

  11. I prefer parallel development. We use Team Coherence here, but I use Subversion at home.

    "One thing that I've noticed is that over the years version control systems are becoming more and more sophisticated and have finally begun to realized that version control is not just about files. It is also about configurations."

    When are we going to be able to check in/out our Delphi configuration? :) I'd love to have packages, etc. based on relative file paths.

    Changed dev machines? no problem, install Delphi, get the code/components/config from the version control server and go.

    Added a new team member? No problem.

  12. We use Sourcegear Vault in "parallel mode" integrated with bugtracking system Sourcegear Dragnet.

    1. Reliable

    2. Remote access. Server side is exposed through web services.

    3. User friendly easy to understand user interface.

    4. Concurrent development style / Parallel development / Atomic checkin transactions.

    5. Affordable.


  13. We use CVS. When I started at current workplace, they didn't use any VCS ! I did know CVS, so we decided to to use CVS.


    1) Parallel

    2) Affordable

    3) UI topped with WinCVS

    On top we use WinMerge as the diff tool.

    Haven't looked at other systems, primarily because CVS works as expected for us.


  14. Hi,

    I have used several different VCSes at different companies:

    1. none at all (really dangerous)

    2. something written internally (hm, no, don't want to go back)

    3. Perforce (reasonbly OK)

    4. MS Sourcesafe (sucks big time)

    5. CVS (better than 5. but ...)

    6. SubVersion

    7. FreeVCS

    8. SubVersion

    I had a say in the decisions 5. (SubVersion didn't exist then) and 8 and I am now fairly happy with using SubVersion + TortoiseSVN. Perforce was as OK as a VCS, but the UI sucked.

    As for diff tools: Tortoise Merge is OK, but not great. I have always replaced it with BeyondCompare.

    And since we are talking about Delphi and SubVersion: Could you please reduce the number of binary files (You said yourself: use text .dfms.)? I am thinking about the .res file in particular. I don't want to check it in because it changes with every build (autoinc buildno) but this change is already tracked by the .bdsproj file. But if I don't check it in, I lose the icon. Also it seems to be the master source for the version information, so everything in the .bdsproj file is overwritten if a .res file exists.


  15. Hi,

    We are currently using Visual Source Safe but are about to upgrade to a different tool. This because Visual source safe has some major drawbacks: it tends to currupt and it does not allow you to do parallel development (without performing some tricks). Also the sharing model is only on file level.

    Since we want a fast time to market and developing several projects at the same time, we want to support parallel development. We use the mainline model as base for version management.

    In the selection of a new tool we had two serious candidates: Perforce and Starteam. In Perforce there is extensive support for integration with other bugcollection tools. But since our current bugcollector is not very stable any more because of the design limit of this tool(1 Gb), we chose Starteam. The possibilities for RFC's in Starteam fit our development proces.


  16. C Johnson


    I asked the exactly same question to Steve and he answered. In few words, the reasons:

    1) Atomic checkins support

    2) Less maintenance

  17. So Allen, have you you been driven nuts by the amount of "explicitwidth/height" litter Delphi leaves in otherwise unchanged .dfm files yet?

    I hope you guys consider putting in an option to disable these properties.


Please keep your comments related to the post on which you are commenting. No spam, personal attacks, or general nastiness. I will be watching and will delete comments I find irrelevant, offensive and unnecessary.