locked
Sharing project between multiple developers RRS feed

  • Question

  •  

    Hi All,

     

    I am currently looking to utilise TFS for a developement project that I am joining that has been going on for some time.

    Can two developers work on the same project at the same time?

    How does TFVC handle the project file?

    What process is required to allow different developers to add files to the project?

     

    I wish to focus the developement on specific areas of the applicaiton (ASP.NET Web Project) but the developers have traditionally worked in isolation on seperate projects so that they can check out the project file without fear of anyone else needing it. They are currently using VSS.

     

    Best Regards,

    Rod

     

     

    Thursday, June 12, 2008 1:40 AM

Answers

  • Rod,

     

    With TFS Version Control, you have two basic options:

     

    1. The "Visual SourceSafe" Way - TFS Version Control can be setup to work just like VSS in the sense that you can turn multiple check-outs off so that only one person can have the project file checked out at any given time.  The development team that I'm currently on is fairly small (4-5 developers) so this is the approach that we generally take because it's fairly rare that multiple developers need to modify the same project file at the same time.
    2. The "Merge" Approach - If you have a larger development team then this approach can be a hindrance.  In this case, you may want to turn multiple check-outs on for your team project (see below how to do this).  In this case, multiple developers can check out the project file at any given time.  When the project file is checked in, it will go through a merge process.  If the version of the project file being checked in isn't different from the server version, then no merge is necessary.  If the server version has been modified since the version being checked in was retrieved from version control, then the changes will need to be "merged" back into version control.  In some cases, an "Auto Merge" option will be available where you can just let TFS figure out how the changes should be merged (use this option only if you're relatively sure how the merge will take place - we have lost some unit tests in the past when using this option although we're not really sure how).  Otherwise, you can manually merge the files using the visual merge tool.  This tool allows you to select which modifications should be merged from which file.

      Note that option 1 above doesn't completely isolate your developers from the merge process.  If they make modifications to files that are out of date with the server, then they may have to merge their changes during check-in... even if multiple check-outs are not turned on.  You can further alleviate some of these issues (with VSTS SP1) by turning on the "Enable get latest on check-out" option.  This option is set on the same dialog as the "Enable multiple check-outs" explained below.

    To turn on/off multiple check-outs, right-click the desired Team Project in the Team Explorer view and select Team Project Settings-->Source Control.  Check or uncheck the "Enable multiple check-out" option as desired.

     

    The difference in the approaches outlined above basically boil down to how comfortable your team is with merging changesets.  If you comfortable with merging, then you may gain some efficiencies by allowing multiple check-outs.

     

    I would recommend reading this document on going From VSS to TFS.  It's a little dated (written in 2006) but it does provide a really good overview of the differences between VSS and TFS version control.

     

    Hope this helps.

     

    Thursday, June 12, 2008 3:54 AM

All replies

  • Rod,

     

    With TFS Version Control, you have two basic options:

     

    1. The "Visual SourceSafe" Way - TFS Version Control can be setup to work just like VSS in the sense that you can turn multiple check-outs off so that only one person can have the project file checked out at any given time.  The development team that I'm currently on is fairly small (4-5 developers) so this is the approach that we generally take because it's fairly rare that multiple developers need to modify the same project file at the same time.
    2. The "Merge" Approach - If you have a larger development team then this approach can be a hindrance.  In this case, you may want to turn multiple check-outs on for your team project (see below how to do this).  In this case, multiple developers can check out the project file at any given time.  When the project file is checked in, it will go through a merge process.  If the version of the project file being checked in isn't different from the server version, then no merge is necessary.  If the server version has been modified since the version being checked in was retrieved from version control, then the changes will need to be "merged" back into version control.  In some cases, an "Auto Merge" option will be available where you can just let TFS figure out how the changes should be merged (use this option only if you're relatively sure how the merge will take place - we have lost some unit tests in the past when using this option although we're not really sure how).  Otherwise, you can manually merge the files using the visual merge tool.  This tool allows you to select which modifications should be merged from which file.

      Note that option 1 above doesn't completely isolate your developers from the merge process.  If they make modifications to files that are out of date with the server, then they may have to merge their changes during check-in... even if multiple check-outs are not turned on.  You can further alleviate some of these issues (with VSTS SP1) by turning on the "Enable get latest on check-out" option.  This option is set on the same dialog as the "Enable multiple check-outs" explained below.

    To turn on/off multiple check-outs, right-click the desired Team Project in the Team Explorer view and select Team Project Settings-->Source Control.  Check or uncheck the "Enable multiple check-out" option as desired.

     

    The difference in the approaches outlined above basically boil down to how comfortable your team is with merging changesets.  If you comfortable with merging, then you may gain some efficiencies by allowing multiple check-outs.

     

    I would recommend reading this document on going From VSS to TFS.  It's a little dated (written in 2006) but it does provide a really good overview of the differences between VSS and TFS version control.

     

    Hope this helps.

     

    Thursday, June 12, 2008 3:54 AM
  • Thanks heaps Jeff, Option 2 is my desired approach, but the team is resisting, I'll get them there.

    Sunday, June 15, 2008 4:33 PM