SVN 대 Team Foundation Server

SVN 대 Team Foundation Server

---

몇 달 전에 우리 팀은 소스 제어 를 Visual SourceSafe 에서 Apache Subversion으로 전환했지만 우리는 더 이상 행복하지 않았습니다.

최근에 Team Foundation Server를 살펴 보았는데 적어도 표면적으로는 매우 인상적입니다. Visual Studio와의 훌륭한 통합 및 DBA, 테스터, 프로젝트 관리자 등을위한 훌륭한 도구가 많이 있습니다.

이 두 제품의 가장 분명한 차이점은 가격입니다. Apache Subversion (무료)을이기는 것은 어렵습니다. Team Foundation Server는 상당히 비싸기 때문에 추가 기능을 사용하려면 Subversion이 필요합니다.

• 누구든지 둘 다에 대해 실제 경험이 있습니까?
• 그들은 어떻게 비교합니까?
• Team Foundation Server는 실제로 비용의 가치가 있습니까?

---

최근에 CodePlex에서 오픈 소스 프로젝트에 참여했습니다. 그들은 소스 제어에 TFS를 사용하며 절대적으로 훌륭하다고 말해야합니다. 지금까지 매우 인상적입니다. 저는 IDE 통합의 열렬한 팬이며 코드를 분기하고 태그를 지정하는 것이 얼마나 쉬운 지 알고 있습니다. 소스 제어에 솔루션을 추가하는 것은 이미 모든 것을 올바르게 구성한 경우 두 번의 클릭과 같습니다.

지금. 엄청난 가격표의 가치가 있습니까? 나는 그렇게 생각하지 않는다. CodePlex에서 프로젝트 작업을 할 때의 이점은 나중에 어딘가에서 사용해야하는 경우 필요한 TFS를 경험할 수 있다는 것입니다. 소스 제어를위한 좋은 IDE 통합을 원한다면 VisualSVN 통합 패키지를 선택하세요. 동일한 기능 (비 도메인 컴퓨터 BTW에서 무료)을 많이 얻는 것은 훨씬 더 저렴한 투자입니다.

---

두 가지의 가장 큰 차이점은 다음과 같습니다. 두 가지를 모두 사용했습니다.

1) TFS는 개발을 수행하는 "Visual Studio 방식"과 다소 밀접하게 연결되어 있습니다.TFS가 VS IDE와 밀접하게 결합되어 있다는 것은 아닙니다. 이는 TFS가 더 이상 적절한 모델이 아닌 경우에도 Visual SourceSafe의 친숙한 "체크인"/ "체크 아웃"패러다임을 유지하는 데 어려움을 겪고 있음을 의미합니다. Subversion의 "커밋"/ "업데이트"개념은 네트워크 연결이 끊어진 시간을 소비하는 개발자가있을 때 훨씬 더 현실적입니다. TFS는 개발자가 항상 서버에 연결되기를 기대합니다. 그것은 큰 마이너스입니다. 저는 개인적으로 TFS가 긴밀한 Visual Studio 통합으로 인해 서버와 로컬 디스크에서 파일이 구성되는 방식에 대해 투명하지 않다는 것을 알게되었습니다. TFS의 더 큰 지지자들조차도 연결된 체크인 / 체크 아웃 모델이 연결이 끊어진 개발자에게 매력적인 옵션이 아니라는 점을 인정합니다.

2) 비용.TFS가 비싸지 않다고 말하는 사람들은 아마도 매우 작은 상점이거나 TFS의 라이선스 조건을 준수하지 않을 것입니다. 당신이하는 모든 일에 대한 클라이언트 액세스 라이센스가 필요합니다. 버그만 관리하는 관리자입니까? ~ $ 250 CAL이 필요합니다 (소매 TFS 라이선스에는 5 개가 포함되어 있습니다). 문제를보고하고 싶은 비즈니스 사용자입니까? $ 250 CAL. 개발자? $ 250 (MSDN이 포함 된 경우 제외). 서버? $ 500 (MSDN이있는 경우 포함). 물론 TFS 사본을 판매하는 사람은 작업 항목 추적이 추가 사용자에게 무료라고 말할 것입니다.하지만 이러한 추가 사용자는 자신이 만든 작업 항목 만 볼 수 있으며 전체 팀의 작업 항목은 볼 수 없습니다. 팀 중심의 민첩한 환경에서 너무 유용합니다. 이 모든 것은 중간 규모의 조직에서 합산되고 SVN 및 CruiseControl.net의 증분 비용과 같은 동급 최고의 제품이 $ 0 일 때 정당화하기 어렵습니다. (공정하게도 TFS에 대해서는 여전히정말 좋은 OSS 이슈 트래커)

