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

[Johnny Billquist]

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.

> 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.

> 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...)

> 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.

> 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?

> 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.

   Johnny