program tip

TFS 대 SVN

radiobox 2020. 12. 6. 21:26
반응형

TFS 대 SVN


프로젝트 (.NET)를 시작하려고하는데 TFS와 SVN 중에서 결정해야합니다.

나는 SVN (거북이 클라이언트 포함), CVS 및 VSS에 더 익숙합니다. TFS에는 SVN에서 사용할 수있는 모든 기능이 있습니까?

SVN에서 TFS로 전환 한 사람이 있습니까?
또한 TFS로 작업해야하는 경우 Visual Studio가 필요할 수 있습니다.

[편집]
우리가 이미 자리에 TFS에 대한 라이센스를 갖고 있기 때문에 돈은 고려하지 않습니다. TFS 대 SVN의 소스 제어 기능에 더 관심이 있습니다. 물론 다른 기능 목록도 환영합니다.


글쎄, 나에게 선택은 분명히 TFS입니다.

  • Visual Studio 로의 SVN 통합은 최소한 (IDE에서 많은 기능을 사용할 수 없음)과 약간 버그가 있지만 (AnkhSVN은 확실히 그렇습니다), TFS 하나는 완벽합니다 (이론적입니다 ...). SVN을 사용하여 (1 개월 동안) 전체 작업 영역이 여러 번 손상되었으며 TFS를 사용하지 않았습니다 (약 2 년).

  • 두 시스템의 소스 제어 관련 기능은 거의 동일하지만 TFS를 사용하여 IDE에서 직접 액세스 할 수 있지만 SVN을 사용하는 경우 TortoiseSVN 또는 기타 외부 도구 에 의존해야합니다 . 솔루션 탐색기 탭에서 몇 번의 클릭만으로 거의 모든 TFS 작업에 액세스 할 수 있습니다.

  • 복잡한 병합의 경우에도 TFS를 사용하면 병합이 훨씬 더 쉽습니다 (예를 들어 SVN은 .csproj 파일에 <<<<<< 및 >>>>>>>>>을 추가 하므로 필요합니다. 수동으로 편집하여 VS에서 다시 열 수 있습니다.)

나는 그 이유가 SVN보다 TFS를 선호하기에 충분하다고 생각하지만 다음과 같이 덧붙입니다.

  • TFS는 단순한 소스 제어 도구가 아닙니다 (작업 항목, 프로젝트 포털 등을 생각해보십시오).

    저는 과거에 중간 규모의 프로젝트 (코더 12 명, 테스터 3 명, 비즈니스 분석가 3 명)에서 사용했으며 TFS의 모든 작업 (버그 보고서, 프로젝트 문서, 빌드 프로세스)을 성공적으로 중앙 집중화 할 수있었습니다. 기타.)

    SVN 및 기타 타사 도구를 사용하여 동일한 작업을 수행 할 수 없다고 말하는 것은 아니지만 모든 것을 하나의 제품에 멋지게 통합하는 것이 좋습니다.


공정성을 유지하기 위해 다음은 TFS의 두 가지 명백한 단점입니다.

  • 가격

  • TFS를 설치하는 것은 매우 고통스럽고 SVN 설치는 몇 분이면 충분합니다.

    SqlServer 2008을 통해 TFS 2008을 설치하는 것은 매우 복잡하고 PDC 등에 TFS를 설치할 수 없습니다. 저에게는 분명히 Microsoft 제품으로 경험 한 최악의 설치 경험이었습니다.

    즉, 일단 설치되면 TFS는 사용하기가 매우 쉽습니다 (특히 소스 제어 시스템에 익숙하지 않은 코더의 경우).


현재 프로젝트에서는 SVN으로 시작하여 TFS로 빠르게 전환했습니다. 나는 행복하다.

내가 전환하기로 결정한 주된 이유는 분명히 SVN의 전반적인 버그 동작 때문입니다 ( VisualSVN 을 서버 로 사용 하고 AnkhSVN 을 클라이언트로 사용했습니다). 적어도 일주일에 한 번은 암호화 AnkhSVN 오류 메시지에 몇 시간을 소비했습니다.

지금까지 TFS 로의 전환을 후회할 단 하나의 이유를 찾지 못했습니다.


" 하나는 TFS와 SVN을 비교할 수 없습니다 "

SVN : 소스 코드 버전 관리 시스템입니다.
TFS : 버전 제어, 릴리스 관리, 요구 사항 추적, 문서 게시 및 기타 사항을 포함하는 완전한 소프트웨어 개발 관리 시스템입니다.

둘 다 VS2005에서 사용할 수있는 IDE 통합 추가 기능 (예 : AnkhSVN, Collabnet의 추가 기능)을 사용하는 것이 좋으므로 고려할 사항이 아닙니다.

