# interfacing M$-TFS

2 messages from 2010-12-03 to 2010-12-07. Participants: Enrico Weigelt, Neal Kreitzinger.
Thread: https://gitlist.dev/t/25944

## Enrico Weigelt, 2010-12-03 21:01

Subject: interfacing M$-TFS
Message-ID: <20101203210139.GB14508@nibiru.local>
URL: https://gitlist.dev/e/20101203210139.GB14508%40nibiru.local

```

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
----------------------------------------------------------------------

```

## Neal Kreitzinger, 2010-12-07 01:20

Subject: Re: interfacing M$-TFS
Message-ID: <idk26n$c5t$1@dough.gmane.org>
URL: https://gitlist.dev/e/idk26n%24c5t%241%40dough.gmane.org
In-Reply-To: <20101203210139.GB14508@nibiru.local>

```

"Enrico Weigelt" <weigelt@metux.de> wrote in message 
news:20101203210139.GB14508@nibiru.local...
>
> 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 

```
