<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Version-Control on Dr. Random</title><link>https://drrandom.org/tags/version-control/</link><description>Recent content in Version-Control on Dr. Random</description><generator>Hugo</generator><language>en-gb</language><lastBuildDate>Wed, 16 Nov 2011 06:53:00 +0000</lastBuildDate><atom:link href="https://drrandom.org/tags/version-control/index.xml" rel="self" type="application/rss+xml"/><item><title>Grappling with multiple remotes in git-tfs</title><link>https://drrandom.org/2011/11/16/grappling-with-multiple-remotes-in-git-tfs/</link><pubDate>Wed, 16 Nov 2011 06:53:00 +0000</pubDate><guid>https://drrandom.org/2011/11/16/grappling-with-multiple-remotes-in-git-tfs/</guid><description>&lt;p&gt;If you happen to be one of the many people in the unfortunate situation to be stuck working with TFS source control on a daily basis and gaze longingly at the folks using Git or Mercurial wishing you could have some of that distributed goodness for your very own self, I am here to tell you that all is not lost.  There are a couple ways you can work with a distributed version control system along side TFS and try and reduce the pain associated with TFS.  One way I wrote about here as an answer to a &lt;a href="http://stackoverflow.com/questions/2331636/real-world-use-of-mercurial-with-a-team-foundation-server/2351734#2351734"&gt;question on StackOverflow&lt;/a&gt;.  This technique worked fairly well for me dealing with a small codebase with only a few branches.  However, it became unmanageable once I started working in an environment which had a large TFS repo with several different branches that I needed to switch between on a regular basis.  You can read about some of the issues I ran into within the updated section of the answer, but overall things got messy quickly.&lt;/p&gt;</description></item></channel></rss>