Simulating file version numbers on HP-UX

[Ken Englander]

I am looking for an opinion about using software on HP-UX to assign and maintain file version numbers.

On OpenVMS all files have a version number that is a part of their "name". A typical edit session on a file would automatically create a new file with the version number incremented. However, many programs, such as Oracle will open, update, and close the same version file without chaning the number.

I am strictly soliciting opinions here. If you are familiar with a product, I would be interesting in knowing about it. We have clients who are migrating from OpenVMS to HP-UX that are interested in this possibility.

I'm thinking that a tool that imposes this on the VxFS filesystem would offer a lot of potential for problems since the programs we expect to be running do NOT handle versions.

Any input is appreciated!

Ken

[Steven E. Protter]

Shalom Ken,

I know of no way other than pointing weapons at the developers to enforce such policies on HP-UX.

Perhaps trying an open source version management tool like CVS is an answer.

SEP

[Laurent Menase · Accepted solution]

you can use rcs,
but you need to checkout a file before modifying it,
then check in.

so ci to checkin
co to checkout.
else there is no automatic way to version files.
It is of application responsibility to maintain one if needed

[Steven Schweda]

Others have in the past suggested ClearCase,
which does have a versioning file system, but
it, too, demands check-out/in operations.

You should try asking in the VMS forum, too.
You probably won't get any better answers
there, but you will provide some considerable
entertainment to the its readers.

[OldSchool]

I know of nothing that will do this automatically at the OS or filesystem level in HPUX.

SCCS (similar to RCS) can be added to the list of items mentioned above. As with all of the above, items still have to be checked in and out.

Also, Visible has a product called Razor that manages issue tracking / source / versions, which seems more along the lines of ClearCase. There is also a product named Perforce that seems to be in the same vein.

You might also find some things of interest in the usenet group comp.software.config-mgmt, which can also be found in google-groups here:

http://groups.google.com/group/comp.software.config-mgmt/topics?lnk

depending upon what you want to do with it, there are a variety of tools that *might* fit your needs, but won't replicate the automatic versioning exactly.

The little I recall of the system you speak of (from a very long time ago), editing a file test.dat and saving it creates something like test.dat;1. Repeating that process creates test.dat;2 and so on. The actual number of versions retained is configurable, and you can always directly retrieve any prior saved version. Using the examples above, editting test.dat;1 and saving the result creates test.dat;3.

If your clients rely on that ability heavily, then the probably aren't going to like any of the proposed solutions, as they all revolve around working copies. You can retrieve a prior "checked in" version, but the versions won't increment automatically, although potentially, something could be scripted to achieve that end.

You might try googling "software configuration management systems" if your your interest lies primarily in software development areas, or "configuration management systems" which are aimed a little broader. the wiki entries should have more descriptive information.

[OldSchool]

hmm... I left out "Subversion". The wiki entries for "versioning file systems" has some interesting diagrams as well

[Olivier Masse]

Using RCS/CVS/SVN is fit mostly for source code. I wouldn't want to have to use these tools to check in, say, /etc/hosts, but it is possible. RCS is built-in to the OS.

You can probably alias the most standard fle management commands (cp, mv, vi) to functions that will invoke RCS, or simply make symlinks to implement a versioning feature. But symlinks are not good performance-wise, and there will always be a case where someone will save a file directly from vi, and not keep the old version.

As someone who managed a transition three years ago and had to train a team of 6 diehard VMS admins, I suggest you train yours to get into the habit of always making a backup copy of any file before working on it. They'll gripe (with reason) as it is indeed a stepback, but there's no easy solution around this.

While they'll probably miss some things about their older OS, emphasize on the other aspects of HP-UX which provide an advantage over VMS to at least try to level them off. Oh yes, and use bash as the default shell for normal user accounts (you can spawn it from root's profile too, with some caveats) and they'll be able to use arrows for command history. Nobody likes change, but decreasing the irritants such as enabling callback with the arrows has been a life saver in my case.

Good luck

[Duncan Edmonstone]

Ken,

Some good point have already been made which I won't repeat - I'll merely say this:

- In my experience trying to crow-bar new IT systems into behaving "just like the old one" is a recipe for a massive fail. The systems are simply different and IT support folks need to be flexible enough to deal with the differences. Doing this sort of thing will likely mean not adopting the features in the new system that *do* deliver value back to the IT function.

I once knew a customer who came off UNIX onto Windows - because the admin knew UNIX so well, he put Cygwin onto the windows boxes and use shell scripts to do a bunch of stuff that a windows admin would have done in a different way (using group policies and active directory seettings etc.) This was all fine until he left the org and they replaced him with another admin who had only ever worked on windows. The chaos that ensued whilst the admin tried to get the environment into a state that was supportable by a generic windows guy was scary to behold... hopefully you get the point.

So accept and embrace the differences...

For more specific advice, maybe you can describe the function that the file version number feature is filling specifically fo you that you think means you can't do without it. Maybe there is another approach to solving the problem...

HTH

Duncan

[dirk dierickx]

some filesystems support snapshots, you can use these as some kind of versioning. although beware that you 'version' a whole filesystem and all the files in it at that one moment.

there are a lot of versioning tools out there, a lot have been mentioned already: rcs, cvs, svn, arch, svk, etc - but these need to called explicitly by the user before changing the file. you can't really enforce this automaticly i'm afraid, but you can have procedures in place (oh, everybody loves procedures) that require users to do so or else...!!

[PeterWolfe]

Suggestion: Train them to use Emacs.
Emacs has an EDT emulation mode and or a TPU emulation mode
and is programmable like TPU so the average VMS
user is more comfortable right from the getgo.

Emacs can support file version numbers. You have
to enable it but the general idea is that
you end up with something like:

file
file.1
file.2
file.3

where the latest version of the file has no version
number (which is what you want on UNIX),
and .1, .2, .3 are the previous versions where
.3 is the most recent....

This only works in emacs. As previous posters
have stated, there just no auto file version numbering
on UNIX. Sure you can use RCS/CVS/SVN methodologies, etc
but those are all really heavyweight
if this simple emacs based solution can suffice.

Re: bash suggestion. You can also get sh/ksh to
handle the arrows appropriately but it's not
configured that way out of the box. Search this
forum for the appropriate lines to enter
into a user's profile or the system wide profile
(e.g you set -o emacs and then define
some aliases for the arrow keys)

[dirk dierickx]

waw, that is funny, complaining about the 'weight' of rcs/cvs/svn and recommending emacs instead. otherwise known as the lightest 'editor' in the galaxy. :D

[Duncan Edmonstone]

gaaah Dirk, please don't spark a vi vs. emacs holy war - some of us were around the first time and aren't sure our hearts can take another! ;o)

Duncan

[Ken Englander]

Thank you all for your input!

Steven - I did enjoy your suggestion about checking in the VMS forum but that might just aggravate the situation. I might find some of our clients out there who are already distressed by the need to move from VMS. I worked with VMS for many years and I am a big fan, but that is not where my company is going.

Duncan/Dirk - I understand these topics come up but I don't think this is the place for that type of discussion.

[Ken Englander]

I thought I forgot to assign points and had to re-open to do that. Closing again.