SVN 대Team Foundation Server [닫기]

https://stackoverflow.com/questions/4219

08-06-2019
|

문제

몇 달 전에 우리 팀은 소스 제어를 다음으로 전환했습니다. 아파치 서브버전 ~에서 Visual SourceSafe, 그리고 우리는 더 이상 행복하지 않았습니다.

최근에 내가보고있는 팀 파운데이션 서버, 그리고 적어도 표면적으로는 매우 인상적인 것 같습니다.Visual Studio와의 뛰어난 통합 기능과 DBA, 테스터, 프로젝트 관리자 등을 위한 훌륭한 도구가 많이 있습니다.

두 제품의 가장 눈에 띄는 차이점은 가격입니다.Apache Subversion(무료)을 이기는 것은 어렵습니다.Team Foundation Server는 상당히 비싸기 때문에 추가 기능을 사용하려면 Subversion을 아예 없애야 합니다.

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

해결책

저는 최근 CodePlex에서 오픈 소스 프로젝트에 참여했습니다.그들은 소스 제어를 위해 TFS를 사용하는데 이것이 정말 훌륭하다고 말하고 싶습니다.나는 지금까지 그것에 대해 믿을 수 없을 만큼 깊은 인상을 받았습니다.저는 IDE 통합과 코드 분기 및 태그 지정이 얼마나 쉬운지를 매우 좋아합니다.이미 모든 것이 올바르게 구성되어 있는 경우 소스 제어에 솔루션을 추가하는 것은 두 번의 클릭과 비슷합니다.

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

다른 팁

저에게 있어서 두 가지의 가장 큰 차이점은 다음과 같습니다. 저는 두 가지를 모두 사용했습니다.

1) TFS는 개발을 수행하는 "Visual Studio 방식"과 다소 밀접하게 결합되어 있습니다. 이는 TFS가 VS IDE와 긴밀하게 결합되어 있다는 의미는 아닙니다. 이는 TFS가 실제로 더 이상 적절한 모델이 아닌 경우에도 Visual SourceSafe의 친숙한 "체크인"/"체크아웃" 패러다임을 유지하기 위해 고군분투하고 있음을 의미합니다.Subversion의 "커밋"/"업데이트" 개념은 개발자가 네트워크 연결이 끊어진 상태에서 시간을 보낼 수 있는 경우 훨씬 더 현실적입니다.TFS는 개발자가 항상 서버에 연결되어 있을 것으로 기대합니다.그것은 큰 마이너스입니다.저는 개인적으로 TFS가 긴밀한 Visual Studio 통합으로 인해 서버와 로컬 디스크에서 파일이 구성되는 방식에 대해 투명하지 않다고 생각합니다.TFS를 더 적극적으로 지지하는 사람들도 연결된 체크인/체크아웃 모델이 연결되지 않은 채 작업하는 개발자에게 매력적인 옵션이 아니라는 점을 인정합니다.사람들이 SVN보다 git 및 Mercurial과 같은 DVCS 옵션을 보기 시작하는 환경에서 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 내부에서 스크립트를 작성하여 "확인"해야 한다고 누가 말했습니까?파괴 알고 있다 어떤 파일이 변경되었는지.거기에는 읽기 전용 잠금이 없습니다.
속도.TFS는 WAN에서 매우 느리며 업무용 컴퓨터에 VPN을 연결하는 경우에만 실제로 사용할 수 있으므로 전반적으로 개발 환경이 매우 느려집니다.
좋은 명령줄과 탐색기 통합이 부족합니다.IDE 통합은 일상적인 최신 가져오기, 파일 추가 및 체크인에 정말 유용하지만 여러 프로젝트에 걸쳐 작업을 수행해야 하는 경우에는 원하는 대로 사용할 수 있는 좋은 도구를 사용하는 것이 좋습니다.그리고 누군가가 tf.exe가 잘 작동한다고 주장하기 전에...실제로는 cmd 라인 도구가 아닙니다.예를 들어 코드를 체크인해도 모달 대화 상자가 표시되어서는 안 됩니다.

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

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

버그질라 문제 추적을 위해
아파치 서브버전 소스 코드 저장소 백엔드로
VisualSVN 서버 서버에서 SVN을 관리하기 위해
거북이SVN (Windows 탐색기에서) 및 안크SVN 또는 VisualSVN (Visual Studio에서) 클라이언트에서
CruiseControl.NET 자동화된 빌드용

비용:$ 0 혜택 :아주 재미있는

