Re: interfacing M$-TFS
- From
- Neal Kreitzinger <neal@rsss.com>
- Date
- Dec 7, 2010, 01:20 UTC
- Message-ID
- <idk26n$c5t$1@dough.gmane.org>
- In-Reply-To
- <20101203210139.GB14508@nibiru.local>
"Enrico Weigelt" <weigelt@metux.de> wrote in message news:20101203210139.GB14508@nibiru.local...
Show 45 quoted lines
> > Hi folks, > > > is there any way for directly interfacing M$-TFS (w/o its svn proxy) ? > > I'm currently working on an embedded linux project and my customer > has a company wide policy to put everything into - please put on > you intellectual seatbelt - M$ TFS. > > Needless to mention that TFS' VCS stuff is practically unusable, > but some collegues still committing directly to TFS (haven't > conviced them to switch over to git), and releases have to be > put there, as QA folks dont know anything else. > > My current workflow is: > > #1: a main branch, frequently copied over TFS manually (;-o) > #2: lots of topic branches which get rebased onto master > #3: finished topic branches are rebased to latest master and > then copied over to and committed in TFS > > Of course, that much manual work - especially with the need of > checking out / locking invidual files in TFS - really suxx and > wastes a lot of time. So I'm looking for way to: > > a) track remote branches from TFS > b) push back changes into a TFS remote tracking branch > > Both should be possible from Linux side, using the native protocol > (very unlikely that IT department can be convinced to install the > svn proxy for TFS). > > > > thx > -- > ---------------------------------------------------------------------- > Enrico Weigelt, metux IT service -- http://www.metux.de/ > > phone: +49 36207 519931 email: weigelt@metux.de > mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 > ---------------------------------------------------------------------- > Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme > ----------------------------------------------------------------------
I'm not familiar with TFS, but have you looked at the vendor-branch methodology described in the git-rm manpage? It seems like it could cover just about anything.
v/r, Neal