Keyword expansion in TFS


Periodically, the topic of keyword expansion comes up, which TFS (at least through 2008) does not support.  At one point during the v1 product cycle, it was a planned feature and was partially implemented.  However, there are lots of challenges to getting it right in TFS version control, and it wasn’t worth the cost to finish the feature.  As a result, we ripped it out, and TFS does not support keyword expansion.

Since it’s not supported in the product and not likely to be supported any time soon, folks gravitate toward the idea of using checkin policies to implement keyword expansion.  The idea is appealing since the checkin policy will be called prior to checkin, of course, which would seem to provide the perfect opportunity to do keyword expansion.

Personally, I’m not fond of trying to do keyword expansion as a checkin policy.  There are a number of issues related to checkin policies to deal with immediately, because any checkin policy that performs keyword expansion is going to modify file contents.

  • Checkin policies get called repeatedly.  Every time the user clicks on the checkin policy channel in the pending changes tool window in Visual Studio, for instance, the checkin policies are evaluated.
  • Whatever a policy does must be done really quickly.  Otherwise, you are going to make the VS painful to use.  The checkin policy evaluation isn’t done on a background thread, and it wouldn’t really help anyway since you wouldn’t want to have to wait for some long policy evaluation before the checkin process started.
  • Checkin policies can be evaluated at any time.  The user may or may not actually be checking in at the point that the checkin policies are evaluated.  You even have the option of evaluating checkin policies prior to shelving.
  • For applications using the version control API, checkin policies are only evaluated if the application chooses to evaluate them (see How to validate check-in policies, evaluate check-in notes, and check for conflicts).  Some folks may read this and this it’s a hole in checkin policy enforcement.  However, since checkin policy evaluation is done on the client, you can’t rely on it being done (i.e., clients can lie and call the web service directly anyway).  The other reason has to do with performance.  For an application like Visual Studio, it controls when checkin policies are evaluated, and by the time that it calls the version control API to checkin, there’s no need to evaluate them yet again.  Some day there may be server-side checkins, but they don’t exist yet (as of TFS 2008).
  • You’ve got to get your checkin policy onto all of the client computers that are used to check in.  The deployment story for checkin policies is probably the single biggest hole in the checkin policy feature in the product (the second biggest hole is the lack of built-in support for scoping the policy to something less than an entire team project, though there is a power tool checkin wrapper policy to do that now).  Any computer without the checkin policy assembly on it and properly listed in the registry is not going to do keyword expansion.

If you read that and still want to do it, you would need to pend an edit on each file that does not already have the edit bit set (for example, non-edit branch, merge, rename, and undelete) and is not a delete (can’t edit a pending delete).  I’m pretty sure that VS and the command line will have problems with changes being pended during a checkin policy evaluation, because they’ve already queried for the pending changes and won’t re-query after the pending checkin policy evaluation.  This would result in edits not being uploaded.  This pretty much makes pending edits on files via the checkin policy impractical.

Alternatively, you could do keyword expansion only for changes where the edit bit is already set in the pending change.  That’s sort of the “least evil solution.”  You would just use the checkin policy for keyword expansion in files that already have pending edits (i.e., check to see that the Edit bit is set in the pending change’s ChangeType).

Some of the files with pending edits may not have actually been changed (e.g., you pended edits on all of the files in a directory as a convenience because you knew you would be editing at least half of them via a script).  When the server detects that a file that’s being checked in with only a pending edit hasn’t been modified, it doesn’t commit a change for that file (i.e., create a new version of that file).  You can read a bit about that in the post, VC API: CheckIn() may return 0.  To detect for yourself whether this is the case, you can compute the MD5 hash of the file content and compare that to the HashValue property of the PendingChange class.  If the two are equal, then the file didn’t change.  For those of you doing government work, you’ll want to watch out for FIPS enforcement.  When that’s turned on in Windows, MD5 hashes are unavailable because the MD5CryptoServiceProvider class in .NET throws when you try to create one.  In that environment, the hash values are empty arrays.