3) 프로젝트 구조. 프로젝트 수가 적은 대규모 팀에서는 TFS가 잘 작동 할 것입니다. 사내에 소규모, 연결되지 않았거나 느슨하게 연결된 LOB (기간 업무) 앱이 많은 경우 TFS의 구조가 부담스러워 질 수 있습니다. 우선, 프로젝트 자체의 분류를 정의 할 수 없습니다. 프로젝트 내에서 "영역"을 설정할 수 있지만 모든 문제와 문서는 "프로젝트"의 기본 컨텍스트 내에서 함께 추적됩니다. 새로운 "프로젝트"를 만드는 것은 종종 시간이 많이 걸리고 작은 노력으로는 과잉입니다. 물론 SVN은 소스 코드 제어에만 초점을 맞추기 때문에 그런 종류의 것이 없습니다.하지만 좋은 소규모 프로젝트 유연성이 필요한 경우 SVN 및 다른 문제 추적 도구가 더 나은 선택 일 수 있습니다.

내 의견은 가치가 있습니다.

• 개발자가 거의 독점적으로 IDE 내에서 작업하는 Microsoft 상점에서 크고 예산이 잘 짜여진 프로젝트가있는 대규모 팀의 경우 TFS가 승자입니다. TFS는 또한 프로젝트에 정책을 중앙에서 시행해야하는 경우에도 유리합니다.

• 다양하고 소규모 프로젝트가 많거나 비용이 문제가되는 상점이 많은 소규모 팀이나 소스 제어에서 연결이 끊긴 개발자가있는 팀의 경우 SVN을 사용합니다.

---

과거에 Subversion을 사용한 적이있는 사람이 TFS 소스 제어를 원하거나 필요로한다는 것에 놀랐습니다.

TFS (2005)에 대한 나의 경험은 꽤 끔찍했습니다. 다양한 개발 요구 사항에 맞게 소스를 적절하게 구성하는 방법에 대한 모든 종류의 백서 및 지침을 읽었습니다.

메인 라인 개발이있는 트렁크, 변경 및 배포를 통합하는 통합 분기, 이전 릴리스를 추적하는 릴리스 분기가있는 간단한 상황은 매우 일반적이고 간단하지만 계속해서 문제가 발생하고 있습니다.

TFS의 주요 문제 :

• 병합은 전복에 비해 고통입니다.
• 수정되지 않은 버그가 있습니다. 2 년 동안 알려진 이름 변경 / 병합에 대한 문제가 발생했으며 2005 년에는 수정 사항이 릴리스되지 않습니다. 결국 분기를 "깨진"폴더로 옮기고 지금은 무시합니다.
• 파일에 읽기 전용 잠금을 설정하는 것은 마찰입니다. 배치 파일을 편집하고 TFS 내부에서 스크립트를 작성하여 "체크 아웃"해야한다고 누가 말합니까? Subversion 은 어떤 파일이 변경되었는지 알고 있습니다. 거기에는 읽기 전용 잠금이 없습니다.
• 속도. TFS는 WAN을 통해 속도가 느리며 업무용 컴퓨터에 VPN을 연결하는 경우에만 사용할 수 있으므로 전체적으로 개발 경험이 매우 느려집니다.
• 좋은 명령 줄 및 탐색기 통합이 없습니다. IDE 통합은 일상적인 Get-Latest, 파일 추가 및 체크인에 정말 좋지만 많은 프로젝트에서 작업을 수행해야 할 때 좋은 도구를 마음대로 사용하는 것이 좋습니다. 그리고 누군가가 tf.exe가 잘 작동한다고 주장하기 전에 목 아래로 뛰어 내리기 전에 실제로 cmd 라인 도구가 아닙니다. 예를 들어 코드를 체크인해도 모달 대화 상자가 표시되지 않아야합니다.

