The Design of Software

Greetings all.

We are using ClearCase at my new place of employment and it seems everyone uses the "dynamic view" in order to access the VOBs.  I created a script that I wanted to have display its own version number when it ran but the CC admin says that using keyword expansion (e.g., $Version: $ in SourceSafe) is "old fashioned".

Am I now an old timer at 8 years out of undergrad?

Thanks-
-dennis.

No, your CC has no perspective.

Just ask what the 'cutting edge' alternative is.

Apparently "cutting edge" is to open up the ClearCase tool and pull up the version information on the file itself. 

I guess this process assumes you do not want to ever publish the information to anyone. 

Baffling.

-dennis.

I've seen files with keyword expansion turned on that have literally hundreds of lines of crap at the top, that nobody ever needs or uses.

Keyword expansion also becomes a problem when you're integrating between different repositories; suddenly the person who checked in a copy of the vendor's file is listed as the owner of the file. And now there's an extra difference to deal with on the next vendor drop.

Oh, and they slow down checkouts, too.

> Baffling.

Why do you need all that crap in the file when it is available in the tool?

Why not just store the edit history and the checkin comments in the file too.

The file should just be the source file. Keep meta data meta.

I actually just wanted the version number and a date-time stamp.  I agree that the check-in comments and other typical keywords, while they can be handy for a quick reference, just add to the noise of the file.  However, the version number and a date-time stamp can be extremely handy.

> However, the version number and a date-time stamp can be extremely handy.

How? Anything you need to know you can get from the version history. And you'll need the checkin comments to make sense of anything anyway. The ever changing version number and date-stamp screw up diffs as well.

I agree that the version number can be very handy to have.

We have dozens of scripts here that are updated on an ad-hoc basis (e.g. no formal development/release schedule).  When an internal user needs a new feature we simply add it and it is good to go.

The easiest way to keep track of which machines have the latest versions on them is to let the SCM tool (Perforce in our case) expand the version number keyword.  All our scripts have an option to report the version number to the user (and the version of all modules used by the script).

If someone has a better idea for how to do this, or to automatically synchronize all our systems (some on their own private networks) I'd be more than open to hearing them.

Anyway, I agree with the OP that keyword expansion is extremely useful.

> If someone has a better idea for how to do thi

The change number in perforce is more useful than version numbers as it specifies the complete depot a point in time.

But who cares about the version number of a file in a scm? What you care about is the version number of a product because that maps to a feature set.

So I would use product version / change number. The product version is the contract. The change number is the exact source code making up that contract.

> > However, the version number and a date-time stamp can be extremely handy.

> How? Anything you need to know you can get from the version history.

Automatic version numbering.

If you are tied to the idea that you have to have a 1.0, 1.1, 1.2, 2.0, 2.1... kind of version numbering, you can use the revision control tool to generate the version number.

It's a freebie update.

Sorry, that should have read "If you are _not_ tied...".

I'm thinking more in terms of scripts here as other posters have said, too.

-dennis.

> Automatic version numbering.

So if I correct a typo the file gets a new version number and making people care about that is a good thing?

> So if I correct a typo the file gets a new version number and making people care about that is a good thing?

Depends what the typo was.

I'm not saying it's always required, I'm just saying that it can be handy and I don't think it's an "old fashioned" idea like my OP asks.

No its not out of date to use $Keyword: expansion.
I use it for all source files, .vb, .SQL, .CSS, .xml etc - everything except .aspx/html/.ascx - stuff which the customer can view easily
I don't use the $History: feature - too much gunk added to the file - Where it really comes in useful is finding out if you have the right version of a stored procedure or CSS etc on a customer's machine, a situation where you don't have access to Source Control to do the comparison - It really helps with support.  Also if $Revision is at the top of the code, I know I last worked on version 20, today its at version 24 - so I know someone has made changes since I last used the file.  Its quicker than these source control tools where you have to switch to another application, find the file in that app then.. menu.. point.. submenu.. click.. select.. etc - too much bother its just there with keyword expansion.