여전히 Subversion을 사용하는 구체적인 이유는 무엇입니까? [닫은]


22

회사의 버전 관리 시스템을 선택하고 싶습니다. 지금까지 Git, Subversion 및 Mercurial이 있음을 알고 있습니다.

요즘에는 Git이 가장 많이 사용되는 것을 보았으므로 여전히 Subversion을 사용해야하는 특별한 이유가 있습니까? 아니면 Git으로 직접 가야합니까?


36
그들은 둘 다 작동합니다. 중요한 것은 그들이 우리에게 말하지 않은 요구 사항을 충족 시킬지 여부입니다.
Matthew Flynn


11
Mercurial을 어느 주장에서 제외합니까?
mouviciel

8
주관적인 (유혹 IMHO) 문구와 -1. Git이 가장 많이 사용되는 것을 볼 수 있습니다-인용이 필요합니다. Git은 오픈 소스 세계에서 매우 일반적이지만 회사 공간에서는 훨씬 드 rare니다. 군단은 중앙의 권위있는 단일 저장소에 대한 아이디어를 정말 좋아하며 변경 속도가 매우 느립니다. 회사 공간에서는 SVN보다 좋은 ole CVS를 볼 가능성이 더 높습니다. DVCS를 신경 쓰지 마십시오.
Keith

4
@RobinWinslow-SVN은 Git과 다릅니다. 일부 환경에 더 적합하고 다른 환경에 더 적합합니다. 개인적으로 나는 일반적으로 DVCS를 선호하고 당신은 분명히 Git을 선호하지만 둘 다 주관적인 의견입니다. 그들은 가치가 없지만 그런 사이트에는 속하지 않습니다.
키이스

답변:


46

SVN은 전혀 죽지 않았습니다. 그것은 여전히 ​​매우 광범위하게 사용되며 언제 어디서나 가지 않을 것입니다. SVN은 특히 분산 버전 제어 가 필요한 분산 프로젝트를 실행하지 않는 경우 분산 버전 제어보다 사용이 훨씬 간단합니다 .

중앙 저장소가 하나 뿐인 경우 (여전히 소스 제어없이 얻을 수있을 정도로 회사 규모가 작을 경우 회사에서 필요한 모든 것) SVN을 사용하여 상호 작용하는 것이 훨씬 간단합니다. 예를 들어 SVN을 사용하면 단일 작업으로 저장소에서 변경 사항을 가져 오거나 로컬 변경 사항을 커밋 할 수 있지만 HG와 Git은 동일한 작업을 수행하기 위해 2-3 단계가 필요합니다.

그리고 최근 개정으로 SVN은 사람들이 HG와 Git을 선호하게 만드는 많은 성능 문제를 해결했습니다. 몇 년 전보다 훨씬 빨라졌으며,이 시점에서 실제로 분산 버전 제어의 고급 기능이 필요하지 않으면 프로젝트의 HG 또는 Git을 살펴볼만한 이유가 없습니다.


16
나는 당신의 추정에 전적으로 동의하지는 않지만 SVN에 찬성하여 중요한 점 하나를 추가하고 싶습니다 : 업계의 많은 사람들이 SVN에 익숙하지만 Git을 편안하게 사용할 수있는 충분한 힘을 모릅니다. 전체 팀이 SVN에 익숙한 경우 Git으로 전환하면 상당한 비용이 발생할 수 있습니다. (물론 반대의 경우도 마찬가지입니다).
Joachim Sauer

8
내가 할 수 있다면 나는 수십 번 찬성 할 것이다. 많은 사람들이 유행을 겪고 있지만 왜 분산 소스 제어가 필요한지 생각하지 않습니다.
Euphoric September

21
@ 유포 릭 : 모든 프로젝트에서 항상 분산 소스 제어를 원하는 이유를 정확하게 알고 있습니다. 분기 및 병합을 단순하고 명확하며 신뢰할 수있게 만드는 중요한 부작용이 있습니다. 선택한 기본 모델이 단순히 더 복잡해지기 때문에 분기가있는 경우 코너링에서 Subversion이 여전히 멈춰 있습니다.
Jan Hudec

18
분산 버전 제어는 "페이드"가 아닙니다. 동시 버전 제어가 파일 잠금 패러다임에 대한 진화와 마찬가지로 소스 제어 의 진화 입니다.
JesperE