소규모 팀이거나 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는 버전 제어 제품이 아닙니다.버전 관리에만 사용할 목적으로 TFS를 구입하는 것은 확실히 돈 낭비입니다.TFS는 애플리케이션 수명주기 관리의 모든 측면을 자동화하는 통합 도구 모음입니다(그리고 "엔터프라이즈"에 거의 맞춰져 있음).

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

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

TFS는 성능상의 이유로(최신 버전을 더 빠르게 가져오기) 및 프로젝트 관리(어떤 개발자가 파일을 체크아웃했는지, 체크아웃 기간이 얼마나 되는지 확인하고 싶습니다)로 인해 서버에서 체크아웃한 사용자를 추적합니다.

저는 SVN에 대해 잘 알지 못합니다(사용해본 적이 없습니다). 따라서 "TFS에서는 병합이 더 나쁘다"고 언급할 수 없습니다. 그리고 Ben S가 보고한 병합 버그에 부딪히지도 않았습니다. 하지만 저는 매우 훌륭했습니다. TFS를 사용하여 분기 및 병합에 성공했습니다.

내가 아는 한 가지 사용 사례는 정기적으로 "오프라인" 상태인 사용자를 위한 것입니다.TFS는 사용자가 대부분의 시간 동안 연결되어 있다고 가정하는 "서버 제품"입니다.2008년 릴리스에서는 오프라인 경험이 향상되었지만(2005년에는 실망스러웠습니다) 아직 갈 길이 멉니다.장기간 네트워크 연결을 자주 끊어야 하는(또는 원하는) 개발자가 있는 경우 SVN을 사용하는 것이 더 나을 것입니다.

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

또한 명령줄이 부족하다는 의견이 저를 놀라게 했습니다. 명령줄 도구는 광범위합니다(많은 경우 별도의 다운로드가 필요하지만). TFS 전동 공구

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

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

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

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

마지막으로 팀 탐색기(클라이언트)는 무려 400MB이며, TFS 서버에는 SharePoint가 필요하며 설치하는 데 이틀이 걸립니다.Subversion 원클릭 설치 프로그램은 대략 30MB이며 1분 이내에 서버를 설치합니다.TFS에는 많은 기능이 있지만 그 기반이 너무 불안정해서 결코 사용하거나 신경 쓰지 않을 것입니다.TFS는 라이센스 측면에서 비용이 많이 들고 개발자는 코드를 작성하는 대신 stackoverflow에 대해 불평을 낭비하게 됩니다. P

제가 추천하는 팀 시스템은 돈을 들일 가치가 없습니다.나는 둘 다 사용해왔고 Team System을 사용한 후에 비슷한 대체품을 찾으려고 노력했습니다.기본적으로 귀하가 지불하는 비용은 통합이고 사용자 정의 지원에 대해 논쟁할 수도 있지만 저는 약간의 시간과 통합 도구를 사용하여 팀 시스템 대체품을 만들 수 있었습니다.

나는 최근에 질문을 했다 팀 시스템 대안을 마련하기 위해 다른 사람들이 수행한 작업에 대해 알아보세요.또한 대체 도구를 만드는 데 사용한 개발 도구도 나열합니다.이 답변과 제가 물어본 질문을 통해 자신에게 맞는 것이 무엇인지 찾을 수 있기를 바랍니다.

나는 팀 시스템을 싫어하는 사람이 아닙니다. 단지 돈을 들일 가치가 없다고 생각합니다.그것은 매우 좋은 도구이며, 가격을 지불하는 것이 마음에 들지 않는다면 꼭 사용하십시오.제가 대체품을 만든 이유는 바로 이것이었습니다.저는 Team System이 제공하는 기능을 원했습니다.

다음은 VisualSVN의 오픈 소스 버전입니다. 앙크스븐.이제 collabnet이 인수했으니 훨씬 나아졌습니다.

필요한 것이 소스 제어뿐이라면 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에서는 문제가 발생할 수 없으며 이것이 바로 그 이유입니다.

VisualSVN 서버 이는 관리할 수 있는 멋진 플러그인이 포함된 전체 SVN 서버입니다.이를 통해 UI를 통해 Windows 인증을 바로 사용할 수 있습니다.쉬운.
남생이 거북이라고 해도 과언이 아닙니다.
앙크스빈 훌륭한 SCC 플러그인입니다.완전한 VS IDE 통합을 원하는 경우 최신 버전은 전체 SCC 플러그인입니다.이제 완전한 통합이 무료로 제공됩니다.

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

TFS는 단지 소스 제어에 관한 것이 아닙니다.TFS가 제공하는 전체 패키지, 버그 추적, 빌드, 보고 등을 사용한다면 TFS는 매우 확실한 선택입니다(확실히 Rational보다 낫습니다).TFS는 Active Directory와도 잘 통합됩니다.

