locked
Keyword Expansion RRS feed

  • Question

  • Hello,

    I understand that VSTS does not support the keyword expansion elements of VSS ($History etc). Given this does anyone know how a developer could identify the version of a code file on their system without accessing source control?

    Thanks,

    Si...

    Monday, April 24, 2006 10:43 AM

Answers

All replies

  • Unfortunately, at this time there is no way to determine the version of a code file w/o accessing source control.

    Ed

    http://blogs.msdn.com/edhintz

    Tuesday, April 25, 2006 2:50 PM
    Moderator
  • Don't you consider removing a feature that has been in version control for 3 decades is somewhat of a serious brain seizure?

     

     

    Thursday, June 8, 2006 4:42 PM
  • Not really.  The whole point of building version control on SQL is that you don't need to store this kind of metadata in (fragile, hard to query) text formats anymore.

    Note that TFS was written from the ground up; we didn't "remove" anything.  It may appear in future versions depending on time & interest.
    Thursday, June 8, 2006 5:30 PM
    Moderator
  • then SQL sucks more than I'd been led to believe

    "expanding" a keyword to put the "id" of the last person to change the file in human readable form doesn't seem very difficult... you know sometimes you just gotta ask them what they were thinking of (like I'm asking you what YOU were thinking of).

    IF we don't have readily availalbe the things we got used to in 3 decades of doing version control, where, pray tell, is the "philosophy of our 'new better' version control" document?  If it was written from the "ground up" (means, we won't look at anything similar to see if it's useful) there _must_ have been some overall philosophy of use somewhere.  How are we to effectively use this "new better" system if we have to guess at how to use it?

    I admit I badly _need_ the ability to have multiple people have a file "checked out" for editing (of course it's not the default, but I can live with that).

    change sets (atomic commits?) are quite useful.

    It will take a while to get used to not having individual file versions.........but a couple of people have "gone ballistic" about no "keyword expansion" and have suggested continuing with VSS <super YUCK> which, of course, won't let multiple people work on the same file.

    Thursday, June 8, 2006 9:30 PM
  • Rightclick -> History seems more useful to me *shrug*

    While I don't think keyword expansion is integral to our "version control philosophy", I agree it's sometimes a nifty thing to have.  If it's important to you, please vote for it at connect.microsoft.com (opens Friday).  We do look at those responses when designing future products.
    Thursday, June 8, 2006 9:47 PM
    Moderator
  •  Richard Berg MSFT wrote:
    Not really.  The whole point of building version control on SQL is that you don't need to store this kind of metadata in (fragile, hard to query) text formats anymore.

    Note that TFS was written from the ground up; we didn't "remove" anything.  It may appear in future versions depending on time & interest.
    Coming in late...

    Your comments make some pretty basic assumptions about working with source code.  You assume that everyone modifying the code has access to checkout and checkin files.  For many reasons, this may not be the case. A file may be distributed to someone outside the team or organization, for whatever reason, and modifications made.  If the version of the file in history is not known, automatic merging of those changes is near impossible.

    One scenario I often perform with VSS:  Receive a modified file from 3rd party.  Look at the expanded keywords to find the SCC version of the file they were given.  Checkout said version of file.  Copy modified file overtop of the filesystem version of the file.  Attempt checkin.  The automatic merge will perform the merge notifying me of any conflicts.  Most of the time there are none and the changes are automatically merged.  Sure, not a fun task; but a task I've had to perform in many different organizations.

    Without automatic keyword expansion this type of scenario cannot automatically be supported.  External tracking of individual file versions would need to be performed, leading to human error.

    Why would the implementation detail of storing revision information in SQL server make keyword expansion in TFS any less useful?  Maybe the PowerToys team can make a quick toy to perform this?

    Tuesday, September 26, 2006 1:37 PM
    Moderator
  •  

    Even later....

    Just had my first encounter with TFS and was shocked by the absence of keyword expansion!

    A header with at least $Log$ and $Revision$ in every source file has always been mandatory in my projects. I need to able to check the revision number again and again without accessing the damn SQL Server. I'm not paranoid, I'm human! I make mistakes and this one of the ways I can prevent them.

    And I need the logs so I might get a clue where to start searching for a bug - yes, I know they are on the SQL Server but I don't want to HAVE TO go there all the time.

    And then there is one of my favourites: Expanding the keyword information into a constant or variable. Can be very useful sometimes,  it's extremely easy and always up to date!

    So please, please bring back the keywords!

     

     

     

     

    Monday, October 2, 2006 2:11 PM
  • There is a feedback bug open for keyword expansion on Connect.  If it's important to you, please vote here: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=192014
    Monday, October 2, 2006 6:54 PM
    Moderator
  • Shame, it was obviously considered, as docs seem to refer to it -

    "By defining a file type, you control whether files with a given extension can have internal keywords expanded during a check-in"

    ms-help://MS.MSDN.vAug06.en/tfsadmin/html/80d71b21-c106-4fd6-9fee-6372585bf41e.htm

    Monday, October 16, 2006 9:11 AM
  • I've logged a bug about this documentation error at https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=227931
    Monday, October 16, 2006 7:44 PM
    Moderator
  • We ship C++ header/source files to our clients as part of the Development kit,
    we need to track which version of files they are using. Current version control system(PVCS) in our organization
    helps us to achieve this with Keyword expansion. Is there is any alternative way to track the revision of the source code
    which is out side the TFS.
     
    -Pramod
    Thursday, October 19, 2006 9:34 AM
  • Thanks for reporting the doc bug.

    Pramod: typically this is done by your build system.  The same process that adds version #s to your binaries can probably be extended to add timestamps (or whatever) to the *.h files as it packages them into your SDK.
    Thursday, October 19, 2006 10:20 AM
    Moderator
  • It has been an year since the discussion about keyword expansion. I couldn't find in the documentation of SP1 in TFS that Keyword expansion was included or not included. The bug item appeared to be closed (won't fix).

     

    Is there any update any one aware of? or, is there a opower toy that supports this feature? Please advise.

     

    Prabhu

     

    Friday, December 28, 2007 9:12 PM
  • Keyword expansion is still on our "wish list" of possible future features.  It is not currently offered in any released version of TFS (2005, 2005 SP1, 2008) or any of the TFS power tools.  Sorry.

     

    --Ben Ryan

    Wednesday, January 2, 2008 2:56 PM
  • Thanks Ben. I can use the view history and annotate feature meanwhile to read through the logs. Please post in your blog in case if there will be an update available in future.

     

    Prabhu

     

    Thursday, January 3, 2008 2:57 AM
  • Today I published my "Keyword Substitution Check-In Policy" on codeplex:
    http://logsubstpol.codeplex.com/

    Any comments are welcome!
    Jochen Kalmbach (MVP VC++)
    Sunday, August 9, 2009 7:29 PM
  • This is absolutely incorrect thinking - we DO need this kind of metadata in our source as there is other NO way to identify what version of a script, or binary is running in the field, without adding keyword support to TFS. If you think otherwise, please enlighten us...
    Tuesday, February 8, 2011 9:27 PM
  • > This is absolutely incorrect thinking - we DO need this kind of metadata in our source as there is other NO way to identify what version of a script, or binary is running in the field, without adding keyword support to TFS. If you think otherwise, please enlighten us...

    While the thread is a couple of years old, I must say that I found the comments from Richard Berg astonishingly arrogant. The statement about the database being in SQL completely misses the point.

    And the Connect entry with 86 for and 2 against is closed as Won't Fix.
    https://connect.microsoft.com/VisualStudio/feedback/details/192014/support-for-tfs-keyword-expansion

    I'll will have to look into Jochen's work.


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
    Links for SQL Server Books Online: SQL 2008, SQL 2005 and  SQL 2000.
    (Just click the link you need.)
    Tuesday, February 8, 2011 10:19 PM