Is there any guidance about workspace naming and workspace mapping in TFS (2010) ?
I'm not aware of any specific guidance on this, but after a couple years, we've primarily settled on a single workspace mapped to root $/. We've been operating like this for probably a year with 80+ developers, and haven't seen much of an issue.
In my opinion, this is valid, as is the idea of one workspace per Team Project, as long as you don't have a whole lot of Team Projects to deal with.
For the Mapping aspect there is nothing to add to the first answer as- "Map to root $/" approach seems to be the most used.
However, the MSDN Basic Guidelines for Creating a Workspace seem to suggest a different approach:
If you want to work with files from a single folder, map to one that is as close to the level of the team project collection as you can but no closer than you must. That way, you will get all the files that you need without getting many that you do not need.
I would tend to say that workspace naming conventions are only helpful if you need to create multiple workspaces on the same workstation. That would be the case if you need to work on different codebases hosted in different team collections or on different branches of the same codebase.
Like mentioned in previous feedback, I did not find a reference specifically addressing the topic, but the "Naming your TFS workspace" article from the old TeamPrise Explorer documentation has some good suggestions:
(...) give workspaces a name that includes your machine name, your deliverable, and branch if applicable.
"Deliverable" is organization specific, but can likely be related to a single team project so that the name of the project could be used to correlate the workspace to it (rather than using a different name for essentially the same thing).
Related
This is a problem we have been living with for a while already. Suppose that I have three files:
a FxCop ruleset, containing our basic Code Analysis rules
a Resharper .DotSettings file, with company defined naming conventions, for instance
a StyleCop.Settings file, with some of the default style cop settings disabled
How do I share these kinds of company wide settings files across multiple TFS Team Projects?
At the moment, we have these replicated in a Resources folder in each project, but this is quite a maintenance nightmare, since when we decide to update a few rules on any of these files, we have to update them in a lot of different places.
One approach I've seen is to create a team project specifically to store these files on TFS, for instance $/Core, and by some means share the files this way, either using workspace mappings or branching the project into the other projects.
I don't like this primarily because it requires manual intervention and hardcoded paths. Ideally, I'd like an approach that was not intrusive, i.e. a developer gets the project from source control and compiles without any problems. No need for separate mappings into specific forlders, setting environment variables, anything like that.
At the same time, I'd like to keep the history on these files, so it would be nice if they could still be source controlled. Since they are central to the company, it would be ideal to have limited permissions on them, and that each change was documented appropriately (changesets provide that).
Another approach that crossed my mind was to share these settings via company internal nuget packages. Say for instance that I do have this $/Core project, but instead of using workspace mapping or branching it inside the other projects, I publish a nuget package (or more than one even) containing the configuration files, and add these packages to each project that needs it. I can then use relative paths to the package folder when referencing them, and it would require no manual intervention on the developers part.
Although using nuget would probably work fine, this solution seems weird to me, since nuget packages are meant to be project specific, but this would be "whole team project" specific instead. Again, using this approach, I'd probably have to add the package to one of the projects inside one of the solutions inside each team project. This is actually quite similar to how test adapters are shared now. For instance, NUnit already support this approach. I feel I'd have to do something very similar to that if I went with an internal nuget package: each solution would have to load the package at least once.
Is there some other way to share these kinds of things across the whole company, while still maintaining them on source control? What if I loosened this constraint, and accepted that they don't need to be source controlled? Would it open up other options to share them?
If you go down the NuGet route, you could create Packages for your FXCOP and Resharper files, and then store them in a local feed.
For Stylecop you could use the existing NuGet Package for StyleCop.MSBuild and then repackage it with your own settings file.
We are trying to move from our current source control to a TFS as a source control. Right now we have all projects as project references. Our organization is small and we have a lot of common projects that are used by various development teams and all teams update these projects as needed. When we migrate to TFS we are looking to use DLL references for these projects but I am wondering if that would make branching impossible and I am also concerned about is there a benefit of having DLL references to the projects that all teams in the company need to make changes to.
Could you please suggest, given our scenario, if it would be good idea to have DLL references to our common projects or to have project references. Any links to suggested readings would also be helpful.
Depends on the size of these projects and how often you make changes there, dll references are generaly used for 3rd party libs, if you own common projects are not often changed and/or changed by small/dedicated group of ppl then it may be benificial to treat them the same way, otherwise its better to have project references.
Im not sure why dll references would present branching problems ? You branch them just like any other code or project, if they dont differ per branch you can save yourself time on updates and keep them outside branch in single location.
In our current project we have four different TFS2010 Team Projects in the same Team Project Collection. The reason for this is that different parts of the project wanted to use different team project templates (CMMI vs Agile).
All projects now use the same template. Therefore we have now reached the conclusion that it would be better to merge the projects into a single team project. This raises several questions:
Is it possible / feasible to use one of the existing projects as the target project for the other three?
How do we move our existing work items into the new project whilst maintaining our area tree? We hope to create one root area for each of our existing team projects, and move all work items / areas underneath this root node.
Today we have work item links from one team projects into another - how do we keep these links when merging?
What is the best practice when moving the source code? One clear approach is to simply copy it to the new location, and locking and keeping the old team projects in case we need to access older versions of the code. But is it feasible to use branching for this, e.g. branching all existing code to the new team project? What kind of problems might this approach cause?
Thanks for your help!
Unfortunately, TFS 2010 doesn't allow you to merge team projects.
Stucturing Team Projects and Team Project Collections is one of the most important strategy decisions to make before starting to use TFS. Unfortunately, a lot of the customers we help don't make the up-front planning necessary and don't understand some of the limitations in TFS around merging, moving, splitting, etc. team projects before they start diving in to using TFS :(
When we have consulting engagements where customers want to consolidate their team projects, we end up having to do a lot of manual work to migrate the artifacts. We have built some tools to help us with this process for work items but for the most part it's a lot of tedious consulting work. The migration utilities always end up needing to be customized for each customer as well since they usually have different business rules for how they want to migrate.
Ultimately, a "migration" doesn't end up bringing over all of the information and you end up with some other problems like date/time stamps being different from what they were originally. (I have heard it referred to as a time compression issue with migrations.)
Some additional thoughts for each of your original questions:
Sure, you could theoretically use one of the existing team projects as the target for the migration of the other three. As long as you like the team project name and don't want to rename the team project. :)
This is where we have built custom work item migration utilities to assist our consulting customers. You would likely need to do the same.
This is possible as well with a custom work item migration utility. You can just keep track of the mappings between old work item IDs and new work item IDs and then add the links later once all of the new work items are created in the target team project.
That's ultimately up to you. I would do a "move" version control operation on the source code from the old team project to the new team project. This maintains everything. However, I would not delete any of the old team projects because that will cause the version control history to be destroyed as well.
It's not the best story for you but hopefully it will help your planning out some!
I have had a nagging feeling for some time that I may be ignoring useful qualities of TFS Workspaces. The site here provides some great background on what they are: http://www.woodwardweb.com/teamprise/000333.html.
However, given this information, I don't really understand when I ought to create a new workspace. Do I create one for each "project"? Do I create one for each project-branch? Do I need to create mirror workspaces on every machine that I intend to work on? I'm not sure what I need to consider when making this decision.
Is there a best practice describing under what circumstances to use different workspaces?
Note: although it may be interesting to learn what practice others follow, I am more interested in learning about how to make the decision myself. I'm not really asking "When do you create new workspaces?". Instead, I am asking "How do I decide when to create a new workspace?".
A workspace is defined per machine, per team project collection (TPC), therefore you need at least one workspace per machine you are working on, for each TPC you use.
Having a snapshot of the entire TPC on your machine might be both wasteful (you might not need access to projects or solutions that are maintained by other teams or developers, so you might want to create a workspace per team project or even one workspace per solution.
If you find yourself working on more than one task at the same time, you might want to create one workspace per task. This is considered a best-practice, and will allow you to separate the changes you make and check them in one task at a time (e.g. one workspace for a development task such as build a new UI, and another for fixing a bug recently found by QA).
Workspace per task works particularly well if your task vertically crosses multiple solutions (e.g. adding a UI, business logic, SOA service and updating the schema on a remote database, all as part of adding a new feature to your product); A task will rarely (if ever) cross team projects and should never cross TPCs.
Short answer, when you need to :-)
If you need to edit code on multiple machines then you will be forced to create a workspace on each machine.
Some people like to have a workspace per Team Project, others per branch or even solution.
Are you working on the same codebase but for different reasons? Branching is usually used to solve this but sometimes it's not an option.
Are the folder / file names in your repository causing you to hit the windows 260 character limit in a path? If so, time for a new workspace.
I tend to have 1 work space per machine mapping $/ to C:\tfs but that's my preference. The only time I create a new workspace is when I need to limit the number of files in scope.
For example, rolling back a changeset. If you use the tf rollback command (or tfpt rollback in 2008) then tfs insists on performng a get latest on the entire workspace. If you've got your workspace mapped to the root of a big team project this can take a long time. Setting up a workspace that only includes the folders that contain the files in the changeset can be a real time saver
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.
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 :)
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
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.