Enabling Keyword Expansion

Not having keyword expansion in a version control system is kind of like selling a car without tires: it's a pretty critical feature, especially for teams not willing to trust that the particular instance of Team Foundation Server being used to store a project's change history will be universally and eternally available.

Allenvm3 at 2007-9-8 >

For unix development, it is not uncommon to embed a version string as a constant into a source file. Then you can use strings | grep "$Version" to find the version strings. This allows you to find out what versions of the source files were used on an application or shared library (i.e. dll).

While it's true you could have some manual process to extract the data and place it back in the file, this data would always be off by one version. Not to mention the fact that if you forget to perform this process it would have out of date information, which is probably worse than no information at all.

The example in the previous post for extracting history and embedding it as part of a migration process is pretty bad, in my opinion. That's like saying an SQL server doesn't really need to support joins. For example, in order to perform a join, I could select data from one table, iterate over it and select data from another table to fill a temporary table with my output. It would work, but it's highly inefficient and prone to errors.

I'm not trying to be argumentative, I'm just hoping Microsoft will put this feature back into a future version.

DwayneA.Davis at 2007-9-8 >

I was speaking to the history keyword because that's what the other poster expressed interest in - and specifically in the context of moving to a different source control system. Remember, as long as your data is in TFS, full history, version information, etc., is part of the meta-data available through the history and changeset commands.

A version keyword would need different handling, and if that handling wasn't automatic, it would lose much of the value since no-one would remember to keep updating the version field by hand.

I didn't mean to imply that such a process for migrating history was "sufficient" - it was just a possible workaround. I'm sure there are better approaches. In fact, I believe TFS has extensibility points such that a "real" solution could be developed (e.g. using custom check-in policies). I'm not trying to say that TFS "doesn't really need to support keyword expansion" - I'm trying to offer some alternatives for those who need some of that functionality.

I still think that keyword expansion is just a tad less critical to source control than joins are to SQL - I think a lot more teams would consider atomic changesets or multiple checkout support to be 'critical'. But of course, every team's needs are different.

CRathjen-MSFT at 2007-9-8 >

I agree - "workaround" always carries a "POOR substitute" connotation for me.

You can be sure we'll be pointing to threads like this one, when we're considering which features should be added and/or which missing features should be filled in, for future releases.

Thanks for the feedback!

Chris

CRathjen-MSFT at 2007-9-8 >