선택을 위해 고려할 기준 :
-예산이 없거나 적은 프로젝트가있는 경우 SVN을 선택하십시오
.-버전 제어 시스템 만 찾고 있다면 SVN을 선택하고 , 완전한 개발 관리를 찾고 있다면 TFS를 선택하십시오.
적절한 개발 환경을 달성하기위한 통합 도구 (CruiseControl.Net, NUnit, NCover, FIT)는 SVN을 선택 하거나 이러한 모든 것을 즉시 구현할 수있는 방법을 찾고 있다면 TFS 를 선택하십시오.


TFS를 18 개월 전에 사용한 후 저는 버그가 많고 느리고 성가 시며 매우 제한된 검색 기준을 발견했으며 관심이없고 급여가 부족하고 일하는 기술 팀이 Sharepoint 및 기타를 사용하도록 강요당하는 팀에 의해 제품을 쫓아내는 느낌을 받았습니다. MS 기술은 마케팅이 원하는 것이기 때문입니다. 진심으로 그것은 개였습니다. 차라리 SourceSafe를 사용했을 것입니다!

반면 SVN은 약간 기술적이고 IDE 통합은 고통스럽고 때때로 혼란 스러울 수 있지만 사용자 기반이 방대하고 대부분의 문제는 빠른 SO 질문으로 해결할 수 있습니다.

Vault 를 고려해 보셨습니까 ? 잘 작동하고 너무 비싸지 않습니다.


2013 버전을 사용하고 Git 기반 리포지토리를 사용하는 경우에만 TFS를 권장합니다. 이전 버전에서 안정적이라고 생각하기에는 너무 많은 문제가 발생했습니다.

  • 한 번에 여러 파일을 diff 도구로 보내는 것은 불가능합니다. 이것은 병합하기 전에 변경 사항을 검토하고 사용할 수 없을 때 엄청나게 유용합니다.
  • 기능의 일관성없는 가용성. 일부 기능은 IDE 내에서만 사용할 수있는 반면 다른 부분은 Windows 탐색기에서만 사용할 수있는 반면 다른 기능은 명령 줄에서만 사용할 수 있습니다.
  • 버전 제어에 파일을 추가하는 것은 IDE에서 사용할 수 없으며 Windows 탐색기 통합에서만 사용할 수 있습니다.
  • 선반 세트에 액세스하는 것은 IDE 내에서만 사용할 수 있으며 Windows 탐색기 통합을 통해서는 사용할 수 없습니다.
  • 단일 통합 설치 프로그램이 없습니다. TFS를 설치하는 것만으로는 충분하지 않으며, 기본 기능을 얻으려면 팀 도구와 전동 도구도 설치해야합니다.
  • 선반 세트 기능은 병합되지 않습니다. 개인 브랜치를 수행하는 멋진 방법이 될 수 있었던 것은 본질적으로 코드가 오래되어 작동을 중지하도록 보장합니다.
  • Visual Studio 이외의 편집기를 사용해야하는 경우 텍스트 파일을 편집하기 전에 수동으로 잠금을 해제해야합니다.
  • 때때로 Visual Studio는 자체적으로 관리하고있는 파일의 잠금을 해제하는 것을 잊고 오류를 발생시킵니다.
  • 체크인 및 보류 UI는 파일 시스템에 실제로 존재하는 것이 아니라 TFS에 이미 추가 된 것을 커밋 할 수있는 파일을 기반으로합니다. 이렇게하면 파일을 놓치기가 매우 쉽습니다. (이것은 실제로 Visual Studio가 프로젝트 파일을 처리하는 방식의 문제이지만 그 자체로는 또 다른 폭언입니다).
  • 이전에 언급 한 문제로 인해 소스를 편집하기 위해 Microsoft가 아닌 도구를 사용하는 것이 불필요하게 어렵습니다.
  • TFS configuration is committed with your source. This means that if you change your TFS server the configuration for all your history is now incorrect. There is a default configuration you can use which overrides this behavior but it is not obvious.
  • No support for ignore filters at anything but the base level.
  • Inability to handle paths of greater than 249 characters.
  • Files that have been unlocked, but not edited show show up as changed, even though they haven't been. Differentiating between changed and unlocked would make it a lot easier for diffs, or better yet doing away with the entire broken unlocking system entirely.
  • Windows 탐색기 아이콘 오버레이는 파일이 편집되었는지 여부를 명확하게 표시하지 않습니다. TFS의 모든 파일에는 녹색 모서리가 있고 수정 된 파일은 아이콘 하단에 연필을 추가합니다. 수정을 위해 빨간색 모서리로 전환하면 아이콘의 거북이 시스템을 사용하거나보기가 훨씬 쉽습니다.
  • 이전 버전의 Visual Studio에는 최신 버전의 TFS와 통합하는 데 문제가 있습니다. 이것은 이제 소스 제어에 IDE 버전 종속성이 있음을 의미합니다.
  • 필요하지 않은 경우 기본적으로 사용자 솔루션 파일을 포함합니다. 물론 나는 이것이 선호의 문제 일 수 있음을 인정할 것이다.
  • 잘못된 캐싱은 로컬 복사본과 서버 간의 차이가 정확하게 반영되지 않을 수 있습니다. 최신 정보를 얻고 실제로 최신 정보가 없다는 사실을 알게되면 매우 실망 스럽습니다.