SCM에 대해서만 이야기한다면 SubVersion을 선호합니다.저는 IDE 통합을 별로 좋아하지 않습니다.나는 또한 SVN의 트렁크/태그/브랜치 구조 규칙과 브랜치 간 전환이 상대적으로 쉽다는 점을 좋아합니다.하지만 TFS에서는 병합이 더 쉬워 보였습니다.Tortoise의 UI는 특히 저장소에 파일을 추가하는 것과 관련하여 TFS보다 뛰어납니다.

나는 그것이 정말로 당신의 필요에 달려 있다고 말하고 싶습니다.TFS는 매우 훌륭하고 광범위하게 사용했지만 엔터프라이즈 수준을 겨냥한 것이므로 이러한 기능이 모두 필요하지 않으면 필요하지 않을 수도 있습니다.이러한 기능(특히 분기, 확장성, 작업 항목 추적 등)이 필요한 경우에는 한 푼도 투자할 가치가 있습니다.TFS에는 버그 추적, 작업 항목 추적 및 소스 제어 이외의 기타 기능이 포함되어 있습니다.여러 개의 분기가 있거나 Subversion의 일부 기능 부족으로 인해 어려움을 겪고 있는 경우 전환하는 것이 좋습니다.그러나 전환해야 할 타당한 이유가 없다면 소스 제어 시스템 전환으로 인한 비용 및 생산성 저하를 피해야 합니다.

두 가지를 모두 광범위하게 사용하면서 Wedge는 "TFS에는 버그 추적, 작업 항목 추적 및 소스 제어 이상의 기타 기능이 포함되어 있습니다"라고 언급하면서 돈을 벌었다고 생각합니다.

그러나 SVN과 TFS는 확장성 측면에서 거의 동일해 보인다고 솔직하게 말할 수 있으며, SVN의 소스 제어는 본질적인 단순성으로 인해 TFS보다 우위에 있습니다.

소스 제어와 함께 작업 항목 및 버그 추적을 원할 경우 TFS를 사용하거나 SVN 및 bugzilla와 같은 기타 무료 도구를 사용합니다.TFS는 소스 제어와 작업 항목 추적을 모두 통합하지만 솔직히 MS는 수년 동안 VSS로 많은 개발자를 학대한 것에 대한 사과로 TFS를 무료로 제공했어야 했다고 생각합니다.

저는 SVN과 TFS를 모두 사용했습니다.TFS 사용의 주요 장점은 Visual Studio와의 긴밀한 통합입니다.버그 추적, 작업 추적이 모두 한 곳에서 이루어집니다.그리고 이러한 항목에 대해 생성된 보고서는 이해관계자가 프로젝트 상태를 지속적으로 파악하는 데 도움이 됩니다.

저는 5명이 함께 프로젝트를 진행하고 있는데 최근 SVN에서 TFS로 전환했습니다.전체 과정은 악몽이었습니다.XMLSpy에서 자동 생성된 코드가 있으며 TFS는 VS2008 외부에서 수정된 파일을 인식하지 못합니다.TFS Power Tools는 결제를 스캔하고 이 문제를 해결할 수 있지만 이러한 도구를 사용해야 한다는 점을 기억해야 한다는 것은 고통스러운 일입니다.우리가 끊임없이 직면하는 또 다른 문제는 TFS의 기본 병합 도구입니다.지금까지 사용해 본 병합 도구 중 최악입니다.TFS가 기본 솔루션 병합을 처리할 수 있을 것이라고 생각하지만 지금까지는 그렇지 않았습니다.

내장된 사용자 인터페이스는 매우 유용하지만 결함도 있습니다.솔루션 탐색기에서 체크아웃하면 추가된 파일이 체크아웃되지 않는 경우가 있습니다.Team Source Control 창에서 수행하면 완벽하게 작동합니다.왜 그런 겁니까?저는 VS2010에서 TFS에 대해 좋은 소식을 들었기 때문에 TFS를 기대하고 있으며 SVN은 완벽과는 거리가 멀지만 이러한 기능 중 일부는 좀 더 직관적으로 작동할 것으로 기대했습니다.

아담

TFS는 프로젝트 관리 및 추적에 적합하지만 소스 제어가 SVN만큼 좋지 않다고 생각합니다.TFS를 사용한 내 쇠고기는 다음과 같습니다.

체크인/체크아웃 모델

