Source code mgt / Version Control on OpenVMS

[John T. Farmer]

Hello,

I am searching for recommendations for tools to manage source code in the openvms environment. We expect to be on this platform at least another 12-18 months, but probably not more than that. Mainly looking to manage code check-out / check-in. We have scripted DCL procedures to move code between dev and prod, but nothing to prevent conflict of two developers moving different versions of the same program or to alert developer-b that developer-a has the program out for modification.

I had previously used tools based on CMS, have heard about, but not used HP's DEC-Set tool. Saw in an older thread

"http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1233157267414+28353475&threadId=1054087" with referneces to VDE and Subversion. So that I don't go on a wild chase, I'd appreciate your comments. I have a openvms server in my lab where I can test anything you folks recommend, but want to only bring one or two candidates in for actual proof-of-concept on dev/prod servers.

Thanks,

John Farmer
john dot farmer at genworth dot com

[Peter Zeiszler]

I remember CMS on VMS but its been ages since I used that.

What about CVS on openVMS? I think its on the freeware CD. This is the current tool we are using on VMS. We use RCS on some of our unix and I thought someone was working on RCS port to VMS.

[John T. Farmer]

I recall looking for a CVS client for OpenVMS when I first started looking a couple years ago. Had trouble finding a build at the time. What platform hosts the repository, Windows, Unix, etc.? Could you share your version of the CVS client? What version of CVS client and server components are you using.

Thanks,

John

[Craig A Berry]

Wanting only one or two candidates is a wish that's easily granted. As far as I know, CMS and Mercurial are about the only viable VCS's out there that run on VMS.

CMS *is* HP's DECset tool:

http://h71000.www7.hp.com/commercial/decset/decset_index.html

Mercurial is a modern Distributed Version Control System (DVCS) written mostly in Python. It's now used for quite a few large projects, including Mozilla, Java, and Solaris. The VMS port is available here:

http://www.vmspython.org/DownloadAndInstallationMercurial

There is a Java-based Subversion client that runs on VMS, but as far as I know there is still no native port of Subversion or way to host the Subversion repository on VMS. There is/was an older CVS port, but that's really a step backward.

What's right for you depends on your workflow and whether spending money is an option. CMS would better support the workflow you describe of preventing conflicts before they happen. DVCSs like Mercurial don't attempt to prevent conflicts but depend on sophisticated tools for resolving the conflicts that are considered inevitable on a project of any size. There might be some advantage to using a system that can move with you when you change platforms, and that would rule out CMS as far as I know.

[John T. Farmer]

In the earlier days of my search, CMS was ruled out due to cost and the expected "short" life of our VMS application. That's now been almost 3 years and my 12-18 month window is still sliding. But I think CMS & DEC-Set will be to costly in the time I have left. Will look at Mercurial in the lab and see what it offers.

Thanks,

John

[Hoff]

As a long-time DECset CMS user, I've found it stable and entirely functional, and I would no longer typically choose to install and use it.

I'd tend to look to use one of the available Hg or SVN clients, or dig around for a Git client. I'd also likely tend to keep the repository on another box, as servers are less commonly available on OpenVMS. This can have issues around certain file formats, however; there may well be a conversion to Stream LF format, for instance.

VDE (I maintained and updated and ported that tool over many years) is built on Rdb and DECset CMS and a few other pieces. It's a very expensive piece of Freeware, given its prerequisite products.

[Craig A Berry]

The notion of keeping "the repository" elsewhere is somewhat anachronistic with a modern DVCS like Mercurial (or git). Each developer has his or her own copy of the entire repository and its complete history and the repository actually sits inside of the working directory. You can certainly have everybody push changes to a centralized or authoritative copy of the repository and produce your releases from it, but that's optional.

Subversion, on the other hand, does support/require a more hierarchical model, so getting SVNKit (the Java Subversion client) on VMS with the central repository elsewhere would be one option, and not a bad one either given the ubiquity and popularity of Subversion and its relative robustness compared to CVS and other predecessors.

[Chris Barratt]

If you are only dealing with VMS code and VMS development, and you have a team small enough that they are unlikely to be working on the same program at the same time, then you could consider just setting up a couple of command files to handle checking in/out in the development environment.

What we do here, is keep all production ready source in directory (or one per project), have a work directory into which we checkout (via command file) the items we wish to work on. We edit/compile/test on code in this directory and when ready check it back into the production ready area. If someone tries to check out something that is already checked out, this alerts them to the fact that someone else may be working on it and they chase it up.

There are a few more complications, but in a small environment it is quite do-able and works pretty well.