6
@ MichaelBorgwardt, 나는 실제로 여러 번 해냈습니다. subversion보다 훨씬 쉽습니다. 모든 것이 로컬에 있다는 사실은 "클라이언트"와 "서버"상호 작용을 설명 할 필요가 없습니다. git 또는 hg의 워크 플로우는 훨씬 자연스럽고 직관적입니다 (히스토리 편집과 같은 까다로운 부분을 피할 경우).
SK-logic

19

클라이언트 툴링은 아직 언급되지 않았습니다. 커맨드 라인 스크립트로 모든 것을 확실히 할 수는 있지만 GUI 통합을 통해 생산성을 크게 높일 수 있습니다.

우리는 주로 Visual Studio를 사용합니다. IDE에 통합하는 것은 현재 Git보다 SVN을 사용하는 것이 좋습니다. 향후에는 변경 될 수 있지만 버전 제어 기능만큼 결정에 영향을 미치게됩니다.

다른 모든 것과 마찬가지로, 버전 제어 시스템 자체도 목표가 아니라 어디로 가든지 확인할 수있는 도구입니다. 상황에 따라 가장 빨리 도착할 곳을 선택하십시오.


이것이 좋은 지적입니다. 사람들이 SVN보다 Git을 선호하는 이유 중 하나는 Git이 더 나은 CLI 도구이기 때문입니다. 그러나 이것은 Windows의 TortoiseSVN과 같은 좋은 타사 SVN GUI로 상쇄 될 수 있습니다.
행복감

2
이것이 Git을 통해 Mercurial (및 TortoiseHg)을 방문한 이유 중 하나입니다. 분산 버전 제어 적절한 툴링 및 IDE 통합 의 장점 .
HappyCat September

15

나는 힘내 팬이다. 최근 Git의 단점 중 하나는 svn의 릴리스 번호와 반대로 해시가있는 버전을 식별한다는 것입니다. 릴리스 번호는 전화 등으로 쉽게 전달할 수 있습니다.

그리고 그것은 내가 상상할 수있는 유일한 프로입니다. 이 기능에 정말로 의존하고 싶다면 분산 및 / 또는 중앙 집중식 VCS Bazaar 에서 사용할 수 있습니다 . Git에는 목적을 달성 할 수있는 태그가 있습니다.

어쨌든 나는 빠른 지점 전환과 숨김없이 개발을 상상할 수 없었습니다. 이 두 가지 기능만으로 SVN을 능가했습니다. 여기까지 동일한 목표를 달성하기 위해 전체 트리를 별도의 디렉토리로 만들고 체크 아웃 해야하는 동일한 작업을 기억합니다.

이른바 "분산 버전 제어의 고급 기능"에는 시간이 함께 제공되므로 처음부터 배울 필요가 없습니다. 그들을 두려워하지 마십시오. 그들은 방해하지 않기 위해 당신을 돕기 위해 여기 있습니다. 그리고 DVCS를위한 중앙 저장소를 설정하는 데 아무런 문제가 없습니다.


1
이것은 실제로 바보입니다 .git은 명확하게 해시 할 수있는 해시의 큰 부분 만 필요합니다. 일반적으로 ~ 6 문자로 충분합니다. 전체 해시가 아닙니다.
TC1

2
실제로는 git hash를 전달하지 않습니다. 일반적으로 6-7자인 해시의 고유 한 접두사를 사용할 수 있습니다.
JesperE

1
@JesperE : 예. 그러나 SVN 릴리스 번호는 시간이 지남에 따라 순차적으로 증가하지만 Git의 해시는 약어를 사용하더라도 무작위 일 수도 있습니다.
Keith Thompson

2

SVN을 사용하면 리포지토리의 일부를 폴더 수준으로 쉽게 체크 아웃 할 수 있지만 git을 사용하면 모든 기록을 포함하여 전체 리포지토리를 얻을 수 있습니다.

상황에 따라 SVN에 이점이있을 수 있습니다.

