tfs2010 - TFS 2010: How to handle external "branched-in" dependencies on working branches -
is there established "best practice" handling external dependencies in tfs working branches? mean is, have project in tfs contains common third-party libraries (in case i'm dealing log4net), branch our other projects needed. we're making significant change i'm doing on separate working branch, requires newer version of component. looks this:
$/thirdparty /bin /log4net $/product /main /thirdparty /lognet <-- $/thirdparty/bin/log4net /working1 <-- $/product/main /thirdparty /log4net <-- $/product/main/lognet <-- $/thirdparty/bin/log4net
part of work requires rebuilding log4net against .net 4 client profile , bringing in new version. normally, when upgrade third party component, it's checked $/thirdparty
in appropriate folder, individual projects free merge latest binary, or not, see fit.
as far have can determine, in order latest changeset $/thirdparty/bin/log4net
need merge $/product/main
, check merge tfs, merge branch $/product/working1
. that's want avoid, because don't want disrupt main branch.
so, guess 2 questions:
is there way merge work without having check main branch?
is there better overall strategy handling these kind of dependencies while still keeping them in tfs? (i know tfs isn't "meant" binaries, because of easy multiple-version , history tracking out of it).
answer 1:
yes. can baseless merge thirdparty working1. here's msdn page:
http://msdn.microsoft.com/en-us/library/bb668976.aspx
as 2: if main project can use 2+ different versions of 3rd party binary, recommend storing separate versions of 3rd party binary in $/thirdparty area , not having direct link between files in 3rd party area , main area.
Comments
Post a Comment