이는 TFS 소스 제어에 있어 큰 단점입니다.불행히도 VS는 원하지 않더라도 자동으로 항목을 체크아웃합니다.누군가가 일부 파일을 체크아웃한 후 휴가를 떠난 상황에 처해 있었습니다.제가 디렉토리 구조를 재구성하는 일을 맡았는데, 그 사람에게 파일이 잔뜩 체크아웃되어 있어서 할 수 없었습니다.GUI에는 체크아웃을 취소할 수 있는 방법이 없으므로 명령줄에서 하나씩 수행해야 했습니다.아니면 이를 위해 Power Shell 스크립트를 작성하는 방법을 알아내야 했습니다.

VS는 모든 것을 수행하는 데 필요합니다

가끔 텍스트 파일을 편집해서 체크인하고 싶을 때가 있습니다.이를 위해서는 파일을 편집하고 체크인하기 위해 엄청난 규모의 VS 2010을 시작해야 합니다.SVN에서는 몇 초가 걸렸던 일이 이제 나에게는 몇 분밖에 걸리지 않습니다.

다른 사람들이 지적했듯이 파일은 체크아웃되지 않은 경우 읽기 전용으로 표시됩니다.쓰기 가능하게 만들고 VS 외부에서 편집하면 TFS는 이를 인식하지 못합니다.이로 인해 VS 외부의 내용을 편집하는 것이 짜증납니다.이는 VS를 실행하고, 파일을 체크아웃하고, 다른 편집기에서 편집하고, VS에서 체크인하는 것을 의미합니다.

SVN에서는 쉬웠던 일부 작업이 이제는 고통스럽습니다.

아직 파악하지 못했을 수도 있지만 TFS에서는 변경 세트를 롤백하는 것이 매우 지루하다는 것을 알았습니다.
솔루션의 일부가 아닌 파일을 소스 제어에 추가하는 것은 엄청난 고통입니다.TFS 소스 제어 탐색기는 소스 제어에 있는 파일만 표시하고, 그렇지 않은 파일은 표시하지 않습니다(아마도 이에 대한 설정이 있을 수 있지만 잘 모르겠습니다).Tortoise SVN을 사용하면 폴더에서 Commit을 누르고 추가할 파일을 선택할 수 있습니다.

저는 현재 우리 회사에서 현재 사용하고 있는 Rational Suite와 비교하여 TFS를 평가하는 노력을 주도하고 있습니다.지금까지 TFS 2008은 클리어케이스 + 클리어퀘스트를 사용하고 있습니다.개발 환경 통합은 정말 빛나는 곳입니다.

내 10센트:

