TFS: Create a new project from an existing one in TFS

Question

What is the best way to create a completely new project in TFS by copying an existing one?

I have an ASP.NET project that will have 50+ "releases" per year. Each release is a distinct entity that needs to remain independent of all others. Once created, I want to make sure that any change to one (the source project or the copy) does not affect the other.

This is for source control only. I do not need to copy any work items.

In the pre-TFS world I would do this by simply copying the folder that contained all of the project files. This had me 90% of the way to the new app, which I could then tailor for the new release. It is very rare that I need to actually add functionality to the base application, and even when I do it never affects existing apps. Is this still possible using TFS, by copying my local folders and then adding the copy into TFS as a new project?

Any suggestions? One branch per release looks like the "standard" way of doing this but I will quickly end up with dozens of branches that really aren't related, and I'd rather keep each new project as it's own distinct project, with no chance of changes in one affecting the other.

Thanks!

• Thanks for the responses. I think you've all given me enough insight to get started. Richard, thanks for the detail. I was a bit concerned that it might be too easy to accidentally merge the branches.

Answer 1

There are really two questions here:

1) Is it better to copy/paste or branch?

I'd venture to say that copy/paste is never appropriate. Unless you are very careful (at minimum, run 'tfpt treeclean' immediately before copying), it's likely you'll end up checking in some inappropriate files to the new location. In addition, you will be using up FAR more disk space on the server, since it must store 50+ full copies instead of just diffs.

There is virtually no danger that branches will "accidentally" become comingled down the line. Merging branches back together involves at least 3 deliberate steps: pend the merge (itself a 4-page wizard), then resolve all conflicts, then checkin.

Nor are you likely to get confused as to your place in the tree. TFS uses "path space" branching. That means branches appear to the user as separate physical locations in the source tree, rather than mere version-tags on top of the same path. Since branches look like folders, you can do all the normal folder operations on them: Cloak (don't download them to your local workspace), Permission (in particular, removing someone's Read permission will ensure they can't even see it), Delete or Destroy (when you're truly done with them).

2) When is it appropriate to create a new Team Project?

This is a more complex topic in general. Official guidance. My opinion.

However, I'd say your case is easy: don't do it. Team Projects have a lot of overhead. There is a finite number you can create on a server...ever. Don't forget about other forms of overhead too, like the time it takes for the project admin to port over all your settings, and the time every developer on your team spends reconnecting his Team Explorer.

All for what? The links above go into great detail about the forms of sub-structure that can be created inside a single Team Project. In short, almost anything is possible. The only areas that are somewhat lacking are Team Queries and Build Definitions, which are restricted to a single container folder, and a few settings like Exclusive Checkout which are all-or-nothing. Unless you have a very large or very diverse team, the benefits of separate team projects per release are very unlikely to outweigh the drawbacks.

Of course, if a "release" is a major event that signals a change in your SCM practices , that's a whole other story. New SCM => new process template => new team project. But I doubt you do that 50+ times a year :)

Answer 2

I would recommend using branching. Create a branch for each release from the main branch. As long as you do not merge the branches they will remain independent. Changes to the main branch will only affect releases created after the those changes were made.

You could copy the files and create a new project, but you may run into a couple of problems:

• The projects "remember" that they were in TFS, there is a bit of manual work to clean up special files etc.
• TFS may slow down when you have many projects, compared with a single project with branches

Answer 3

This might sound obvious but you should only create a new project for a "new project". It sounds like what you are talking about are different versions of the same project.

If you want to maintain separate codebases for previous releases then as the other answerers have said, branching the code is your best option. This works nicely when you want to merge bug fixes from your latest version into older releases too.

However if you really really must have new projects, you still use branching in the same manner.