Version control in Linux

I've been asked to look at version control in Linux. Over the years we've developed a lot of software under windows and have used the version tab in the properties window to great effect. This is very usefull as it means we can check the version of a piece of software without running it. My question is there an equivalent in linux? I've checked KDE but there doesn't appear to be anything, can it be added or enabled?

Under linux, everything is run from the command line interface - even GUI apps, so although KDE apps are launched graphically by the user, KDE is really running exec'ing the app as if it were being running from an xterm.

Most linux apps have a version switch so that when the switch is supplied on the command line, the app reports version and exits. This switch is often -v or --version, although applications are not always consistent. KDE ( and/or Gnome ) may well have this switch defined in a style guide, so that truely compatible apps have a defined switch.

Try kmix -v, and then kmix in an xterm...
You will notice that kmix reports the versions of it's 2 major dependancies ( KDE and Trolltech's Qt library ), which is better than the Windows equivalent (Right Click..properties) that won't report .DLL versions.

I'm not really sure how Windows gets the version of an app that is reported in that way... maybe it's in the registry (possibility for corruption leading to false versions reported), or more likely, a similar method is used, and windows calls the app through a well-defined interface.

I'm not really sure how Windows gets the version of an app that is reported in that way... maybe it's in the registry (possibility for corruption leading to false versions reported), or more likely, a similar method is used, and windows calls the app through a well-defined interface.

Windows grobbles around in the headers of the binary -- the Win32 binary format contains the version fields, so, although the program isn't "run", it is directly consulted.

The ELF format used in Linux may well have similar fields, but they aren't used for executables; running with "--version" is the de facto standard. Library versioning, of course, is done in the filename, i.e. libfoo.so will be a symlink to libfoo.so.2 (major version) which is a symlink to libfoo.so.2.1.5 (full version). These symlinks are maintained by the ldconfig program, which examines the shared-library format headers to discover the "true" version.

Peter

Windows grobbles around in the headers of the binary

Footers, technically. The VERSIONINFO block is stashed with the other resources (menus, dialogs, etc.) towards the end of the file (though it doesn't have to be).

The Win32 executable format also has space in the COFF header for a file version, but very few applications bother to fill this in.

Library versioning is all very unfortunate, and leads to things like libc-2.1.2.so, a practice I abhor.

If you're using RCS, or presumably anything which uses RCS as a backend (CVS, Perforce...), then ident can come in handy to see what source code went into a particular binary.

Richard.

But what would the alternative be?

( I assume by extension that you also abhor libfoo.so.x.y.z and are not just griping about the arse-about-face labelling of libfoo.x.y.z.so )

At least in linux, for the whole part, backward compatibility is often kept, and it is possible to keep multiple versions of libraries around anyway. I've had a lot less dynamic library version issues under linux than under any 'doze box I've ever had.

running with "--version" is the de facto standard

...or "-V" or "-v" or something more obscure...

P.S. I know someone is going to ask for an example of "more obscure", if so try dig, it has no -v, -V or --version. You just have to run it and grok the normal output.

( I assume by extension that you also abhor libfoo.so.x.y.z and are not just griping about the arse-about-face labelling of libfoo.x.y.z.so )

You assume wrong

libc.so.whatever is fine
libc-whatever.so is a crock.

I had backward compatibility on SunOS 4 without this crock in like 1993.

Ahh, the Library versioning is all very unfortunate got me.

I too abhor the libfoo-x.y.z.so bastardisation.

Of course I still have it, because my SunOS 4 box is substantially unmodified... since not long after 1993