But wait, there’s more!  You would also have to make sure that you read and write the file in the correct encoding (e.g., reading in DBCS as ASCII or Unicode would be bad – for example, Japanese or Chinese DBCS files).  There are probably more encoding issues to contend with.  One thing that’s probably on your side, though, is that if you do read in the file in the wrong encoding, you won’t likely find the markers indicating that the file needs keyword expansion.  To avoid randomly finding the tags when you know you don’t want to, you’d likely want to skip all binary files that your expansion logic doesn’t know how to handle (e.g., you could conceivably handle keyword expansion in JPEG file headers, but that doesn’t seem too likely).

The other thing to consider is how keyword expansion interacts with branching and merging.  Imagine putting the date in every file in a keyword expansion system.  It’s going to be a merge conflict every time your merge branches.  The same is true for log (history) information.  You would need to write a tool to handle the content conflicts; otherwise, merging large branches would be a real bear.

Even with all of that, you are not going to get one of the things that often comes up (and this was true when we were thinking of putting in the product, because it was all going to be done on the client prior to checking in) which is the ability to record the changeset number in the keyword expansion comment.

So, to sum it all up, you are going to need to consider the following.

  1. Your checkin policy will get evaluated multiple times and often not when someone is actually checking in.
  2. You’ll want to only modify the files that already have pending edits, as pending new changes from within a checkin policy may lead to new content changes being uploaded with the rest of the checkin.
  3. You’ll want to test out how it’s going to interact when merging files from one branch to another.  What’s it like to deal with the conflicts your keyword expansion introduces?
  4. There will be checkins where keyword doesn’t happen for whatever reason, so it’s not completely reliable.  This is in addition to the fact that changes that do not already involve an edit won’t have keyword expansion at all.

If we had done keyword expansion as a feature, what would have been different (other than the fact that you wouldn’t have to think about all of this :-) )?  We wouldn’t have the limitation of 1.  Just like in 2, we’d have to think hard about whether every rename, branch, undelete, and merge should have an edit pended also.  At best it would have been an option, and it wouldn’t have been the default.  Regarding the branch merging issue, doing something on the server would be a performance hit that may be excessive with large branches (keep in mind that the server stores the content as compressed and doesn’t uncompress it — the client takes care of compressing and decompressing content), so the client would need to have some logic to help make it bearable (e.g., before performing a three-way merge, collapse all of the expanded keywords).

Our conclusion was that the feature was too expensive to implement and test relative to the value provided and other features could be implemented and tested with a similar effort (e.g., making history better).  Folks either strongly agree (can’t live without it) or disagree (don’t care about it at all) with that conclusion.  There’s rarely anyone on the fence.  The feedback we’ve received to this point indicates that we’ve made the right tradeoff for the vast majority of our customers (and potential customers).