TFS2005는 설치하기가 어렵고 TFS2008을 유지하기가 어렵습니다. 설치자가 더 쉽고, 유지 보수가 간단하고, 자동화 된 빌드가 작동하기 쉽습니다.TFS2010은 정말 대단합니다!- 설치는 개 eassssyyy입니다.관리는 매우 쉽습니다.그것은 모두 멋지게 배치된 UI입니다.vs2008에서는 프로젝트를 생성할 수 없고 vs2010을 사용해야 하기 때문에 VS2008과 통합하는 것은 그리 쉽지 않습니다(어리석은 일입니다).TFS2010을 사용하면 TFS2008의 끔찍한 하위 폴더 대신 공유 포인트 프로젝트 위치를 변경할 수 있습니다.TFS2010에는 프로젝트 관리에 정말 유용한 번다운 차트와 같은 도구도 있습니다.TFS2010은 고객을 포함한 전체 생산팀을 위한 것 같습니다!그래도 여전히 비용이 너무 많이 듭니다 :(

또한 TFS에는 서버 하드웨어에서 훨씬 더 많은 성능이 필요하다는 점을 명심하십시오.물론 최소 하나의 Windows Server 라이선스도 필요합니다.

우리 회사가 따랐던 모범 사례는 2개의 서버를 사용하는 것입니다.프론트엔드(통합 공유포인트 포함), 백엔드에 전용 SQL Server(우리는 엔터프라이즈 클러스터 사용)가 있습니다.TFS는 1대의 컴퓨터에 설치할 수 있지만 설치해서는 안 됩니다.

이에 비해 우리의 svn 서버는 256MB RAM과 1개의 CPU를 갖춘 가상 Linux 서버에 설치되어 있으며 checkout-all과 같은 일반적인 작업을 수행할 때 여전히 몇 배 더 빠릅니다.가상 하드웨어는 vshpere가 할당할 수 있는 가장 낮은 수준이었습니다!하지만 디스크는 빠릅니다(SAN).

TFS에는 최소 $5000의 전용 하드웨어가 필요한 반면, svn 서버(Linux)는 현재 Windows 기반 OS에서는 더 이상 사용되지 않는 모든 하드웨어에서 실행될 수 있다고 제안합니다.

제 생각에는 프로젝트가 진행되는 상황과 환경에 따라 다릅니다.간단하고 작은 프로젝트가 있다면 SVN이 좋습니다.이미 쓴 것처럼 VisualSVN은 Visual Studio st에 훌륭하게 통합됩니다.기본 파일 시스템을 통해 체크인/체크아웃을 수행할 필요가 없습니다.

TFS는 버전 제어에 적합하지만 모든 기능을 실제로 사용한다면 더욱 좋습니다.내 눈에는 예를 들어 작업 항목을 고객 버그 보고서, 새로운 기능 요청을 처리하고 작업을 관리하여 예상 시간, 사용 시간 및 프로젝트 진행 상황을 추적하기 위한 통합 저장소로 사용하면 정말 가치가 있습니다. 남은 시간 표시.
또한 정말 흥미로운 점은 작업 항목을 소스 코드 체크인과 연결하는 기능을 사용하는 것입니다.보다 여기 이에 대한 자세한 내용은

우리는 SVN에서 TFS2010으로 마이그레이션하는 과정을 진행 중인 소규모 팀입니다.그렇게 하는 가장 큰 이유는 이제 TFS의 일부인 버그 추적을 위한 WebAccess와 Visual Studio의 통합입니다.

@아담:우리는 더 나은 경험을 할 수 있기를 바랍니다.아직은 알 수 없다...

저는 지난 3년 동안 SVN을 사용해 왔으며(이전에는 VSS에서 나옴) 최근에 TFS2010으로 전환해야 했습니다.전반적인 느낌은 SVN보다 버그가 많고 작업/버그와의 뛰어난 통합을 제외하면 SVN에 비해 우위에 있다고 생각하지 않습니다.속도도 SVN에 비해 다소 느린 것 같습니다.

지금 소스 컨트롤을 선택한다면 여전히 SVN을 선택할 것입니다.

도구 관련:-ANKHSVN Visual Studio Plugin은 TFS 소스 컨트롤만큼 좋습니다 - 거북이는 TFS 대응보다 훨씬 좋습니다.

TFS는 개발자가 아닌 사람이 필요하지 않은 경우 오후 작업에 적합합니다.

우리 헬프데스크가 프로세스에 참여해야 하는데 제대로 진행되지 않았습니다.

또한 최소한 tfs 2005의 빌드 관리는 형편없으며 2008 sln에 비해 빌드할 수도 없습니다.저는 소스 제어 선택이 배포 선택에 영향을 미치는 것을 정말 좋아하지 않습니다. 이것이 바로 우리 팀이 svn shop이 아닌 이유입니다.

그 경우 단지 소스 제어를 기반으로 SVN을 사용하겠습니다.Visual Studio용 AnkhSVN 무료 추가 기능이 새 릴리스에서 크게 개선되었습니다.또한 SVN의 소스 코드를 얻을 수 있으며 문서도 훌륭합니다!그들은 변했다 몇 가지 신비한 것들 TFS 2010 소스 제어에서는 소스 코드가 없으면 문제 해결이 매우 어려울 수 있습니다.또한 문서를 작성하는 데 있어 MSDN 팀에 의존하고 있으며 그들은 자신의 일정과 깊이에 따라 작업을 수행합니다.

그러고보니, TFS는 분명히 소스 제어 이상의 기능을 제공합니다..이것은 ALM 도구.이를 작업 항목, 보고, 자동화된 빌드와 결합하여 게이트 체크인, 자동화된 테스트 등서로 다른 도구를 SVN과 연결해야만 얻을 수 있는 매우 풍부한 가치를 제공할 수 있습니다.물론, SVN용 소스가 있다고 해서 안전한 것은 아닙니다.나는 SVN을 사용하여 무슨 일이 일어나고 있는지 완전히 파악하는 데 몇 주가 걸리는 시나리오에 들어갔습니다.

따라서 ALM 관점에서 살펴보고 회사에서 사용할 것인지 확인하는 것이 좋습니다. 모든 TFS 기능 또는 동종 최고의 전략을 사용하려고 합니다(예:지라).

1마일 단위로 TFS.

SVN의 파일 기반 접근 방식을 사용하면 실수로 너무 많은 문제가 발생합니다.내가 경험한 소스 제어 문제:TFS - 2 년 동안의 0 문제 SVN - 손실 수 ...

예, 저는 TFS 가격이 대부분의 회사에 영향을 미친다는 것을 알고 있습니다. 이는 매우 부끄러운 일입니다.MS가 합리적인 가격 모델을 가지고 있다면 훨씬 더 많은 시장 점유율(및 이익)을 가질 수 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow