locked
How to make a file in source control writable when get it's latest version? RRS feed

  • Question

  •  

    When I get latest version of a file, it's automatically read-only. How can I configure the source control system that make some files writable when get their latest version?

    Thanks!

     

     

    Monday, December 26, 2005 8:16 AM

Answers

  • TFS source control would not let you do that. The source control systems want users to be explicit about their intent to change the files, the checkout command.

     

     

    Friday, December 30, 2005 8:50 AM

All replies

  • TFS source control would not let you do that. The source control systems want users to be explicit about their intent to change the files, the checkout command.

     

     

    Friday, December 30, 2005 8:50 AM
  • Amit is correct.  It's something we may consider for v2.

    Buck

    Friday, December 30, 2005 4:01 PM
    Moderator
  • I have posted several questions/observations/complaints in this forum about "missing" features in TFSVC.  "Right" or "wrong" in your opinion, if the feature is in VSS then someone out there is using it.  My team's personal beef is not being able to force a get latest upon checkout.  Really, what is up with that???

    I once consulted on a project where the client's lead developer insisted on making the entire code tree (over 10,000 code files, 10M lines of spaghetti VB code) writable upon a get latest because his personal experience was that it was much easier to make changes and compile on writeable files.  After he got his changes working he checked out the files to change and posted the edits.  I would never do that but his system worked for him and there was no changing that.

    The point there is that you cannot legislate morality.  Most developers I know are ready to move to a better version control tool than VSS.  Although you have developed many compelling features and characteristics in TFSVC, you have missed the boat on flexibility and transitioning.  It seems that you are almost ignoring the huge VSS user base and how they may have been using this tool for years. 

    Case in point: On my current project the top 3 developers have collectively executed over 50 Visual Studio development projects using version control, some of them huge projects with dozens of developers.  Not one of these projects opted to use multiple checkout or to not force a get lastest upon checkout. 

    Friday, December 30, 2005 8:52 PM
  • You are correct that there are features from VSS that are not provided in TFS.  The reverse is true as well.  For a variety of reasons, there was never a goal of having every feature that VSS has in addition to what's in TFS.  We're going to take into account feedback from users of VSS, ClearCase, Perforce, Serena/PVCS, CVS, Subversion, StarTeam, etc. when deciding what to implement in v2.  The feature set of v1, as well v2, is also heavily influenced by how we use it internally.

    In the end it's a matter of making choices on how to spend the finite amount time available for developing, testing, documenting, and internationalizing a system of version control, work item tracking, and build that, hopefully, provides a cohesive workflow for v1.  We'll build on it for v2, and many folks are listening to the feedback from v1.

    Buck

    Saturday, December 31, 2005 3:56 AM
    Moderator