[Info-vax] XQP File Versions (was: Re: What does VMS get used for, these days?)

[Stephen Hoffman]

On 2022-12-01 17:31:48 +0000, Johnny Billquist said:

> On 2022-11-08 22:21, Stephen Hoffman wrote:
>> On 2022-11-06 18:18:29 +0000, Robert Carleton said:
>> 
>>> Going a slightly different way, does files versioning help relieve the 
>>> programmers from some of the work necessary to roll back a corrupted 
>>> dataset when something goes wrong with their job? In the IBM world, 
>>> they talk about the production control analysts managing the batch 
>>> processing. I suppose file version control might be one of the tools 
>>> that they use, maybe in organizations that have a lot of duty 
>>> separation.
>> 
>> For small stuff, sure. XQP file versions can and do work. For more 
>> complex code changes as tend to be typical, file version rollbacks get 
>> gnarly as most change sets lack a consistent number of versions for a 
>> set of related code changes across a selection of files. Rolling back 
>> changes with file versions then means finding the right group of file 
>> versions. Which is usually not ;-1 or ;-2 across all of the various 
>> files involved in the source code change.
> 
> Not really an XQP feature. But ODS-[125]. The wise way to roll back is 
> by using the file timestamps, and not directly the version numbers. 
> That do work acceptably well if you just want to roll back to a 
> previous point. However, it's not as good/nice as a proper version 
> control system, I would agree.

The wise way is to use a version control system or DVCS. Not 
re-inventing a version control system from first principles and spare 
parts, and particularly not one built upon a PURGE-prone substrate of 
file versions.

>> XQP file versions also tend to need explicit management, and version 
>> cleanups can be hazardous for the practices used at some sites. And 
>> there's no good means to clean up intermediate file versions between 
>> those that a developer might wish to preserve.
> 
> There is a workaround for that, but it is a still a bit of a headache. 
> But protect the versions you want to keep from delete, and then run a 
> purge. Probably not a bad idea to protect versions that are significant 
> anyway, to avoid accidental deletions by fumbly fingers anyway. But 
> it's still rather semi-manual.

Versions are adequate for rolling back small-scale work. They're an 
increasing hassle as multiple modules become involved with one change.

>> IBM Rational Clearcase VOB is a very nice implementation of file 
>> versioning for app development, though that never really caught on more 
>> generally. The VOB presents a build or version or baselevel or whatever 
>> a developer or development team might call a collection of related 
>> source code changes, as a synthetic file system as a view from within 
>> the DVCS. The usual implementation here is based on a FUSE, which is 
>> fairly commonly feature available. There are undoubtedly some other and 
>> analogous implementations to VOBs, too. Switch the build or version or 
>> whatever, and the (virtual, synthetic) part of the file system you're 
>> looking and working within switches to what that build or baselevel 
>> would look like.
> 
> I think clearcase was very nice and cool. Almost all implementation 
> I've used did not use FUSE, but was playing quite a lot inside the 
> kernel (FUSE is rather new relative to this), but I can imagine they 
> would have moved over to FUSE as that started to appear. (I haven't 
> used clearcase in probably 20 years now...)

A git FUSE wouldn't surprise.

OpenVMS lacks FUSE-like APIs, though a user-written ACP can help with 
that. ACPs are undocumented, but not particularly difficult. Just don't 
decide to parallel the DECnet ACP, as that design is just weird. 
Parallel the magtape ACP, if you have source listings access.)

MOUNT would need some help here too were a FUSE to be added, as last I 
checked MOUNT was unable to launch a user-specified ACP, among other 
limits. It assumed anything mounted was a file system (which is not 
always the case), and MOUNT had direct knowledge of supported file 
system formats. Basically, anybody working in this area and with their 
own ACP gets to write their own MOUNT analog.

>> For the development projects I'm typically dealing with, pushing 
>> changes to the local DVCS is the usual approach when building stuff and 
>> is integrated within the IDE, and that makes rollbacks easy. Once ready 
>> to share, the code gets pushed from local into general availability. 
>> Getting better support in LSEDIT might help some, and other folks can 
>> choose to use VSC as that gets better integrated. If you're not using 
>> an IDE, then you're probably going to be getting familiar with git 
>> command line syntax.
> 
> Except git is not really a tool you want to use on the command line. 
> Referring to commits by hashes that are 64 for or so random characters 
> to type just is not doable. Cut and paste makes it sortof manageable, 
> but it still sucks big time.

I've yet to meet a command-line IDE. But then it's been a while since 
I've used RSX-11, too.

>> As a competitive feature, I suspect there'd be much more interest in 
>> integration with git or hg and with common IDE such as VSC than with 
>> the existing file versioning scheme. But sure, XQP file versioning does 
>> work for smaller efforts and smaller pools, and it does work when the 
>> developer and the local tooling is lacking. (Which it kinda is lacking, 
>> on OpenVMS. VSC and VGIT only gets you so far. The current compiler 
>> overhaul will absolutely help, as that becomes available. And that'll 
>> then help with better VSC integration, too.)
> 
> Didn't VMS have some tool for source control?

DECset CMS. Which was and remains limited in its scale and scope.

I think CMS ODS-5 support is now mostly working, though one of my 
favorite quotes is from the era when it wasn't: "the attempt to add 
ODS-5 support to CMS apparently turned into a Keystone Cops-like 
adventure for HPE."

CMS is unlikely to be a big draw, either. Maybe if DEC had done a 
distributed CMS, but that never happened. (There was some work to add 
that distributed support for a project based on CMS, but that work 
ended a very long time ago.)

>> XQP file versions have been around for over forty years, so probably 
>> not going to be a big draw for new apps and new developers. Not 
>> compared with git or hg or VSC or recent compilers or other of what are 
>> increasingly considered "table stakes" features.
> 
> Well, file versions existed in RSX about 50 years ago. No XQP, but ACP.

Still not a big draw, membership in the half-century club aside. File 
versions aren't a competitor for DVCS support. And OpenVMS DVCS 
integration and support is lacking, discussions of vgit aside.


-- 
Pure Personal Opinion | HoffmanLabs LLC