Re: Looking for suitable spells to get open to return a filehandle from a module

[kikuchiyo]

I'm working on what I imagined would be a simple module to provide versioned access to files (this is something that VMS provides)

May I ask why do you think you need this?

Even more impudently, may I suggest that you actually DON'T need this?

The reason I say this is that in a previous job I had to use a system that was similar to what you're trying to do, and it was an unmitigated disaster.

The VMS filesystem had a (mis)feature that files were versioned, that is, every filename had the pattern NAME.EXT;VERSION. If you accessed the file as NAME.EXT, you automatically got the latest version, but you could use other versions if you used the explicit version number. The point is that this was a built-in operating system feature and it worked transparently everywhere.

The geniuses at $previous_job must have missed this feature and implemented something like it when they ported their codebase to Unix back in the eighties - in a half-assed, imperfect way. They used NAME.EXT.VERSION filenames in a regular Unix filesystem, which meant that the mechanism to open/save the latest version only worked if you used their specially modified tools. If you wanted to use the regular unix commands (cp, mv, ln...), you had to explicitly refer to the files as whatever.1, whatever.2 etc., and the filesystem was full of garbage from the old versions.

But even if the such a system could work perfectly, transparently, it would still be inferior to proper version control systems, of which we have several mature, highly performant, feature-rich implementations.

The point here is that version control makes sense on the level of projects, not individual files. I'd argue that a versioning system that depends on individually versioned files (like VMS's scheme, or CVS) is actively harmful and worse that using nothing. The single biggest difference between SVN and CVS is that SVN uses a single version number for the entire project which gets bumped when any file is modified in the project, and this feature elevates it to a viable and usable VCS.

TL;DR use a proper version control system.

[talexb]

This is a fair question, and I appreciate that it has the potential to be a disaster.

I'm running scripts that do some ETL processing, and it would be handy to be able to version the result reports so that I could go back and see how this run's results compared to the previous result's runs. The tricky part is creating something relatively lightweight that I can sneak onto the command line, rather than remember to save the previous run's results (mv results.txt results.txt-5, for example).

I've also been meaning to contribute something to CPAN for far too long, and this is something relatively innocuous that might be useful to someone, somewhere. I could be using git for this -- but I need to stretch a little, and write something useful.

[kikuchiyo]

It's good to know that you are aware of the pitfalls.

Still, I'd recommend that you use a VCS (git or mercurial) under the hood for this. They are optimized to store and retrieve previous versions (that is their primary job after all), they give you tools to compare versions, and they give you context for each version you commit (or your module commits).

Yes, you could say that you don't really need all that, you just need something that hides and automatizes that mv results.txt results.txt-5 step, but little projects like this tend to accrete features and use cases, and before you know, you're stuck with an underdesigned, metastatised monster of a system.