... 목록은 계속됩니다. 모든 통합에도 불구하고 훨씬 우수한 무료 대안이 있다고 생각합니다.

---

우리는 VS.NET 상점이며 다음을 구현했습니다.

1. 이슈 추적을위한 Bugzilla
2. 소스 코드 저장소 백엔드로서의 Apache Subversion
3. 서버 에서 SVN을 관리하기위한 VisualSVN Server
4. 클라이언트의 TortoiseSVN (Windows 탐색기) 및 AhnkSVN 또는 VisualSVN (Visual Studio)
5. 자동화 된 빌드를위한 CruiseControl.NET

비용 : $ 0 혜택 : 귀중한

소규모 팀이거나 who TFS 프로세스를 구매할 준비가되지 않은 경우 SVN 및 오픈 소스 도구를 사용하는 것이 좋습니다.

---

다른 사람들이 지적했듯이 TFS는 SVN이 프로젝트 관리 등의 형태로 제공하는 것보다 훨씬 더 많은 기능을 제공합니다. 두 가지를 모두 사용하고 TFS를 구현하는 데 매우 큰 회사와 협력 한 결과, 여기에 2 센트가 있습니다.

1) TFS 2005를 사용하는 경우 TFS 2008로 업그레이드하십시오. 감사합니다. TFS 2008에는 실행 가능하게 만드는 수많은 개선 사항이 있습니다.

2) Visual Studio에 살고 있고 IDE 통합을 원하면 TFS를 사용하십시오. 저는 SVN 통합을 사용했으며 거의 ​​항상 TortoiseSVN을 사용합니다.

3) 계정이 Windows 인증과 통합된다는 아이디어가 마음에 들면 TFS를 사용하십시오. 그 끝에서 관리 용이성이 좋습니다. SVN에 대한 갈고리가있을 수 있습니다. 저는 긍정적 인 것은 아니지만 GUI 기반 관리를 좋아한다면 TFS를 이길 수 없습니다.

4) 메트릭을 추적해야하거나 체크인 정책과 같은 것을 구현하는 더 쉬운 방법이있는 경우 TFS를 사용하십시오.

5) MSFT가 아니면 구현하지 않을 사람이 있다면 TFS를 사용하십시오.

6) .NET (Java 작업, Eclipse 등) 이상을 수행하는 경우 SVN을 사용하십시오. 예, TFS와 잘 작동하는 매우 좋은 제품 (Teamprise와 같은)이 있습니다. 그러나 다른 언어가 상점의 작은 부분이 아니라면 SVN을 고수하십시오.

그 외에는 두 SCM 기능이 거의 동일합니다. 둘 다 분기와 병합을 수행하고 둘 다 원자 체크인을 수행하며 이름 바꾸기와 이동을 모두 지원합니다. 분기 및 병합 개념을 시작하는 사람들에게는 소스 제어 탐색기에서 분기를 표시하는 것이 좋습니다.

TFS는 실제로 그렇게 비싸지 않습니다 (어쩌면 $ 1200?). SVN과 비교할 때 아마도 그렇습니다. 보고 서비스 및 SharePoint와의 통합은 좋지만 다시 말하지만이를 사용하지 않으면 문제가되지 않습니다.

내가 말하고 싶은 것은 TFS의 180 일 평가판을 다운로드하여 사용해 보는 것입니다. 평가판을 나란히 실행하십시오. 어떤 길을 가도 행복 할 것 같아요.

---

