We have 50+ projects divided into 2 solution trees managed by TFS (Version: Visual Studio 2008 / TFS RTM (9.0.21022.8)).
30+ projects are Visual Studio 2008 projects and others are Visual Studio 2010
New projects use some older assemblies via references to binaries.
During developing new projects we have to make changes into older assemblies so we have to keep 2 MSVS instances opened simultaneously.
Is there a way to share compilable sources with TFS between two different studios solution trees? Or shall we upgrade 2008 solution tree to 2010? Does TFS 2008 support shared projects (or may be it have to be upgraded too)?
Thank you in advance!
Andrew:
First off, we violate a couple of "best practices" to accomplish this, but pragmatism is where best practice meets the real world.
What we do is this:
All binaries are checked in to TFS within a LocalBin folder that consolidates all of our binaries.
All shared assemblies are located within a folder called LocalBin/SharedBin
The SharedBin folder is branched to a top-level SharedBin folder within the consuming team project(s).
On a successful main build, the LocalBin/Sharedbin is merged to the projects' SharedBin folders.
It winds up being something like this:
$/ProjectA/Main/Localbin/SharedBin is branched to $/ProjectB/Main/SharedBin and $/ProjectB/Dev/Sharedbin (as well as the equivalent folders in $/ProjectC, $/ProjectD et cetera).
We only do this sharing when we have a successful MAIN build, and the build is responsible for merging not only to the other MAIN branch projects, but also to the DEV branch projects, so they are up to date.
We've toyed around with the idea of coping the binaries to a shared network location after successful build, and having a convention to reference those binaries in that network share, but this process is working well for us today, and we're loathe to make changes to it at this point (more important things happening for now).
This is one of those things that's hard to fully describe in a posting, so if you have further questions, I'd be happy to try to answer them.
BTW, our solution was built and is running under TFS2008 with thousands of project files, and likely millions of lines of code. It does increase the build time due to the merge and increases the amount of space used in your repository, but both have been manageable thus far.
Related
We are using TF Service. As per best practices, we perform frequent merges.
The merge tool does a bad job handling merges for our project files. We get duplicates for Views, Controllers, even our PublishProfiles Folder.
I have a hard time believing that TFS hasn't been optimized to deal with something as trivial as dupes. The logic within our controllers, EDMX files, and Views should be more complex to merge, yet are handled better.
Are we doing something wrong? More specifically, is there an option or setting for TFS that better deals with such issues.
This is a known issue with the not so good Merge tool that accompanies Visual Studio 2010 and this Visual Studio 2012 has a completely renewed merge tool that can do contextual merges between XML files, which greatly reduces the chance of these types of issues cropping up. Since you're seeing this in Visual Studio 2012, I'd love to see a couple of examples that go wrong. I haven't had major issues since upgrading to Visual Studio 2012.
As a best practice, I tend to always do a Get-Latest before adding new files. And I always check in as soon as possible after getting the solution to compile again. This reduces the chances of these issues when you're working on the same branch. You might still end up with these types of issues when doing a merge between two branches though.
Additionally, instead of using the Visual Studio 2012 merge tool for all file types, you can set a custom merge tool for specific file extensions, that way you can use any commercial or open source merge tool instead of the default one. There's quite a few great examples out there:
WinMerge
BeyondCompare
TortoiseMerge
P4Merge
KDiff
Etc, etc, etc...
Your mileage may vary between the different tools out there.
In a team of only 3 developers this issue affects us badly with VS2013 and TFS2013. The best recourse I could find was to disable automatic conflict resolution in the settings menu.
http://donovanbrown.com/post/I-dont-trust-2012-Auto-merge-but-it-does-it-automatically-.aspx
we have 2 dev teams, one team work on TFS2005 and the other team work on TFS2010.
it's the SAME project but one team is continue to work on .net framework1.1 project version and the other team work on the .net framework4.0 project version.
WE HAVE ONLY SOURCE CONTROL (NO WORKING ITEMS AND ETC...)
after we do the first import from TFS2005 to TFS2010 to TPC X, can we import after one week just the changes of the passed week?
can we do import (TFS2005 to TFS2010) to the same TPC X (already existing one) ?
can check in can be done automatic to 2 TFS servers ?
I'd avoid splitting your code base accross 2 servers if possible. Once you've moved the code in to TFS 2010 I'd use branching to distinguish between the .net 1.1 version of the code and the .net 4 version.
Once you have the code in branches you can merge the code on a regular basis to keep the versions in step.
You need to think about what branching stratgy works best for your situation, read the guidance on codeplax to help you decide. Your branching strategy will depend largly on whether the .net 1.1 version of your code is being actively developed or if it's just in maintenance / bug fix mode.
If you're using VS 2003 to do the .net 1.1 development you can use the MSSCCI provider to give you basic TFS integration.
From your description it sounds like you already have two versions of this project in two separate TFS Servers. I agree with James that it's best not to split codebase across two version control systems, but sometimes we just end up in this type of situation.
How are you importing from TFS2005 to TFS2010?
This is an important question. TFS2010 does not have a way to import a single Team Project from one server to another. You can Import an entire TPC (Team Project Collection). I know of only two methods:
A) Seriously look at TIP (TFS Integration Platform). It's not perfect, but it is designed to do what you are looking for.
B) You can do a snapshot migration. Basically this means getting latest from VS2005, check in to VS2010 (wherever you want), then leave all prior history in VS2005.
If TIP doesn't work for you or is deemed too risky or missing critical info then find out if TFS2010 can import TFS2005 databases to migrate your TFS2005 Team Project Collection. If yes then make a copy of the TFS2005 Version Control databases, then import the entire Team Project Collection into TFS2010, then delete the other TFS2005 projects from this collection that aren't needed. You can call this your TFS2005 Archive Team Project Collection and keep the full fidelity version history on-hand if needed. I did a migration from TFS2008 to TFS2010 a couple times. It's non-trivial but doable.
Migration approaches:
Plan A: Migrate everything to TFS2010 and retire TFS2005 as soon as you can. You can archive 2005 or perhaps move it to a virtual machine if you feel it's essential to have available... but you really want to cut your admin work in half plus get 5 years worth of improvements by moving everything to TFS2010.
Plan B: Set up a system that allows you to integrate between the two servers until you can finally retire TFS2005. Stay in this situation only as long as absolutely necessary and upgrade whatever you need to unblock moving everything to TFS2010.
Q&A:
After we do the first import from TFS2005 to TFS2010 to TPC X, can we import after one week just the changes of the passed week?
A: It should be doable, but fidelity of import depends on how you are importing.
If you are doing a "snapshot migration" by checking in the latest version of VS2005 code into VS2010 then you can check out the first snapshot, repeat a new snapshot over the code, then merge the changes. The BIG drawback to snapshot migration process is that you lose all metadata in TFS2005 including change history, labels, checkin comments...
If you use TFS Integration Platform hopefully most content and metadata will transfer. The neat thing here is once you define the synchronization rules and run it once you can simply re-run the same migration with minor changes. Watch for how labels and changeset metadata gets transferred.
Can we do import (TFS2005 to TFS2010) to the same TPC X (already existing one) ?
TFS Integration
A: That shouldn't be a problem. TFS Integration Platform or checking in a "snapshot migration" can be targeted to any folder path. I assume there is no formal branch relationship established between the two codebases currently. Therefore I'd strongly recommend checking in the imported files into a separate folder, convert it to a branch (if not already done by import process), then establish whatever branching relationship makes sense to the existing TFS2010 project branch. If there is no shared code between these two projects then I'd keep their branches separated.
Can check in can be done automatic to 2 TFS servers?
A: That's the promise of TIP (the TFS Integration Platform). I personally had a rocky time trying to get it to migrate full source history from one TFS2010 Server to another, but big part of that problem was network issues traveling across 6,000+ miles and 3 firewalls.
Start by reading this blog and it's comments for a well balanced discussion of TIP and current limitations: TFS Integration Platform Updated (Mar ‘11)
Good Luck!
We're setting up a brand new TFS 2010 server, without having used TFS before (or, frighteningly enough, no other central source management system). Here's the general structure our small team (of 6-7 programmers) talked about setting up, and I'm curious, based on others experience working with TFS, if this is a good idea or not (these names are just descriptive and not what we're planning to use):
$/
Our Organization's Collection/
.Net technology projects/
class libraries projects/
Project 1/
Project 2/
Project 3/
etc.../
ASP.NET projects/
Project 1/
Project 2/
Project 3/
etc.../
Windows Workflow Foundation projects/
etc.../
WPF projects/
etc.../
Other non .NET source code/
SQL/
Server configuration/
(and so on)
Will we regret this structure after a year of using it? An application would span many parts of this structure - would that be a problem to manage?
At what level do we set up release/main/dev branches?
Thanks for any input and guidance!
Plan now. Branch when necessary.
With a team that has never managed branching/merging, I wholly recommend keeping everything as simple as possible to start (meaning, forget branching for the short term). After having recently converted our source from VSS to TFS2010 and implemented a Branch By Quality strategy for a team of a similar size with similar experience levels, my recommendation is this:
Do not implement a branching strategy until you need it. You can always branch once you determine it is necessary. Go ahead and bring the projects into TFS for source control and make sure everyone is comfortable with the software and the teamwork necessary to keep it stable.
In the meantime find members of the team who are interested and give them time to research, train, test, and practice on a parallel or simplified instance of your codebase. They will need practice creating projects, branching and merging in situations that mimic your deployment process; they will need time to communicate with the rest of the team to fine tune your processes and DOCUMENT them; they will need to be willing to be a resource to other members of the team as the learning curve flattens out. This way you have team members prepared and confident to step up and implement your chosen branching pattern.
You do not want to jump into a branching strategy before determining the need for it. There is a large amount of administrative overhead involved with plenty of perils.
With that said:
I don't think you will have any trouble managing what you have there once you start branching to accommodate a need. The key here is to make sure you don't over-architect this and complicate the management of your source/deployment. Also know that the structure of your TFS will be reflected in your local file system / workspace.
We created a separate Team Project for each independent solution or group of related reused libraries. In one case we grouped a set of highly dependent solutions together under a single Team Project - a large multi-application intranet portal that is deployed at once. Doing so allows us to keep deployment and source management simple. Here is a look at our branching structure for this one at a high level:
This is one large project with many sub-projects. Every branch is a complete copy (just the difference/versions are stored on the server). There are a large number of Team Projects above and below this one in the Collection and looks a lot like your list up top.
The final answer depends on the interdependency, structure, and deployment strategy of your applications. Do you have any specific concerns regarding your structure there?
In addition to #hangy's link, if its TFS 2010 your settingup then codeplex's Visual Studio TFS branching guide details the current wisdom for 2010.
Our .NET team works on projects for our company that fall into distinct categories. Some are internal web apps, some are external (publicly facing) web apps, we also have internal Windows applications for our corporate office users, and Windows Forms apps for our retail locations (stores). Of course, because we hate code reuse, we have a ton of code that is shared among the different applications. Currently we're using SVN as our source control, and we've got our repository laid out like this:
- = folder, | = Visual Studio Solution
-SVN
- Internet
| Ourcompany.com
| Oursecondcompany.com
- Intranet
| UniformOrdering website
| MessageCenter website
- Shared
| ErrorLoggingModule
| RegularExpressionGenerator
| Anti-Xss
| OrgChartModule etc...
So..
The OurCompany.com solution in the Internet folder would have a website project, and it would also include the ErrorLoggingModule, RegularExpressionGenerator, and Anti-Xss projects from the shared directory.
Similarly, our UniformOrdering website solution would have each of these projects included in the solution as well.
We prefer to have a project reference to a .dll reference because, first of all, if we need to add or fix a function in the ErrorLoggingModule while working on the OurCompany.com website, it's right there. Also, this allows us to build each solution and see if changes to shared code break any other applications. This should work well on a build server as well if I'm correct.
In SVN, there is no problem with this. SVN and Visual Studio aren't tied together in the way TFS's source control is. We never figured out how to work this type of structure in TFS when we were using it, because in TFS, the TFS project was always tied to a Visual Studio Solution. The Source Code repository was a child of the TFS Project, so if we wanted to do this, we had to duplicate the Shared code in each TFS project's source code repository. As my co-worker put it, this "breaks every known best practice about code reuse and simplicity". It was enough of a deal breaker for us that we switched to SVN.
Now, however, we're faced with truly fixing our development processes, and the Application Lifecycle Management of TFS is pretty close to exactly what we want, and how we want to work. Our one sticking point is the shared code issue.
We're evaluating other commercial and open source solutions, but since we're already paying for TFS with our MSDN Subscriptions, and TFS is pretty much exactly what we want, we'd REALLY like to find a way around this issue.
Has anybody else faced this and come up with a solution?
If you've seen an article or posting on this that you can share with me, that would help as well.
As always, I'm open to answers like "You're looking at it all wrong, bonehead, HERE'S the way it SHOULD be done.
I think there's some misunderstandings here. First, you can have multiple (as many as you want) solutions in a single TFS project. Also, a single Visual Studio project can have any number of solutions referring to it.
Second, what version of TFS are you using? 2010 is different from 2005/08 in how it handles TFS projects.
Under 2008, there are several ways to approach this depending on what you want to get out of it. You can either have multiple TFS projects or a single TFS project.
I'll start with multiple.
Set up a TFS project for your shared library type code, and others for each regular project you have. As part of the development process on this shared library, check in the completed assemblies. Then Branch those assemblies into any other TFS project you want to use them in. When you do a feature update or bug fix to the shared library, simply merge the branch into any other TFS project you want the updates to go into.
This allows you to make shared changes for a single app without having to push all of them.
If you want a single TFS project holding everything, just add folders for each Visual Studio project you want. The visual studio solutions can refer back to projects outside of their base tree without issue. Now, when configuring things like Builds for each solution, make sure you limit what directory the build server pulls from / watches. That way you don't have it building one of your internal sites when changes were made to an external site.
Only recording this in the hope that it helps someone else some day, I fear I'm a little too late to answer your original question ;)
We have a very similar situation, and your question (and subsequent answers) made it very easy for us to set up TFS properly.
To use your example to explain our setup:
# = Project Collection, > = Team Project, | = VS project
# SVN
> Internet
| OurCompany
| OurCompany2
> Intranet
| UniformOrdering
| MessageCentre
> Shared
| ErrorLogging
| RegularExpression
This means that work can be assigned (using Scrum templates in Sharepoint) to any of the Team Projects (which are SAAS apps in our case) and the developer can choose to open any or all of the VS Projects to get the job done.
The majority of the senior developers (those that are across multiple products) have one VS Solution (maybe "WholeEnterprise.sln" to continue the analogy) that contains ALL the different VS Projects and can therefore work on any/all of them at any one time. We can also ensure that projects build properly, and all the dependencies are up to date before pushing an update.
The structure of this in your operating system of choice is totally up to you! Some of us have replicated the structure of TFS, others have a totally flat hierarchy... This doesn't seem to make a difference at the end of the day.
We are using TFS 2008 for Web App dev. The WebApp is a large project, so we do not want every developer to see all the source code, which means lots of libraries or subapps need to be referenced.If I put all the libraries and subapps in one VS2008 Project or VS2008 Team Project, all the source codes will be exposed to each person.
Do I have to make the WebApp reference other Team Project to solve this problem? What is the best way doing so?
Consider each isolated section to be a project (in both the physical and management sense) as independent. Ship release from those shared components/projects and deliver them as binaries to be pulled into the others. You can use a the output from trunk or release branch builds of the shared components to deliver new "releases".
This affords you the option of full branching, work item, reporting etc for each logical project in your organization.
If you let someone be a contributor/developer on a project, then that individual has access to the entire project. If you want to keep someone out of the certain files, then that will need to be under its own TFS project. You would then reference the output assemblies from the parent project in the child project.