team foundation server

Hi ,

  I am programmer  and  a user of Team foundation server ( on TFS more at a beginner level)   .  Currently during the development , I am asked to do the following
     Checkout "my latest work folder" ( this term is explained below)
        When a release comes during development for testing ,  Create a new folder  ( naming folder as Projname_CurrentDate . For example if ProjName is XYZ and today is 2015/08/03 name is XYZ_20150803)
Even if a minor modification comes , create a new folder in TFS  and upload release in it)

 Is this approach really recommendable ? Infact, it potentially will have around 100 folders , which in my opinion is not a good idea

   My opinion is to have a single folder ( or  folder per revision and not each version)  .

   Can I get some expert advice on this ? ( Also, I am not quite sure how a new version is created   in TFS )

   Also, Is branching the way how  another guy developing some  of the modules will branch out and develop his modules ?

       I have attached a snapshot of how TFS folders look like now. Project name is erased for security reasons
Sam OZAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Bob LearnedCommented:
Here are my recommendations:

1) Structure


2) Main trunk should always build without errors--strive to never break the build.  

3) When you need to create a new version or test out a large code change or refactor operation, branch from Main into Development folder with version.

4) Have a few people do merges from development branches into Main trunk, to reduce risk of breaking the build.

5) Do all your work in Team Explorer, or Visual Studio IDE so that TFS is kept in sync.  This means don't do any work in Windows Explorer, like renaming folders and files.

6) Make sure file paths are relative, so that when you branch into a different project folder the folders don't have to be changed.  Assembly references, and project paths are relative, so you won't need to worry about them.
Sam OZAuthor Commented:
Thanks Bob.

    The point that I still annoys me is -

     A release (version 1.0.0)  is given  to the Test guys . Some minor error is found .  Do I need to  create a new version just with the correction ?  During the couple of days of testing , sometimes similar things can happen 10-15 times ( Is this not enough to checkout and make changes and then checkin ?  Do we need to create a new folder by name Version 1.0.x for this ? )

 Also, Another point I am not sure is , How multiple people make changes in TFS environment ( If it is disconnected mode) .  That is -   Programmer1 is working on Page1 and Programmer2 is working on Page2 . How  each get a copy work on it  and merge later ( Programmer1 may have a release today for testing  and Programmer2 have a release tomorrow)

Bob LearnedCommented:
Let me give you a scenario:

You need to make a minor change, unit test it, QA the system, and deploy it to production.  This may take weeks.  In between the start, and deployment, someone says, "We need to do an emergency fix for another issue, and deploy that change".  If you make a change in Main, then you would need to revert the changes that you made for the minor fix, so that doesn't get deployed with the emergency fix.

There are different approaches, such as shelving pending changes, and then making the emergency fix changes.  I prefer the branch process, because it is cleaner, without the risk of breaking changes in Main.  All deployments should be from Main.

You can forward and reverse integrate changes with TFS.  It is a simple process through the IDE.

Branch strategically

Branching and forward/reverse integration is a personal choice.  There are a variety of opinions, so you need to take the information that you get, and make your own choices for your development team.  Some strategies are like squirrel hunting with an elephant gun.  If you have a few solutions, and small development teams, complex branching strategies may not be advisable.

A Straightforward Guide to Branching

Multiple changes can be made to the same code base, as all code is local to each workstation.  There a good practices, such as getting changes from TFS before making any changes, to reduce the amount of merging multiple changes.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
.NET Programming

From novice to tech pro — start learning today.