Is there an established “best practice” for handling external dependencies in TFS working branches? What I mean is, we have a project in TFS that contains common third-party libraries (in this case I’m specifically dealing with log4net), which we branch into our other projects as needed. Now we’re making a significant change that I’m doing on a separate working branch, which requires a newer version of the component. It looks basically like this:
$/ThirdParty
/bin
/log4net
$/Product
/Main
/thirdparty
/lognet <-- $/ThirdParty/bin/log4net
/Working1 <-- $/Product/Main
/thirdparty
/log4net <-- $/Product/Main/lognet <-- $/ThirdParty/bin/log4net
Part of the work requires rebuilding log4net against the .NET 4 client profile and bringing in the new version. Normally, when we upgrade a third party component, it’s checked into $/Thirdparty in the appropriate folder, then the individual projects are free to merge the latest binary, or not, as they see fit.
As far as I have can determine, in order to get the latest changeset from $/ThirdParty/bin/log4net I need to merge that into $/Product/Main, check the merge into TFS, then merge that branch into $/Product/Working1. That’s exactly what I want to avoid, because I don’t want to disrupt the main branch.
So, I guess two questions:
-
Is there a way to get this merge to work without having to check anything into the main branch?
-
Is there a better overall strategy for handling these kind of dependencies while still keeping them in TFS? (I know TFS isn’t “meant” for binaries, but we like it because of the easy multiple-version and history tracking we get out of it).
Answer to 1:
Yes. You can do a baseless merge from ThirdParty to Working1. Here’s the MSDN page:
http://msdn.microsoft.com/en-us/library/bb668976.aspx
As for 2:
If your Main project can use 2+ different versions of your 3rd party binary, then I recommend storing the separate versions of the 3rd party binary in the $/ThirdParty area and not having a direct link between files in the 3rd party area and the Main area.