Visual Source Safe like revision managers for linux

Look into CVS's $Log, $Id, $Rev and other substitutions. Subversion can also be configured to do the same. It's not often thought these days to be a good idea though, as many people prefer that what one gets back after a checkout should be the same as was checked in. The metadata about the change can live in the changelog.

Nick

I am afraid there is no "Visual Source Safe like revision manager" for Linux. No one has managed to replicate the unreliability, database corruption, and general data-destroying capabilities for which VSS is so famous.

There are plenty of /real/ revision control systems (or source code management systems, if you like) for Linux. There is the old CVS system that a few people still use, though most have moved on to something better. The most popular choice for a system based on a single central server is Subversion - it is very popular for corporate use, for mixed Windows/Linux/Mac use, and for smaller projects. For distributed version control systems, the two most popular are probably git (which is great for huge projects, but doesn't do so well in Windows) and mercurial (which is a little lighter, and has good cross-platform support).

Unless you have a good reason for picking something else, I'd go for Subversion.

Regarding these sorts of log messages, the general modern opinion is that they are a bad idea. A version control system should keep your files safe, let you look at old and new versions, and see who did what at different times. It should /not/ mess with your files and change their contents. Once you have a /real/ version control system instead of the dog's breakfast you currently put up with, you can learn to use commands like "svn log" or the Tortoise SVN explorer extension (or RabbitVCS on Linux) to view your logs, rather than having them mess up your source files.

Of course, subversion does support this sort of thing for messing up your source files with revision ID and similar information. But it is disabled by default, because you should not use it.

-- Les Cargill

A hit, a very palpable hit!

Or still use The One True rcs.

... unless you ask it to do so. A $Log$ tag that gives one a space to append a change summary has to be a time-saver, but to each his own.

As you say, each to his own. But simply telling the OP about the best way to get a version control system to add log data to his files would be doing him a great disservice - there are good reasons why that sort of thing went out of fashion long ago. (You might notice a touch of bias in my writing...)

Here are some arguments against keyword substitution:

Mercurial, which is a more modern version control system (but perhaps a bit /too/ flexible for the OP's needs), specifically does not include any sort of keyword expansion in the base system. Of course, someone has written an extension for die-hards who insist on it.

The Mercurial wiki seems to be having trouble just now, but here's the link anyway:

(Other systems, such as git and bzr, also have no support for keyword expansion.)

So leave your old RCS bad habits back in the eighties, learn to use "svn log" when you want log information, and let the version control system track /your/ files, not ones that it modifies on the fly.

Alternatively, if you want such data in the file then just adopt the discipline of including such detail as part of your update comments so that it is all checked in together. My preference is for a little more detail about the changes that were made with references out to supporting change management documentation (Fault Reports, Change Notes, ECN's, Review Comments etc.).