It's been 1.5 years now that I'm using SVN for various projects. Setups I've used so far:

  • AnkhSVN client for Visual Studio. It integrates nicely as Source Control provider since version 2.
  • Servers either CollabNet Subversion on windows or Apache 2.2 with SSL + SVN through DAV on linux.

Haven't had any problems with any of these setups and I definetly recommend using SVN as it's free and easy to start using. Also many project management / bug tracking packages integrate with SVN (like trac for instance).


I'd pick SVN. I've worked with SVN from a developer standpoint before and I currently work with TFS, and let me tell you that TFS is painful. While TFS is feature full and is more than just version control, its version control is sloppy at best. Merging is horrendous and many of us now turn to manual merging or merge tools because we can't rely on TFS. Files go missing, aren't downloaded to the local system sometimes, and there are just oddities in its behavior that make you want to bang your head against a desk.

That being said, if you want TFS in all its glory, are willing to work with its pain points, it is a great tool to setup automated builds, and releases.


Check out this article before you decide: A Comparison of TFS vs Subversion for Open Source Projects


I've used both - but actually, I've switched my main projects from TFS into SVN. I find the offline and anonymous access very valuable in my projects.

In general, I think they are comparable. I would just pick the one you know the best, and you are the happiest maintaining. I don't find the specific features in one dramatically outweight the features in the other system.


If you're familiar with svn I'd stick with it. Tfs isn't free and isn't simple. It does far more than just source control. If you're a .net shop like us and you're deciding what product to use for the whole dev cycle it's a contender, but for simple source control it's overkill.


I'd say TFS is more than just source control. If you can afford it, I would definitely advise to use it. When you start using Team Builds for example, or using stuff like Work Items, then you'll see that TFS can really manage your whole development life cycle, providing a rich environment in which reporting, ease of use, slick VS integration and solid source control are all rolled in to one.

It does require some iron on the server side. I do not find it to be slow however, it works nicely over VPN and supports offline work.

A major con is the install process (on the server side) which is tedious, non-flexible and in my mind (I come from a field in which packaging up apps and deployment are very important) a bad example of how SQL Server, Reporting Services, Sharepoint and webservices could be installed.


TFS can import from SVN, however SVN cannot import from TFS. So if you don’t find a good reason otherwise use SVN, as it is easier to change your mind later.

One of the best things about SVN is that every source code control system I know of can import from it, so choosing SVN us a very low risk option.


In my experience SVN overall is far quicker and more painless. I've used it with XCOPY deployment scripts that allow you to work and deploy far faster overall in comparison to TFS.


I don't have experience with TFS, but IDE integration is something you should think about. TFS obviously integrates very well with Visual Studio. AnkhSVN, the only usable free plugin for VS, is often problematic, even in the new versions. I haven't tried VisualSVN, though.


Consider that TFS 2010 can be installed also on Windows Vista / 7 client OSs and that it supports an express, three clicks, installation.


Pros:

  • Integration with Visual Studio. A real plus if you're leveraging a full Microsoft tech. stack for development.
  • Automated builds (though achievable via other products) is really nicely done. Continuous Integration and Gated check-in builds are fantastic IMO.

Cons:

  • Windows Workflow Foundation. For some reason, Windows Workflow Foundation was chosen as the method to customize many aspects of TFS. In short, you need a book on Windows Workflow to understand it, and I simply don't have the time. Very disappointing IMO.
  • Project Management. The concept of work items is simple enough I guess, but there's a lot of oddities with it that just leave me flummoxed. It's just way too complicated IMO. Coming from a Trac + SVN background, I much prefer Trac here. Again, just my opinion.

Failing to understand what the tools are capable of, their limitations, will mean you end up with a tool that doesn't work for what you want. Understand your requirements, and read the product manuals a bit - plenty of information available to determine suitability.

While I agree completely with the proponents for SVN, as it is a glorious tool (I've used it many times in university) , I've found TFS to generally be more cooperative in OOTB situations when you are using the SP1 Version with Studio 2010.

As well, there are some nice little plugins that make TFS a little more palatable for those of us who are used to, and generally prefer a SVN-type solution as well, and many of them have excellent support:

TeamReview for Code Reviewing is one example: http://teamreview.codeplex.com/ MS Pathways for multi-platform use of TFS: http://www.microsoft.com/pathways/teamprise/FAQ.htm

This SO Question is a great resources for TFS addons: What Add-Ons / Utilities are available for TFS?

A Word to the wise, as mentioned above, TFS can be a pain to be installed, so caution should be exercised. Following the route below, I've encountered minimal problems:

Studio 2008 -> Patching -> Studio 2010 -> Patching -> .NET -> SQL Server 2008RD/2012 -> Patching -> TFS -> Patching

참고URL : https://stackoverflow.com/questions/661389/tfs-vs-svn

반응형