Cobol Source Code Control system

[Migrated content. Thread originally posted on 11 May 2011]

Does anyone have any experience with a Cobol source Code Control System? which one?

I have been trying to understand TortoiseSVN and TortoiseHg but thought there mught be a better system out there somewhere.


  • Hi Dater,

    We have been using SVN on a Linux SuSE server since 2 years ago, we are very happy with results, actually we are more organized than before and we always found the cobol source code and the specific changes made to it.

    As client we use Tortoise on a Windows XP machines, with NetExpress 5.1 and Dialog System.

    In fact, Dialog System files, are the only problem that we have, cause they are binaries and svn can't compare it.

    We use simple structure on svn, just a Project/trunk, and if we need move to another version, we make a brach version2/trunk.

    I hope that this comment serve to you.

  • Do you have a plugin for TortoisSVN to MFC or are you using the Windows Explorer interface?

  • Any source code control system should work with COBOL sources. I've used a number of them, within and outside Micro Focus.

    There are basically four kinds of SCCSes:

    - Local-only, exclusive-access (locking) revision control systems, such as the original SCCS itself and RCS. These are relatively straightforward because they don't have many features. They're rarely used in modern software development.

    - Shared-access merge-and-commit file-based systems, such as CVS and Subversion. These enhanced the exclusive-access systems by making it possible for multiple developers, typically on multiple machines, to modify the same sources at the same time. Still fairly straightforward, though they require some understanding of the merging process.

    - Non-centralized distributed data-based systems, such as git. These systems are more flexible than centralized ones like CVS and Subversion because there is no central repository; developers pull change-sets from, and/or push them to, each other. These systems also typically track individual chunks of data rather than the files they appear in, so they understand moving a block of code from one file to another, for example. Significantly more complex, particularly the free implementations.

    - Alternative systems, which use a number of approaches. StarTeam's object-based system is one example.

    If you're finding Subversion confusing (note that TortoiseSVN is just a front-end to Subversion; it's not a separate SCCS), I suggest reading the "Subversion book", which you can purchase or read for free online at

    There are various open-source and commercial add-ons to integrate Subversion with Visual Studio and Eclipse - just search for eg "subversion visual studio plugin".
  • My questions are: Can Microfocus COBOL be version controlled using SVN? Is there a TortoiseSVN plugin for Microfocus COBOL? Thank you,
  • My questions are: Can Microfocus COBOL be version controlled using SVN? Is there a TortoiseSVN plugin for Microfocus COBOL? Thank you,
  • Godfrey originally wrote:
    My questions are: Can Microfocus COBOL be version controlled using SVN?

    Subversion is a general-purpose revision control system. As far as it's concerned, Micro Focus COBOL sources are just text files, like any other text files.

    You don't say what COBOL product you're using. The older Windows Net Express IDE uses binary project files. You can put those in Subversion, but it can't show diffs or merge changes from different branches. The same applies to things like images (for example if your project includes icons). Again, this isn't specific to COBOL; it's how Subversion works with anything.

    Is there a TortoiseSVN plugin for Microfocus COBOL?

    I don't know what such a plugin would do.

    Also, note that TortoiseSVN is a Windows Explorer plugin for Subversion. Subversion is the actual change management system - TortoiseSVN is just an interface to it.
  • I have a similar question. We are currently converting our legacy code from Net Express to Visual COBOL and have been playing around with Subversion. We are also currently looking into switching to Mercurial because of confusion around merging with Subversion. Anyway, what is the best way to organize all the individual modules comprising our system? There are around 1500 source modules and many of them are shared, common code modules. For example, do you recommend putting all the modules into one project, creating a project for each module, grouping modules, etc.?

    Also, is one version control tool better for legacy code over the other?
  • It's impossible to give a general answer to how projects should be arranged - it really depends on your specific sources and how they're related to each other. Broadly speaking, "one big project" is not a great idea; it's better to split code up into functional units.

    I've never used Mercurial, so I can't comment on it.
  • Verified Answer

    We Can very well use "AnkhSVN - Subversion Support for Visual Support"  . This could be easily hooked up with Visual Studio. Let Me know if i need to provide. Just Add the Plugin and Configure and Start using it.