Comments (65)

  1. JohnS says:

    that illustrates one of the problems in the reliance upon code-as-text, doesn’t it? because you can imagine that keywords would just be a mix of mandatory (username, date, etc.) and arbitrary (label, free text, sprint number) attached to a changeset, which the client could just substitute when viewing the code. but at the same time, having some alternative visualization of arbitrary meta-data attached to the code (for instance, as additional columns in the repository view, like Vista’s explorer windows) would help to eliminate the need for keyword expansion… :)

  2. buckh says:

    I agree that there are lots of possibilities for associating and displaying metadata related to files, changesets, and more.

    However, the folks that want keyword expansion invariably want it because they want to have that information in the files themselves.  That way no matter what editor or environement is being used, the information is available.

    Buck

  3. TimAgain says:

    If you are a making case for shipping product to meet deadlines I understand. Though it sounds like you have gone to the next step and decided to remove keyword expansion from source code control architecture.

    I like to use keyword expnsion ( mainly $Revision$) for programs that are not compiled (T-SQL, vbs, cmd files, etc..) The history comments we can type in ourselves and do not need keyword expansion. The $Revision$ information ensures some level of confidence when debugging problems.

    I do not agree with the vendor trend of using diff tools to act as my source code control. I think it compliments the process.  

  4. buckh says:

    Tim, I did blur the two reasons a bit.  With v1, it was cut for time.  For v2 and beyond, we haven’t come to the conclusion that we can have the features that folks using keyword expansion want and weighed against the time to implement and test the feature.  In your case, you want a subset of the traditional keyword expansion features.

    Partly I wanted to see the reaction that folks would have to guage interest in the feature, and I appreciate your comments.

    Buck

  5. Matt Janofsky says:

    Keyword Expansion is one of those features that doesn’t seem valuable on paper.  However, it serves as one more check and balance point.  When you see the version number in the file, it may be obvious that you’re working on the wrong source file.

    Also, as part of our standard header, we assign the source file name and version number to a private constant.  I can then search for the file name in the DLL or EXE and know exactly which version of the source file that item was built with.  That can save a lot of debug time later.  Often times, I can see exactly why a bug was not fixed or has reappeared.  Search the DLL and sure enough, it was built with an old version of the source file!

  6. ArchVile says:

    I used keyword expansion (mainly $history) in several projects and made it a standard part of our dev process. It’s very convenient to look at source code and determine what changes have been made regardless of environment or available tools. If these comments are just in source control, it’s one more (inconvenient) step.

    I recently migrated from VSS to TFS Source Control and could not believe that it did not support this function. Now something that has been part of our standard process for years has to be modifed for a yet unknown alternative.

  7. thensley@firstsolar.com says:

    I also find keyword expansion important for non-compiled text files (sql scripts, config files, etc.)  

    When you are looking at copies of these files that have been deployed, printed, emailed, or burned on a CD you can tell which revision in source control it was.

    I don’t understand why it’s necessary for the source control system to store the values of the keywords to be expanded.  Strip out the existing value of the keyword when checking in and insert the current value when checking out.  Wouldn’t that solve the merging problems?  The keyword would always be something like "$MyKeyword:$" stored in the source system and "$MyKeyword: 1234$" when expanded.

  8. Alastair Green says:

    I agree with that last point by thensley.

    I am developing some javascript files that will e used by a 3rd party and I need to send periodic updates to a bunch of people that don’t have access to TFS.  It would be nice to automatically include a revision number so that people can check they have the correct version in the correct environment.

  9. Jeff Clark says:

    Used to compare deployed versions of stored procedures on the DB server. Also used for logging information by setting up a private constant in the source file and inserted into the error handling.

  10. Keyword on $Revision$ is incredibly handy.  SharePoint development can require a lot of non-compiled files to effectively customize a system.  The ability to quick reference a version number on a deployed file is extremely handy.

  11. Jeff Chadwell says:

    This just boggles my mind.  How can you not have the ability to embed a version string into a binary file?  I personally know of several instances where that information saved us countless hours of tracking down a bug that had already been fixed, simply because we could instantly determine that our customer had the wrong version of our code.

  12. Martin says:

    I think this is really an unfortunate omission. I would not consider moving over unless the keyword expansion exists, for the reasons others have already provided:

    1. When code is compiled into a database, it is nice to see which version it is, and automatic keyword expansion streamlines this process greatly.
    2. Injection of version info into error messages in the code – again this streamlines this too.

    The keyword expansion is, in our case, never used to determine the version of a file that is under source control, it is used for determining versions of files that have left source control and been distributed.

    So…we will continue to host our repository within a system that can handle this quite simple feature.

  13. Martin says:

    Quick point, and maybe I’m being blinkered, but why does it have to be expanded on checkin?

    Surely expansion on checkout is pretty easy…

  14. Martin says:

    …and reduce the keyword on checkin to prevent conflicts?

    (sorry for the multiple messages)

  15. padamson says:

    Keyword expansion is very important for development.  I have never used source control for a SW product without it, wouldn’t consider a version control product real if its missing, and is a required feature for us.  

    So while TFS has many things that make it superior to VSS (which BTW stinks for large products), it will not be used by any of the product teams I work with until it matures and gets this feature.

    While I feel Buck’s pain at implementing it, its just too important a source of information for broad based teams and external partners who get source files but won’t have access to TFS.  

  16. rvolk says:

    Can’t agree more that this is a crucial feature and seriously lessens the usefulness of TFS.  And frankly, with all of the logic involved with merging, branching, and check-in policies, to say that adding keywords is too hard sounds like BS.  Sorry guys, if VSS could do it…

    It’s also a little too integrated with Visual Studio, to the point where it’s almost useless without it.  It’s also very poorly integrated with SQL Management Studio.  It doesn’t seem to work unless I have a project, which I really don’t need in order to edit a single stored procedure or view.  VSDB edition isn’t much better.

    I don’t know if this is true but I’ve heard that MS doesn’t use TFS for their own source control.  Even if this is a rumour, what does that say about it?

  17. buckh says:

    Keyword expansion remains on our feature backlog, but I don’t know when it will make it into the product.  It is not in 2010.

    We’ve been using TFS internally for years, and the entire Developer Division has been using it since early last year.  Brian periodically posts an update on it: http://blogs.msdn.com/bharry/archive/2009/01/16/microsoft-tfs-adoption-update.aspx.  You can see the full breakdown of where it is used.  It is true that Windows and Office do not yet use it for version control, but DevDiv, MSIT, and other parts of the company do.

    Buck

  18. Loadmaster says:

    At the very least, $Revision$ should be supported. It’s practically universal.

    I’m saying this after 20+ years of using many source code tracking systems (SCCS, RCS, CVS, PVCS, ClearCase, PerForce, Subversion, VSS, etc.), and more to the point, having to convert source files from one system to another.

    I’ve heard the counter-arguments for not using keywords and why they are bad and all. All of these arguments are quite simply wrong.

  19. rskedel says:

    This feature is very important to trouble shooting field installations that go bad.  I can not believe this feature does not work in TFS.  At the very least I would like to see

    $Workfile$

    $Modtime$

    $Author$

    $Revision$, how hard could that be.  Every other revision control software has it.

  20. John Hardin says:

    +1.

    If it’s too difficult to support complex user-defined keyword substitution, fine, omit that. But don’t use that as an excuse to avoid implementing the basic predefined keywords that experienced developers expect to have available, like $Id$, $Revision$, $Author$, $Modtime$ and so forth.

  21. adam davis says:

    I think it should be included.  If it isn’t, supply a good alternative that works with text files cross platform, regardless of editor.

  22. D Bullen says:

    I am coming in new to TFS – or was.  Staggered it doesn’t support keyword expansion, won’t be using it now.

  23. David A. P. says:

    ARGH! Started a new job, was excited to finally have a chance to try out TFS "for real." Excitement turned to disbelief mixed with bitter disappointment at finding out that keyword expansion is nonexistent. Srsly?

  24. Hi!

    I implemented an Check-In Plicy which does keyword explansion…

    http://blog.kalmbach-software.de/2009/07/24/tfs-automatically-insert-check-in-comments-into-source-code/

    It currently only supports $log$, $date$, $author$, $typ$.

    $revision$ is hard to implement, because the number is only available after the check-in is done ;( you can only use "previousrevision" ;=

    But the main problem in bigger teams is the very bad concept of check-in policies… there is no global storage of the settings; also you do have to deploy it on every dev-PC…

    Are there any news in TFS2010 regarding Check-In Polcies?

  25. buckh says:

    Jochen, nice work!  I wish I had better news for you on deploying checkin policies in 2010, but unfortunately it is still not automatic (it’ll get strong consideration for the next release after 2010, I believe).  There is a little-known feature in the 2008 power tools that will do it, but you then have to make sure all of the clients have the power tools installed.  If that’s universal, it may be an option for you.

    Buck

  26. Don McLeish says:

    Buck, I agree with the previous posters. We just moved to TFS and I also am shocked to find it doesn’t do $revision$ expansion. I’m the main database developer and most of the code I write is in scripts (text files). I embed the revision into all the stored objects (packages, procedures, triggers, views, etc) so we know exactly which version a client has installed in their database. PLEASE push for this feature in future releases. I’d drop TFS in a second and go back to VSS if it were up to me.

    Also, do you have a link to the 2008 power tools that you mentioned?

  27. buckh says:

    Don, I’ve been reading all of the comments, and I’ve also forwarded them to the version control PM.  It’s definitely on the backlog for consideration in the next release.  It seems to be a very binary issue where folks either must have it or don’t use the feature at all.

    Here’s a link to the power tools: http://msdn.microsoft.com/en-us/teamsystem/bb980963.aspx.

    Buck

  28. Today I published my first release of the "$log$ substitution check-in policy" on codeplex:

    http://logsubstpol.codeplex.com/

    Please feel free to use it and comment it!

  29. Emilio says:

    Personally I can’t understand why MS decided to drop this basic feature that is available on virtually every self-respecting version control system. But well, VSS had problems with extended characters in the source code that I think never got fixed…

    Then I must say (personal opinion) I liked RCS/CVS keyword expansion bettern than that of VSS because it looked less cluttering or less an eye sore than how it looked in VSS.

  30. kendall morley says:

    It seems that most people who support the lack of keyword expansion in tfs seem to assume 2 things.  1. You will always be working inside the IDE and 2. You will always be doing development.  

    Everything you say about view history ans such in TFS holds true for 1 and 2 above.  However that lack of keyword expansion becomes a huge problem in the followin senarios.  

    A). you are called out to a client site to debug a database trigger.  You do not have an IDE or TFS all you have is the code of the trigger.  having a version number and a file location in TFS would be a huge help.  

    B). A collegue emails you a single source file or an App.Config file and asks you to merge their changes into tfs.

    Again having a version number and a location in TFS that the file came from would be a huge help.

    With the 2 pieces of info I mentioned you can instantly tell if a file came from the release branch and if it is the correct version.  If you suspect someone has manipulated the file you can email it to a collegue who has tfs and the ide and get them to compare the file on site with the exact version in TFS, not just the absolute latest version.

    Another thing.  Why would anyone in their right mind implement keyword expansion on checkin.  Do it on checkout and get.  While a file is in TFS you do not need keywords and you dont want them showing up in diffs.  It is only when a file is extract from source control that the information becomes useful.  

    Buck stop confusing the argument about whether keyword expansion is usefull with the argument about wheter fitting it in to the TFS architecture is easy or hard.  As an end user I dont care how hard your developers have to work.  Keyword expansion solves a problem as is usefull.  Solve the problem another way and keyword expansion is not so usefull.  The problem is this.  You have a file outside of the source control system, client site, email inbox, zipped on a usb stick,  how do you tell where the file came from what version it is, without comparing every known version of the file in every source control system you have used for the last 20 years.

    Or to make matters worse, old version of the file are in subversion

    2 good keywords are $version  and $location or $path.  

  31. buckh says:

    Kendall, regarding difficulty, it’s really about the investment of time.  Implementing this means choosing not to implement something else.  The feedback on this feature seems to be very much binary, with folks either very much wanting it or not caring at all for it.  Just this past week I asked the MVPs about whether they wanted this particular feature, and the answer was a resounding no.  I also see the passion for it in the comments on this post.

    Buck

  32. Edvard says:

    The support for Keyword expansion is a must in our development environment. If not added, we have to live with VSS for the future. In any file we tag the latest version and distribute with the compiled file. $Header: /Dev2009/InFront/Web/ProfitBase.InFront.Analytics.WebClient/Default.aspx.cs 6     30.04.09 12:24 Ja $

    In our environment with continuously development this is a must. The reason this is not used by every development-team, might be the poor documentation of this issue in VSS. There are neither examples nor description of possible usage.  

    Please rethink this issue.

  33. Ron says:

    This is a perfect example of why I never voluntarily use closed-source software. There are probably thousands of developers that would be happy to spend time adding this feature if they just had access to the source code.

    I suggested using keyword expansion as a simple solution to a problem today and was shocked when I was told that it wasn’t an option because TFS doesn’t support it.

    I found it so hard to believe that I did a web search and ended up here.

  34. Brian Miller says:

    I would have thought that keyword expansion would be easy, i.e., not taking a lot of time at all.  The internal document always contains the $BlahBlah: $ keyword, and then that would be replaced with an appropriate value on doing "tf.exe get sourcefile".  All of that information is available through "tf.exe history", so it's not as if the information is not available.

  35. Ilias says:

    +1

    looking for $Revision$ keyword expansion to help easier versioning in automatic build processes.

  36. Ken Crismon says:

    Yet again I discover another reason to use SVN over TFS.  Microsoft makes you pay a ton for a tool that is slow, hard to use, over inflated with its own value and really does not provide anything better than SVN.

    I continue to cringe when a team tells me they are using TFS.  I will never recomend it to my clients.  No keyword expansion is simply silly and the blog does not answer the reasons why, it only gripes at how hard it would be to do.  My $0.02 worth.

  37. Arne says:

    Is there at least a way I can tell which revision I have updatet the base directory to ?

    I am looking for a way to get the same functionality as the svn

    SubWCRev program

    tortoisesvn.net/…/tsvn-subwcrev.html

  38. buckh says:

    Arne, the tf properties command will give you most of what it looks like that svn app gives you.  If you just want to know which version is in your workspace, tf localversions command will do it more efficiently.

    Buck

  39. Arne says:

    I have testet the tf localversions command, but I am only able to get the revision where my root directory was added, and not the version I have updated to.

    That is also what I am able get from the tf properties command.

  40. buckh says:

    Arne, I thought I understood, but now I realize I do not.  Could you give me an example?

    Buck

  41. Paul H says:

    I'll join the long list of those that are surprised and disappointed to say the least, to find that TFS does not support keyword expansion. I read the article and wish I could tell my customers I wouldn't add the feature because it is too hard. We have to move from VSS so by definition our requirements are small. To find that TFS doesn't even do the basics of VSS is staggering to say the least. If it's hard to do the complete feature set why not start with the simple things you can do. The feature we really need is $Revision $. How are we expected to track changes to text files like sql code if you can't include the version number in the code file. I thought the idea was to make developers lives easier not harder.

  42. I can just direct you to my codeplex project, which supports keyword expansion and $Revision$ ;)

    logsubstpol.codeplex.com

  43. Paul H says:

    Yes we have looked at that.  It doesn't seem robust enough to us.  We use the version number in our scripts to determine if we need to run a particular script or if it has already been run or in fact a newer verison has been installed.  So it is critical to us that the script version number be updated and that we can rely on it happening.  Having to make sure that policy's are installed and activiated to enable this feature does not seem robust enough to me. The SCCS should make sure this happens.

  44. Ken Walker says:

    One more vote here in disbelief that Microsoft doesn't think this is an important feature to support.

    Buck–You've mentioned over and over that "some people really want it, some don't care."  But that's actually the case with many or most software features.  Isn't the point really "how many" people fall into the "really want it" category?  Can you give us an indication of that split?

    Another way I look at it: Shouldn't you guys implement the basic functionality before adding too many additional bells and whistles?  It would be one thing if some feature was obviously out-dated, but that doesn't seem to be the case here…

  45. Does TFS 2010 support keyword expansion?

  46. buckh says:

    Ken, you are right that I glossed over that.  So far, the number of customers telling us it is a requirement has not been enough to move it up the priority list.  It has moved up some over time.

    Vy6bu3aa, no it is not supported in TFS 2010.

    Buck

  47. Dave says:

    You are right it should not be part of checkin policy – it should be done by TFS itself. You are wrong this is not important since without it, there is no way to determine the changeset version of a file used as source (e.g. a script or sproc) and there is no way to determine what source is being used in the field. The product version is inadequate and there is no product version for a script in any event…

  48. Tomari says:

    It's not just, that "You have to go back to TFS" to find out the version for your not-compiled files. If yopu think about he process more in details, it looks like this: If keywords like modification-history or current (or previous) version information is missing, you a) "have to go back to TFS", but also b) get EACH version of file from TFS and compare it against my version, which is very time consuming and error-prone. The compare furthermore c) requires that you have a Compare-tool (perhaps have to even buy one!). In addition, 4) if the Production-Server is totally (physically and/or networking-wise (which is always a good idea) separated from computers where I have access to TFS-server, then this whole procedure is practically inpossible.

    So These are my for reasons why I need Keyword-extensions ASAP!

  49. Carlos Marques says:

    Can't we have keyword expansion at build time?  That's where keyword expansion becomes important before we send our code (T-SQL scripts, javascript files, classic-ASP files, etc.) into the wild.

  50. buckh says:

    Carlos, I like that approach.  I've asked the team to consider this for the next release or a power tools release.

    If you want to implement it now, this would be a good starting point.

    blogs.msdn.com/…/how-to-create-a-custom-workflow-activity-for-tfs-build-2010.aspx

    Buck

  51. Hi Buck,

    I want  do some changes as “keyword expansion” in files in Check-in Event for don’t use Check-in Policy (Client Side) for this. Other option will be create one WebService that in each Check-in, take the files changed, make check-out, make the changes and make check-in. The last solution isn’t good because pollute the history of changes.

    Do you know a way for do it in check-in event, such as: When the user do check-in, he sends the changed files to server. Before these files are loaded to server, the sever calls my application that makes changes in these files, returns the changed files to server that then loads them to server.

    I wait response. Thanks

  52. Ted says:

    I agree with Martin's comment above.  Surely the simplest solution is to expand keywords on get, view and check-out, and strip out inserted text, i.e. revert to unexpanded keywords on check-in.

    The ability to determine version details of all constituent source file that have been compiled into an executable is an extremely useful debugging aid and it is frustrating that it is difficult to implement a build process that supports this using TFS.

  53. Kim J says:

    Any update on the availability of keyword expansion in TFS2010? We really need it for our project.

  54. buckh says:

    Kim, there's no plan to add keyword expansion to TFS 2010, and we do not have plans to have it in the TFS 11 release.  It is on our backlog for a future release.

    Buck

  55. Eric Mamet says:

    Like others, I find this a fundamental feature missing for all sorts of code but in particular for non-compiled code, such as TSQL, SSRS, etc.

  56. Paul Harrington says:

    Is there somewhere where we can vote for this feature, so that it gets into the next version of TFS? I have a license for TFS but can't use it because this feature is missing as it breaks our installation process. ie. We need a version number in our text files to know whether to update them or not when "new we think" software is installed.

  57. buckh says:

    Paul, we have a site for feature requests at visualstudio.uservoice.com.  That would be the place to post it for voting.

  58. Paul Harrington says:

    Thanks Buck I have created an entry.  You can currently find it on the first page of 'Hot Ideas'  (41 votes at the moment) or by searching Keyword Expansion.

  59. I still use VSS 2005. Does it still not supported in TFS 2012?

  60. buckh says:

    Correct, keyword expansion is not a feature in TFS 2012.

  61. After reading comments in numerous locations on the MSDN/Microsoft site from many people, I think it absolutely arrogant how the folks at Microsoft state that the keywords expansion is just not important. Repeatedly – over many years, folks have been asking about getting it implemented and repeatedly MS says that they feel it isn't important.  Maybe we do need to look for a different source control tool for our company since we don't account for anything.

  62. Mark Kamoski says:

    Really??? Too hard to implement??? Really???

  63. Thomas Jeffré says:

    Hit this stumbling block on my first day of using codeplex. Thank you, Microsoft, for offering this free service. But I´m seriously considering not to use it because of the lack of $Revision and $Date. I have a mixed hardware/software project and I do not edit VHDL files with visual studio. Version control is a nightmare without version info in the sources.

    I do understand that the target audience for TFS are VS software developers (preferrably Win8 Apps?) and that people who kick the electrons through the silicon are a minority. It is ok for me to be considered comercially irrelevant. But it still appears surprising that $Revision should be so time consuming to implement.

  64. Mitch Cervinka says:

    I don't think the "binary issue" concern (i.e. people either can't live without it, or else don't use it at all) is a reason to disregard the problem.  For those who <i>do</i> use keyword expansion, it is very valuable.  Those who don't use it probably don't realize what they're missing and perhaps with a little training, they too would find it valuable and wouldn't want to work without it.

    Keyword expansion is one of the features that marks a mature, professional versioning system.  You can choose to cater only to those who don't use it, but they tend to be the casual crowd that doesn't need a professional, full-featured system.  Does Microsoft intend to sell kiddy software or professional software used by large Enterprise development teams?  To whom are they marketing this product?

    The bottom line is that…

    1. for many users and organizations, keyword expansion is an extremely valuable feature.

    2. if it is a standard feature in most other versioning software then it should be seriously considered for TFS

  65. kmh says:

    After more than 8 years of stubborn resistance and zero progress, this is simply amateurish and inexcusable. Please try again to explain why VSS was discarded and eventually left as unsupported. How can TFS be considered by anyone as a usable version control system without the most vital features?