(또한 폴더 트리까지 숨겨진 ".svn"가비지와 같은 큰 단점이 있습니다.


3
참고 : v1.7 이후 .svn 가비지가 없습니다. 이제는 모두 단일 위치에 저장되었습니다.
gbjbaanb

이것은 정확하지 않습니다-git을 사용하면 기록없이 파일 만 체크 아웃 할 수 있으며 원하는 경우 리포지토리 단일 파일의 일부만 체크 아웃 할 수도 있습니다. svn보다 조금 더 복잡하지만 용량이 있습니다.
Benubird

2

"6 시간 동안 수행 할 수있는 작업이 있다면 6 시간이 걸리더라도 도구를 작성하는 것이 20 분 안에 작성하는 것이 더 낫습니다."

분산 버전 제어는 해결해야 할 다른 짐승입니다. 각 개발자마다 상당한 학습이 필요합니다. 각 개발자의 학습 프로세스를 수용 할 수있는 버퍼가있는 경우 적절한 분산 버전 제어 시스템으로 이동해야합니다. 학습 단계가 완료되면 분산 버전 제어가 중앙 집중식 버전 제어보다 훨씬 낫습니다.

분산 버전 제어는 최종적인 것으로 보입니다. 오랫동안 머무르는 것이 여기에 있습니다. 나중에 빨리 적응하는 것이 좋습니다. SVN이 새롭고 사람들이 CVS에 익숙해 졌을 때 SVN을 사용하지 않는다는 주장이 많이 있었지만 SVN이 가장 인기있는 버전 제어 시스템이 된 것과 같은 토론을 기억합니다.

회사가 기존 버전 제어 시스템에서 많은 소스 코드로 잘 설립 된 경우 새 시스템으로 이동하는 것은 큰 작업이지만 회사가 작거나 시작하는 경우 새 버전 제어로 이동하는 것은 매우 쉽습니다. 그러나 이전 버전 컨트롤 (새 설정)을 고수하면 나중에 버전 컨트롤 마이그레이션을 계획해야하는 병목 현상이 발생할 수 있습니다.

나는 많은 SVN 의견을 보았지만, 모두 "SVN이 더 낫다"보다는 "SVN이 나쁘지 않다"는 경향이있다. 따라서 프로젝트에 대해 분산 버전 제어 (예 : Git)를 선택하는 것이 좋습니다.

SVN에 비해 GIT의 장점 편집

  1. 전용 서버 불필요 실제로 두 서버 모두 서버 없이 사용할 수 있습니다.
  2. 네트워크 연결 없이도 개발을 계속할 수 있습니다.
  3. 지점 관리가 훨씬 쉽습니다.
  4. Bamboo와 같은 CI 도구의 향상된 지원

누군가가 SVN을 고수하는 이유로 툴링 (Visual Studio 용)을 언급했습니다. http://gitscc.codeplex.com/ 은 Visual Studio에 대한 GIT 지원을 제공합니다.


6
SVN Git 또는 Hg보다 이진 파일을 더 잘 처리 합니다 .
가짜 이름

2
"향후 버전 제어 마이그레이션을 계획해야하는 병목 현상이 발생할 수 있습니다." 이 접근 방식으로 인해 필요한 것보다 복잡하게 만드는 많은 프로젝트를 수행했으며 프로젝트가 미래의 이점을 활용하기 오래 전에 취소되었습니다. 때때로 충분하고 충분합니다. YAGNI를 고수하고 오늘 업무를 수행하십시오. 나중에 마이그레이션에 대해 걱정할 시간이 충분합니다. 최소한 여전히 프로젝트가 있습니다.
njr101 September

2
Once the learning phase is over Distributed Version Control is much better than Centralized Version Control.나는 이것에 완전히 동의하지 않습니다. 상황에 따라 인식되는 이점이있을 수 있지만 svn의 사람이 읽을 수있는 버전 번호만큼 간단한 것은 많은 조직에서 큰 이점입니다.
TZHX

1
@apeirogon-모든 것은 저장소에 넣을 내용에 달려 있습니다. 내가 작업하는 주요 리포지토리 중 하나의 HEAD 만 11.1GB입니다. Git / bzr / hg 리포지토리에 있으면 100GB 이상이 필요할 것입니다.
가짜 이름

1
물론 이것은 특정 저장소가 PCB 파일과 3D 모델로 가득 차 있기 때문입니다. PCB 파일과 3D 모델은 모두 이진 형식이며 공간 효율적이지 않습니다. 여기에 권장 사항 (예 : PCB ddesign 파일을 저장하는 사람들을위한 Electronics.SE)은 소스 코드를 저장하는 사람과는 매우 다릅니다.
가짜 이름

1

그 당시 Subversion을 사용해야 할 특별한 이유가 있습니까?

IDE에서의 툴링 지원과는 별개로 (필자는 사용하지 않음) – 실제로는 아닙니다. 물론 SVN이 더 친숙 할 수도 있지만 이것이 유일한 이유에 대한 것이므로 Hg와 Git을 배우는 것이 매우 쉽고 빠릅니다.

그렇습니다. 브랜치가 힐버트 공간의 하위 매니 폴드를 매핑하는 동종 이형 endofunctors라는 것을 이해하면 Git이 얼마나 사소한지를 설명하는 모든 복잡한 가이드가 있습니다. 1

나는 그것을 이해하지 못한다. 그러나 당신은 무엇을 알고 있습니까? 중요하지 않습니다. Git을 사용하기 위해 그 어떤 것도 알 필요가 없습니다.

대부분의 경우 Git과 Hg는 사용하기 쉽고 SVN보다 확실한 이점이 있습니다. 방 안에있는 코끼리는 물론 가지가 있습니다 : 가지들은 Git과 Hg에서 작동합니다. 대조적으로, SVN에서는 그것들이 기껏해야 고통스럽고 최악의 경우에는 여러 머리를 병합합니다.

물론 SVN을 계속 사용할 있습니다. 여전히 Windows XP를 사용할 수도 있습니다. 그러나 두 가지를 모두 시도한 대부분의 사용자는 대안 중 하나가 상당히 우수하다는 데 동의합니다.


1 네, 농담입니다. 내 생각에


Hilbert 공간의 하위 매니 폴드를 매핑하는 동종 이형 endofunctors가있는 Git 튜토리얼? 나는 그것을 읽어야한다! 그러나 이것은 하스켈 ( Endofunctor가 언급 한) 로 쓰여졌 고 양자 역학 (따라서 힐버트 우주 )에서 영감을 얻은 Darcs에는 적용되지 않습니까? 나는 Git과 HG가이 일들과 어떤 관계가 있는지 알 수 없다.
leftaroundabout

@leftaroundabout 농담입니다. 설명은 정확하지 않습니다 (내가 아는 한). “자신이 쉽게 알아 내면 git 브랜치는 쉽다”로 시작하는 많은 튜토리얼에 대한 리프입니다. 그리고 그 뒤에 복잡한 도메인 별 은유가 있습니다.
Konrad Rudolph

1
지나치게 복잡한 튜토리얼이 이유가 있다고 생각한 적이 있습니까? 그리고 어쨌든 무엇입니까? DVCS 관중이 분기에 대한 강박 관념을 이해 한 다음 모든 작은 일에 대해 지점을 다시 통합했습니다. 그것은 항상 문제를 찾는 해결책처럼 느껴집니다. SVN에서 브랜치를 다시 통합하는 것은 어렵습니다. 왜냐하면 그것이 처음에는 멍청하고 개념적으로 잘못된 일 이기 때문 입니다 . 그리고 "우리의 제품이 잘못된 일을 훨씬 쉽게 해냅니다." 매우 설득력이 있습니다.
메이슨 휠러

1
여러 변경 사항을 병렬로 작업하는 것은 약간 고통 스럽지만 다음 SVN 릴리스에 적합한 선반 이 있습니다. 대부분의 경우 동시에 여러 변경 작업을 수행하는 경우 (특히 일관되게 수행하는 경우) 이는 조직 수준에서 해결해야하는 더 큰 문제의 증거이며 새로운 기능으로는 사용할 수 없습니다. 도구. (위의 내용은 "우리 제품은 잘못된 일을 훨씬 쉽게 해줍니다."및 휴먼 타스크 전환에 대한 Joel의 고전 기사를 다시 참조하십시오.)
Mason Wheeler

3
@KonradRudolph 최신 버전의 SVN에서는 분기를 트렁크로 병합하는 것이 좋습니다. 몇 년 동안 현재 아주 좋은 곳으로 꾸준히 개선되고 있습니다.
Adam Bruss
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.