I'm not very familiar with TFS, but as most version control systems use the same terminology you should figure something out of my response (I hope :P) Also as there are many models of "branching" the below answer covers my experience and practices that I'm used to at work and on home projects.

I assume the 3 version of code represent some work in progress, as V2.0 is modification of relatively stable V1.0 and similarly the V3.0 is based on V2.0.

I assume you "release" those three versions of Pong in order (like release V1.0 then start working on V2.0 and so on...) working on the master branch or trunk.

So as you release V1.0 you attach a tag or label (i.e. "Version 1.0") to this exact commit that is deployed. Then just work on, committing your changes and so it becomes (pre)V2.0 and after you deploy you again attach a tag to it ("Verions 2.0") and start working on (pre) 3.0.

Now suppose you found a bug in V1.0. Because you attached a tag to it, you can find it easily and create branch from that tag. That will give you exact source code that was deployed as 1.0. You fix the bug and redeploy from that branch. This branch will sit there forever and you fix any other bugs for 1.0 on that branch.

If the bug also affects other version you have to fix it again on master branch (for v.3.0) and if necessary also create a new branch for 2.0 and fix it there.

So you will end up with one master branch (current 3.0+ development) and a "hot fix" branch for any fixes to old versions.

To work on different branches you can switch you repository to the branch of your current interest. This will replace all the files with their versions relevant for given branch.