What would be a reliable way to copy some files from a project within TFS projects collection A to another project within TFS projects collection B regularly. The latest from source is to be taken and check into the destination, overriding conflicts (if any). I have automated Team Foundation Build and can add a script or step within it. I would prefer this to be a part of automated build but it would also be fine if I had to run it nightly at a fixed time. I just need a reliable and automated way to do it.
You may want to investigate the Team Foundation Server Integration Tools, which allow you to set up synchronization between two TFS servers. You can set up either bidirectional synchronization or unidirectional synchronization between two servers - in your case, it sounds like you want unidirectional synchronization between collection A and collection B.
We've been using the bidirectional synchronization for about a month now and have been very pleased with it.
I think that you might want to reconsider that course of action. The boundary between TPCs is meant to be a strong one: they are supposed to be two sandboxes. What would be your reason to port source code (I'm assuming that this what you mean), from one sandbox to another?
If what you really need is the outputs (say you are building a component in one TPC and need to use it in another), then perhaps what you really want to do is to arrange for the project that builds the component to deposit the output (binaries, for example) in an accessible network drop location, and have the consumers (the second TPC's developers and automated builds) copy those and add them as references where needed.
This way you do not risk as many conflicts in the code, and actually promote better reusability.
Hope this helps,
Assaf
Related
Can anyone give me a definitive answer as to whether or not TFS 2012 allows multiple build controllers for a single collection? I can't seem to find anything that says no, but it also isn't well explained as to if it is possible. I understand that the typical solution is to expand by adding more agents, but the purpose for a secondary controller is that I want to roll out a second custom workflow with separate assemblies to run against the same collection without breaking our original workflow (which is also run using custom assemblies). So this is sort of a blue/green or drain/fill approach for testing new build steps on a live system without breaking the existing system. It appears to almost work but we've also seen some TFS connectivity issues (connection terminations) when fetching code for the build workspace which did not exist before we tried this.
Looks like it is definitely possible. Check the MSDN link and look at the topic "Multiple Build Server system". In the picture it show a single collection which is connected to multiple build controllers. Definitely possible.
http://msdn.microsoft.com/en-us/library/dd793166.aspx
The video below also give you a step by step process on how to do it.
http://www.youtube.com/watch?v=tGyYvdxoJKU
I know it is definitely possible in TFS 2010, so I can't imagine it wouldn't be in 2012. We haven dozen of build controllers (with a few build agents each), for a variety of reasons - building different products, with different tools, in different geographical locations.
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
I am pretty new to TFS but I have some experience with VSS. I like to know your opinions of what would be the best way of working with TFS in the following scenario:
We are a group of developers working on projects. All projects starts from a common base code. All projects are one man only, no code sharing until the project is done. A project can last from a few hours to several months, no code is merged until done. Any developer works simultaneously on more than one project, usually 7-10 projects at a time. Usually the projects only involve a small numbers of files that are changed/created (10-20) but rely on a large group of infrastructure files that change quite often. However, any change in infrastructure is not considered until the merge, so we don't get latest version from server until the final build.
An additional request is that, when merged, we’d like to use a 3 way merge tool. We use this approach in VSS, via a custom made application and it works very well. However this involves special file management, for example every file that has to be changed must have an original version saved somewhere that will be used as the “root” file for the 3 way merge process.
What do you think?
You should take a look at the Visual Studio TFS Branching Guide 2010. (direct download). In that package, there is a PowerPoint deck that walks you through a series of possible branching structures.
It sounds like you want either "Branch by project" or "Branch by developer" (since you only have one developer per project, these are effectively the same).
Regarding the 3-way merge tool, take a look at this list to see how to configure your favorite diff/merge tools.
We are moving to TFS 2010 (from PVCS) for source control and work item tracking
As I understand it you should have under source control for each TFS project everything that projects solutions, etc. need to build.
This OK for new .NET solutions/projects, but we have a large collection of legacy Delphi 6 projects with shared source libraries we want to port into TFS for source control and build. It is how we manage multiple TFS projects that want to sare a specific set of source files between them that is my problem here.
Historically with PVCS we have had projects for each solution (say A & B), and a seperate project for common source code (say C). Users would get C then get either A or B (checking out as required) on disk this would maifest as something like this:
$\Projects\C
$\Projects\B
But B & C are seperate PVCS archives.
Now fast forward to life with TFS 2010 as our ALM solution...
If we create a TFS project (1) that contains the source repository for the common code (C), that projecs can obviously access it (lets say the TFS project also contains the solution A) and all is good.
We now create a new TFS project (2) in which to make solution B. Beacuse solution B is wildy different to solution A we had no reason to share TFS project 1's source control so we made a new source repository rather than branching from 1. Now later on we discover a need for solution B to access some common files from C (in 1). Oops!
The question is this; can I perform some source control wizzardry that lets me add a folder in the 2's soruce control that is a (to steal a file system term) symbolic link into 1's source control for the common code C?
Edit
I should point out this is all legacy code and the shared source library (C) is just that shared source it does not build into a library or other binary we could simply add to A or B.
In TFS 2010, as you may know, they introduced the concept of a project collection (PC). Each project collection is an aggregate for team projects (TP). Each PC is stored in a separate database, and the VCS is stored in the database.
This means that there is one VCS repository per PC, not TP. Each TP is (by default) the root folder in each VCS (i.e. TP1 will be at $/Prj1, TP2 might be at 4/Prj2, etc.)
One more point is that you do not want to have one solution per TP. Think of a TP as a suite of products, and a solution as a part of that.
Symbolic links, as per Visual Source Safe, no longer exist in TFS, and I'm not sure you need them. It is not considered a good practice to create a dependency between one solution and the source code of another solution.
What I suggest you do, is have each solution in your codebase depend only on its own code, and on other solutions' binary deliveries.
What will happen is that if Sln_A depends on Common_Sln, you will build Common_Sln, and bring its binaries from the drop location as part of your Get. Then, add the binaries as references.
This will solve your problem, with the added benefit of transforming a tight coupling where a dependency may break your dependent solution's build, into a situation where you do not change or upgrade your dependencies until they are ready and you are ready for them.
Does this help solve your problem? This is how I do this with the projects I consult on.
HTH,
Assaf.
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.