up vote 8 down vote favorite

This isn't quite so much a question about how it was done "back in the day", but what my options are today for source code/version control on an MS-DOS machine. I enjoy tinkering with Turbo Pascal, Turbo C, and Turbo Assembler on my HP 200LX, which runs MS-DOS 5.0 on an 80186-compatible processor, with 640 KB of RAM, plus a little bit of EMS. I would like to be able to keep past revisions of files to revert or track down bugs if/when I screw something up.

What are the viable choices for source control on such a machine? I do not require any kind of network support, simply a local file-based repository. If it compresses committed files, or stores only differences, that would be a plus, as I don't have tons of disk space on this thing.

I've looked briefly at RCS in the past, but it's a bit clumsy to work with, since you have to commit/check out single files at a time (along with its bizarre default behavior of deleting the working copy when checking in), and I'm not sure if there's a "commit all changes" option akin to git add ..

share|improve this question
  • 1
    @Ross I wrote “16-bit DOS” intentionally ;-). – Stephen Kitt Jun 1 at 14:13
  • 1
    @Raffzahn yes, DJGPP (and its predecessor, DJGCC) have always required a 32-bit CPU. – Stephen Kitt Jun 1 at 14:44
  • 2
    If you don't want the "retro-feeling" when using source control, my immediate idea would be "network drive or laplink to a modern computer, put copied files into git repository". Gets the job done, while allowing you to undo any mistakes. – dirkt Jun 1 at 15:51
  • 2
    Is there any reason that git couldn't be ported to MS-DOS(or FreeDOS)? I'd imagine you'd have networking issues, but if you were working in a local repository is there any technical reason it wouldn't work? – Skoddie Jun 1 at 18:15
  • 2
    @Skoddie: I'd assume it would use too much RAM, and be too slow - the git format isn't really optimized for an 80186 system. But nothing stops you from cross-compiling it, and trying it out... – dirkt Jun 2 at 16:30
up vote 8 down vote accepted

RCS should work for you. I used it in the past. But, as you noticed, it's a rather primitive tool set.

That can be mitigate a bit with some custom scripting, which is what I did.

CVS, in fact, started essentially as a scripting layer on top of RCS.

I ended up having a script that worked on a single directory. As all code at the time was that way, this wasn't a big deal.

Today, we'd have a large source tree representing everything. Back then, I had several modules of source code, each in their own directory (mind, these were essentially stand alone modules with little dependency on each other), and within each directory was an RCS directory (I forget what the name was, for some reason something with ",v" comes to mind, or .rcs) that managed the source code. Actually I think it was a .rcs directory, and files were stored in a ,v file. So hello.c was hello.c,v -- something like that.

Then I had scripts that would "check in" and "check out" "everything". By everything, I mean my source code and build files. It wasn't so much "check in *" but more "check in Makefile, *.this, *.that". Then there was similar some introspection in to the RCS dir as to what to check out.

My use case was mostly as a versioned back up. We didn't do things like merges and branching and all that, RCS is really just a primitive versioned file system like construct.

When I had to recover things, it was all done by hand, cherry picking files, and what not.

The only concern is I can't say if the DOS .BAT files are robust enough to do everything that needs to be done. It's been some time (decades!) since I've done this, and it was on a UNIX system. If not, you might need to write some simple wrappers in Pascal or C.

But it was possible, it was workable, and helped save my bacon more than once.

I can't contrast RCS and SCCS, it just seemed at the time that the consensus was RCS was better than SCCS, so that's what I used. It was certainly newer.

Edit:

I should clarify RCS's behavior (yes, it's coming back to me now...).

As I recall, what RCS did is when you checked something in, it changed the files to "read only", when you check it out, it made them writable. This is in contrast to SVN and GIT which don't (at least by default afaik) do this. But DOS doesn't really have this permissions capability, but I'm not sure if this will be a real issue or not. I don't recall RCS deleting the files on check in, it simply locked them.

RCS may have too may unix-isms in it to really work well with DOS. You'd have to try it and see. But the takeaway from my experience was that it was a usable toolset with a little bit of scripting to make the day to day work well, and perhaps worth experimenting with to see if you can get it work for you. But go in with the expectations of what it really is, basically a versioned file system more so than a complete source code control solution.