Ubiguchi가 지적했듯이 TFS는 버전 관리 제품이 아닙니다. Version Control에만 사용하려는 의도로 TFS를 구입하는 것은 분명히 돈 낭비 일 것입니다. TFS는 응용 프로그램 수명주기 관리의 모든 측면을 자동화하기위한 통합 도구 모음입니다 (그리고 "기업"에 적합합니다.

또한 Ben S의 게시물에 따라 잠금에 대한 귀하의 의견을 이해할 수 없습니다. 잠금은 TFS에서 전혀 필요하지 않습니다. 관리자는 VSS (일부 "현명하지 않은"고객이 요구하는 기능)처럼 작동하도록 TFS를 구성하여 "체크 아웃시 최신 정보 얻기"를 구성 할 수 있습니다.이 기능은 체크 아웃 잠금도 수행한다고 생각합니다.

그러나 "정상적인"TFS 사용을 통해 "체크 아웃"은 사용자에게 잠금 유형을 묻는 메시지를 표시하며 기본값은 "none"이어야합니다. 사용자는 체크 아웃 (또는 체크인 잠금)을 선택할 수 있지만 필수는 아닙니다. 자물쇠를 원하지 않으면 사용하지 마십시오.

TFS는 다양한 성능상의 이유로 서버에서 체크 아웃 한 사용자를 추적하고 (최신을 더 빨리 확인) 프로젝트 관리 (개발자가 파일을 체크 아웃 한 내용과 체크 아웃 시간이 얼마나되는지보고 싶습니다)을 추적합니다.

저는 SVN에 익숙하지 않습니다 (사용한 적이 없습니다). 그래서 "병합은 TFS와 함께 더 나쁘다"고 말할 수 없습니다. Ben S가보고 한 병합 버그를 건드리지 않았습니다.하지만 저는 훌륭했습니다. TFS를 사용한 분기 및 병합 성공.

TFS가 여전히 약하다는 것을 알고있는 한 가지 사용 사례는 정기적으로 "오프라인"인 사용자를위한 것입니다. TFS는 사용자가 대부분의 시간에 연결되어 있다고 가정하는 "서버 제품"입니다. 오프라인 환경은 2008 년 릴리스에서 개선되었지만 (2005 년에는 음울 했음) 아직 갈 길이 멉니 다. 오랜 시간 동안 자주 네트워크 연결이 끊어 져야하는 (또는 원하는) 개발자가 있다면 SVN을 사용하는 것이 좋습니다.

TFS를 사용하는 SVN 팬을 위해 고려해야 할 또 다른 기능 은 사용자가 TortiseSVN을 사용하여 TFS에 연결할 수 있도록하는 코드 플렉스 인 SVN 브리지 입니다. 나는 좋은 친구이자 동료가 그것을 광범위하게 사용하고 그것을 좋아합니다.

또한 명령 줄의 부족에 대한 의견은 저를 놀라게합니다. 명령 줄 도구는 광범위합니다 (많은 사람들이 TFS Power Tools를 별도로 다운로드해야하지만

나는 Ben의 의견이 분명히 "Microsoft V1.0"제품이었던 2005 릴리스의 평가판을 기반으로한다고 생각합니다. 이 제품은 현재 2.1 버전이며 곧 버전 3이 출시 될 예정입니다.

---

TFS는 가증 스럽습니다. 이 시점에서 TFS에 몇 가지 문제가 있기 때문에 SVN (백업용 Live Mesh 포함)을 사용하여 로컬 버전을 제어합니다. 가장 큰 문제는 TFS가 타임 스탬프를 사용하여 최신 버전이 있는지 기록하고 이러한 타임 스탬프를 서버에 저장한다는 것입니다. 로컬 사본을 삭제하고 TFS에서 최신 정보를 가져올 수 있으며 모든 파일이 최신 상태라고 표시됩니다. 올바른 버전의 파일이 있다는 보장을 제공하지 않는 어리석은 시스템입니다. 이로 인해 많은 성가심이 발생합니다.

• 파일이 편집되면 TFS에 알려야하므로 항상 서버에 연결되어 있어야합니다.
• IDE 외부에서 파일을 편집하면 TFS가 혼란스러워집니다. 또한 NTFS에서 모든 파일을 읽기 전용으로 설정합니다.

TFS는 병합을 지원하지만 실제로는 체크인 / 체크 아웃 시스템입니다. 파일을 편집하면 다른 개발자에게 잠겨있는 경우가 많습니다. 주위에 방법이 있지만 시스템이 너무 복잡해서 항상 문제가 발생합니다. 예를 들어, 개발자는 모든 파일에 대해 배타적 잠금을 설정하는 전체 솔루션을 확인하여 NTFS에서 읽기 전용으로 설정된 모든 파일을 처리 할 수 ​​있음을 발견했습니다. Subversion은 잠금을 획득하지 않는 체크 아웃 구문이 동일하기 때문에이 작업을 몇 번 수행했습니다.

마지막으로 Team Explorer (클라이언트)는 무려 400MB이고 TFS 서버에는 SharePoint와 설치에 이틀이 필요합니다. Subversion 원 클릭 설치 프로그램은 약 30MB이며 1 분 안에 서버를 설치합니다. TFS에는 많은 기능이 있지만 그 기반이 너무 흔들려서 사용하거나 신경 쓰지 않습니다. TFS는 라이센스 측면에서 비용이 많이 들고 개발자는 코드를 작성하는 대신 스택 오버플로에 낭비를 줄 것입니다.

---

내 추천, Team System은 그만한 가치가 없습니다. 나는 둘 다 사용했고 Team System을 사용한 후에 비슷한 대체품을 찾으려고 노력했습니다. 기본적으로 당신이 지불하는 것은 통합이고 당신은 사용자 정의 지원을 주장 할 수 있지만, 저는 약간의 시간과 함께 도구를 통합하는 Team System 대체품을 만들 수있었습니다.

최근 에 다른 사람들이 Team System 대안을 찾기 위해 무엇을했는지에 대한 질문을 했습니다. 대체물을 만드는 데 사용한 개발 도구도 나열합니다. 이 답변과 내가 물은 질문을 통해 무엇이 귀하에게 적합한 지 찾을 수 있기를 바랍니다.

나는 팀 시스템을 싫어하는 사람이 아니며, 그럴 가치가 없다고 생각합니다. 그것은 매우 좋은 도구이며 가격을 지불하는 데 신경 쓰지 않는다면 반드시 그것을 사용하십시오. 내가 생각해 낸 대체품을 만든 전체 이유였습니다. Team System이 제공하는 기능을 원했습니다.

---

다음은 Ankhsvn 이라는 VisualSVN의 오픈 소스 버전입니다 . 이제는 콜라 브넷이이를 인수했기 때문에 훨씬 나아졌습니다.

---

소스 제어 만 필요한 경우 TFS는 과잉입니다. 이전 고용주 중 한 명은 기업에서 TFS, VSS 및 Subversion을 사용했습니다. 기업에는 Active Directory 또는 Exchange Server 2003이 없었기 때문에 TFS 서버에 별도의 사용자를 만들어 개발자가 사용할 수 있도록했습니다. 우리는 Ben Schierman이 언급 한 것과 같은 종류의 병합 문제와 Subversion으로 우리를 밀어 붙이는 다른 버그가있었습니다.

TFS가 적합한 선택인지 여부는 부분적으로 예산, 개발 팀의 규모, 솔루션의 구성 / 유지 관리에 사용할 수있는 시간 및 인력에 따라 달라집니다. TFS가 제공하는 추가 문제 추적, 작업 항목 및 프로젝트 통계 기능을 원하는 경우 다른 대안을 살펴 보는 것이 좋습니다. JIRA (Atlassian Systems의) 또는 Trac과 같은 제품은 Subversion과 잘 통합되며 프로젝트 또는 프로그램 관리자가 저렴한 가격으로 관리 할 수있는 일종의 감독 기능을 제공합니다.

Active Directory, Exchange Server 2003 이상 및 리포지토리 전담 직원이있는 이상적인 환경에서는 TFS가 좋은 선택 일 가능성이 높습니다.

---

나는 직장과 집에서 모두 사용했습니다. 둘 다 그 자체로 매우 멋지다. TFS 사용을 권장하는 유일한 경우는 소스 제어보다 더 많은 기능을 사용하는 경우입니다. 필요한 모든 것이 소스 제어라면 SVN으로 잘못 갈 수 없으며 이것이 그 이유입니다.

1. VisualSVN 서버 그것은 그것을 관리하는 멋진 플러그인을 가진 완전한 SVN 서버입니다. UI를 통해 바로 Windows 인증을 사용할 수 있습니다. 쉬운.

2. 거북이 거북이, 충분히 말했다.

3. ankhsvn 훌륭한 SCC 플러그인입니다. 완전한 VS IDE 통합을 원하는 사람들을 위해 최신 버전은 완전한 SCC 플러그인입니다. 이제 무료로 완전 통합됩니다.

위의 설정은 100 % 무료이며 소스 제어에 필요한 모든 것을 제공합니다.

---

TFS isn't just about Source Control. If you use the whole package that TFS offers, bug tracking, builds, reports, etc then TFS is a pretty solid choice (certainly better than Rational). TFS also integrates well with Active Directory.

Though if you are just talking about SCM, then I prefer SubVersion. I don't really like IDE integration. I also like SVN's convention of Trunk/Tags/Branches structure, and relative ease of switching between branches. Merging seemed easier in TFS though. Tortoise's UI beats TFS's hands down though, especially in regards to adding a file to a repo.

---

I'd say it really depends on your needs. TFS is very nice, I've used it extensively, but it's very much aimed at the enterprise level, if you don't need all of those features it might not be necessary. If you do need those features (especially branching, scalability, work item tracking, etc.) they are worth every penny. Keep in mind that TFS includes bug tracking, work item tracking and other features beyond source control. If you have multiple branches or if you find yourself struggling against some lack of feature or other in Subversion then it might be a good idea to switch. But barring a good reason to switch you should probably avoid the cost and productivity hit of switching source control systems.

---

Having used both extensively, I think Wedge was on the money in noting "TFS includes bug tracking, work item tracking and other features beyond source control".

However, I can honestly say that SVN and TFS seem pretty equal in regards to scalability, and if anything SVN's source control has the edge on TFS due to its inherent simplicity.

If you want work-item and bug tracking alongside your source control then you either go for TFS or you go with SVN and some other, possibly free, tools such as bugzilla. While TFS does integrate both source control and work-item tracking together I honestly think MS should have given it away free as an apology for abusing so many developers with VSS over the years.

---

I have used both SVN and TFS. Main advantage of using TFS is its tight integration with Visual Studio. Bug Tracking, Task Tracking will all go in one place. And the reports generated for these items will help the stake holders keep informed of the project status.

---

I am working on a project with 5 people and we recently switched from SVN to TFS. The entire process has been a nightmare. We have auto generated code from XMLSpy, and TFS does not recognize files modified outside of VS2008. The TFS Power Tools can scan your checkout and fix this problem but it is a pain to have to remember to use these tools. Another problem we constantly run into is the default merging tool in TFS. It is by far the worst merging tool I have ever used. One would think that TFS would be able to handle basic solution merges but so far that has not been the case.

The built in user interface is very useful, but it also has flaws. If I checkout from my solution explorer, sometimes files are that have been added are not checked out. If I do it from the Team Source Control window it works perfectly. Why is that? I look forward to TFS in VS2010 as I have heard great things about it, and SVN is far from perfect, but I would have expected some of these features to function a little more intuitively.

Adam

---

TFS is great for project management and tracking, however I feel the source control is not as good as SVN. Here are my beefs with TFS:

Check-in/Check-out model

This is a huge con for TFS source control. Unfortunately, VS automatically checks out items for you, even if you don't want to. I've been in a situation where someone checked out some files and then went on vacation. I was in charge of restructuring the directory structure, but was unable to because a bunch of files were checked out to that person. There is no way in the GUI to undo the checkout, which meant it had to be done one by one in the command line. Or I had to figure out how to write a power shell script for this.

VS is required to do everything

Sometimes I want to edit a text file and check it in. This requires me to startup VS 2010, which is a huge beast, just to edit a file and check it in. Something that took a few seconds with SVN now takes me a minute.

As some others pointed out, files are marked read only if they are not checked out. If you make it writable and edit it outside of VS, TFS won't recognize this. This makes editing something outside of VS annoying. This means, firing up VS, checking out the file, editing it another editor, checking in in VS.

Some operations that were easy in SVN are now a pain

• Maybe I haven't figured it out yet, but I found that rolling back a changeset was very tedious with TFS.

• Adding files to source control, which are not part of a solution, is a huge pain. The TFS source control explorer only shows which files are in source control, not which ones are not (maybe there's a setting somewhere for this, I don't know). With Tortoise SVN, I could simply press Commit on a folder and select which files to add.

---

I am currently leading the effort to evaluate TFS at my company against the Rational Suite which is what we currently use. So far TFS 2008 is pwning clearcase + clearquest. The dev environment integration is where it really shines.

---

My 10 cents:

TFS2005 was a joke - hard to install and even harder to maintain TFS2008 was stable - easier to installer, simpler maintenance, and automated builds that work. TFS2010 is EPIC! - installation is dog eassssyyy. Management is very easy; it's all a nicely laid out UI. Integrating it with VS2008 isn't so easy since you can't create projects in vs2008 you have to use vs2010 (which is stupid). TFS2010 also allows you to change the sharepoint project location instead of having those awful subfolders of TFS2008. TFS2010 also has tools like a burndown chart that is really useful for project management. It's like TFS2010 is for the whole production team including the clients! It still costs way too much though :(

---

Also take in mind that TFS requires a LOT of more horsepowers from the server hardware. And at minimum one windows server licenses ofcourse.

Best practice, as our company followed, is to use 2 servers: front-end (with integrated sharepoint), and a dedicated sql server in the back-end (we use an enterprise cluster). TFS can be installed on 1 machine, but should not.

In comparation, our svn server is installed on a virtual linux server with 256mb ram and 1 cpu, and is still several magnitudes faster when doing common tasks like checkout-all. The virtual hardware was the lowest vshpere could assign! Disk is fast though (SAN).

I whould suggest that TFS requires dedicated hardware for atleast $5000, while svn server (on linux) can run with any hardware which is obsolete for current windows based os.

---

In my opinion it depends on the situation and environment in which the project is done. If you have just a simple, small project, then SVN is great. As already some wrote, VisualSVN integrates nicely into Visual Studio s.t. you don't have to do the checkin/checkout over the native file system.

TFS is great for version control, but even better if you really use all of it's capabilities. In my eyes it really becomes worth if you use - for instance - the work items as your integrated repository for handling customer bug reports, new feature requests and for tracking the progress of your project by managing tasks and the according estimated time, used time and remaining time indications.
What is also really interesting is to use the feature of associating work items with source code checkins. See here for more infos about that.

---

We are a small team in the process of migrating from SVN to TFS2010. Our biggest reason to do so is the integration in Visual Studio and the WebAccess for bugtracking, that is now part of the TFS.

@Adam: Hopefully we will have a better experience. Can not tell yet...

---

I've used SVN in the past 3 years (coming from VSS earlier) and recently had to switch to TFS2010. The overall feeling is that it is buggier than SVN and except for the nice integration with the tasks/bugs I don't see it as having an edge against SVN. The speed seems to also be somewhat slower than with SVN.

If I were to choose a sourcecontrol now I would still go with SVN.

Regarding tools: - AnkhSVN Visual Studio Plugin is as good as the TFS source control - Tortoise is a lot better than the TFS counterpart

---

TFS is great, if you don't need non-developers, to get to pm stuff.

Our helpdesk needs to be involved in the process, and it just wasn't cutting it.

Also the build management in tfs 2005 at least, is attrotious, and it can't even build vs 2008 slns. I really don't like that my source control choice, affects my deployment choices, this is why my team is not an svn shop.

---

If it just based on source control, I'd go with SVN. The AnkhSVN free add-in for Visual Studio has been greatly improved in its new release. Also, you get the source code for SVN and the documentation is great! They changed some arcane things in TFS 2010 Source Control, and without the source code it can be very daunting to troubleshoot. Plus, you are dependent on the MSDN team for pumping out the doc's and they do it on their own schedule and at their own depth.

That being said, TFS obviously offers much more than source control. It is an ALM tool. Combining it with work items, reporting, automated builds, gated check-in, automated testing, etc. can provide some very rich value that you can only get with connecting disparate tools with SVN. And of course, having the source for SVN is not a failsafe. I've gotten into scenarios with SVN where it would have still taken weeks to totally figure out what was going on.

So, I recommend you look at it from an ALM perspective and see if your company is going to use all of the TFS features or is going to with a best-of-breed strategy (e.g. JIRA).

---

TFS by a mile.

I inadvertently cause too many problems for myself with SVNs file-based approach. Source control problems ive experienced: TFS – 0 problems over 2 years SVN – lost count...

Yes I know the price of TFS factors it out for most companies which is such a shame. MS might have a lot more marketshare (and profit) if they had a reasonable pricing model.

참고URL : https://stackoverflow.com/questions/4219/svn-vs-team-foundation-server