share|improve this answer
  • 2
    MS-DOS does have that one permission capability, to make files read-only. – Ross Ridge Jun 1 at 14:24
  • It was important for me, because when I went in to VI, it would say "read only" which told me I had to check it out, I can see that being a frustration if the tools being used don't really indicate that but the OS prevents the tool (editor) from saving to a read only file. – Will Hartung Jun 1 at 14:26
  • Turns out you can get the latest PC build (5.7) directly from the official RCS site: cs.purdue.edu/homes/trinkle/RCShome Does RCS have an equivalent to git status, i.e. something to show which files are currently changed but not checked in? – db2 Jun 1 at 14:28
  • @db2 rlog -L -R RCS/* shows all the locked files (i.e. those which have been checked out), which tells you which ones have potentially been modified. rcsdiff will show you the changes between the working files and what’s been checked in. – Stephen Kitt Jun 1 at 14:36
  • For network sharing I seem to remember that we somehow we "mounted" the RCS directoryr. Certainly on Sun boxes we symlinked to a single RCS directory. By the time of Windows 95 Visual SourceSafe was an option (I remember using it before Microsoft bought it) – PeterI Jun 1 at 15:40
up vote 5 down vote

The Official RCS Homepage has rcs binaries for DOS.

ci -l is the way to keep the source file around. As you can only change one file at a time under DOS, the RCS process works rather well.

share|improve this answer
up vote 3 down vote

Not really fancy, but back in the days, I just zipped (*1) all source directories whenever I did any build that got handed to other developers/test users or when a release was due. It was done by a little script, that also incremented the build number and moved the archive onto a separate directory for backup.

Other scripts could compare two archives (or the last and the actual source tree) to find changed files or do a diff on a specific file. Without parameters, the actual tree and the last build was used, with one parameter that build archive and its predecessor, with two these too.

Since source files tend to be all text (with a lot of redundancies), the resulting archives where, even for large programms, small enough to fit a single floppy.

Maybe such a low-level approach could be a good start?

*1 - Or more correctly, I LHARC'ed it, as that was the tool I used back then.

share|improve this answer
  • 1
    My first job as a professional programmer was basically a single step up from that little script: a system that used a BTrieve database of projects and files, checked for files that weren't on the list, and automated archives of them when they'd changed. And an option to prepare a release to send to the client automatically. Written in Microsoft QuickBASIC to run on Novell Netware 3.0. :) – Jules Jun 1 at 21:39
  • 1
    I remember using ARJ back then, it worked really well on text files. – user230910 Jun 1 at 21:49
up vote 2 down vote

If you have access to a very old MSDN CD-ROM set, you might find Microsoft Delta, which was a MS-DOS source control system that I had to use in the early 90's, at a client site.

It was not very good and had obviously "escaped" from Redmond as some kind of April Fool's joke, but due to an apparent lack of alternatives, was adopted by a major UK-based enterprise.

It started as DOS command line, then went GUI for a while (just a wrapper). Luckily, MSFT bought SourceSafe, which was vastly better.

share|improve this answer
  • 2
    This answer rang a bell! Raymond Chen, of Microsoft, seems to think Delta was a commercial release of an internal tool named SLM; he also seems surprised it was released. See footnote 1 of blogs.msdn.microsoft.com/oldnewthing/20180122-00/?p=97855 (EDIT: via which you will find a link to download Delta, with its Windows GUI which is described as just a front-end) – Tommy Jun 3 at 16:49
  • Yes, Raymond's comment "It was very short-lived." in the footnote tells you all you need to know about Delta. – Steve Jones Jun 3 at 17:26
  • 1
    A company I once got acquired into had decided to use a shared document system for their source control. It was painfully obvious that this was not its intended use, but some engineers had dutifully created a large collection of scripts to work past most of the unpleasantness. They had so much time invested in the scripts and process that they were reluctant to consider alternatives (in our case, Perforce). I'm not a fan of SourceSafe, but there's something to be said for using a peg that's the right shape. – fadden Jun 3 at 17:32
  • 1
    @fadden At the time, SourceSafe seemed like the most sophisticated software ever written, compared to Delta. One of the guys I worked with back then said he was the source-control system at a previous site, in that he kept the "gold copy" of the source code locally and then when other developers wanted to make changes, he'd let them check out, make changes, then check in. It was all completely manual, with a spreadsheet of who had what checked out, but he said it worked well and canvassed for Delta to be replaced by him, as Delta kept corrupting our work. – Steve Jones Jun 3 at 17:38
  • SourceSafe was vastly better? Now that is a chilling thought. :D Wish I could find a copy of the old DOS versions, though, even if to just kick the tires. We used to use VSS at work for a couple of years before migrating to TFS, and eventually Git. – db2 Jun 4 at 12:10
up vote 1 down vote

I once used a commercial revision control system called TLIB on DOS. I don't remember liking it very much. Apparently, it's still being sold today, although I'm not sure if the current version will work in exclusively 16-bit mode. http://www.burtonsys.com/ has details.

share|improve this answer
New contributor
Ben Combee is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
up vote 0 down vote

You mention that RCS is not on the shortlist, but if you can get your hands on a later release of MKS RCS it has rudimentary changeset functionality that might be Good Enough. Given that all that MKS IP is owned by another company, and the older DOS stuff wasn't even supported for some time even before that, I can't suggest how you might get your hands on it.

But it was a surprisingly useful product for the time. It would be an easy turnkey solution if you could find it on eBay, for example.

Full disclosure: I used to work for MKS.

share|improve this answer
up vote -2 down vote

git is so much better than was available back then, so don't use those except for nostalgia.

When you want to commit, mirror your sources to a machine new enough to run git and do it there.

share|improve this answer
  • I was just wondering if it'd be possible to get git to compile under DOS. LLVM has a 16-bit 80x86 output target, getting git to build with clang rather than gcc shouldn't be too hard, and git's requirements in terms of OS support aren't huge. But unfortunately the LLVM 16-bit code generated requires a 386, so that's no good for this purpose... – Jules Jun 2 at 7:36
  • 2
    Of course, if you have an ethernet card, you can use a network filesystem (e.g. sourceforge.net/projects/etherdfs) to store your source files on a remote disk, and then you could run git instantly and easily just by switching to a different keyboard. That'd probably be the easiest solution. – Jules Jun 2 at 7:56
  • 80186 means segmented memory access. That means Turbo C or similar which probably cannot compile the git sources because they are too new. – Thorbjørn Ravn Andersen Jun 2 at 7:57
  • 1
    @Jules If clang's 16-bit x86 mode is like GCC's 16-bit mode then it's useless for creating significant applications. You're limited to 64k code and 64k data, and there's no C runtime library. However even with a complete 16-bit segmented C compiler porting git would be a major undertaking. It likely git assumes things like it can allocate objects bigger than 64k and int is at least 32-bits. – Ross Ridge Jun 2 at 13:49
  • 1
    @Thorbjørn Believe me, if there were a version of git that ran on a 186 with DOS 5.0, that's what I'd be using. ;) I'm running on a palmtop, and like sitting outdoors and programming, so I don't always have a modern machine at hand to do source control duty. I'll guess I'll just have to start rcshub.com to share source. :D – db2 Jun 2 at 15:25
up vote -2 down vote
  1. All source code revision control systems before 'git' sucked to various degrees.
  2. You are going to find many faults with the limited compatible choices.
  3. So, your best bet, by far, is to just "roll your own" simple, scripted process.

Roll your own is the way to go. When you break it down to the essentials, probably you can get by with a master and a dev "branch", and "tagging" of checkpoint releases. So, I would create a master directory and a separate dev directory, and a script for "merging" dev into master. I would also create a way of affixing "tags" with a script that just creates an archive of the code in the working directory in a separate location and with appropriate file naming to identify the "tag". 3 directories (master, dev, archive/tagged) and a couple simple batch files should do quite nicely, IMO.

share|improve this answer
  • 3
    And git sucks in it's own special set of ways. Every piece of software has issues, and 'roll your own' for something like source control is almost ever a good idea. – Michael Kohne Jun 3 at 18:08
  • 1
    @MichaelKohne I think "roll your own" is the only option here though if the original poster wants something significantly better than RCS. – Ross Ridge Jun 4 at 13:56
  • @RossRidge - If they can find older CVS binaries (I believe, but can not prove that CVS existed for DOS), then CVS is definitely the way to go vs. rolling your own. While it's certainly out of date, it's got enough features to take away the pain of RCS, while being something that could work in the target environment. – Michael Kohne Jun 5 at 12:59
  • git actually sucks pretty bad. Mercurial is better and so is Subversion if you are OK with a non distributed model. Git with SourceTree as the front end is less sucky. – JeremyP Sep 14 at 9:31

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.