SVN의 스타일이 맞지 않습니까? [닫은]

Visual Source Safe에서 SVN으로 마이그레이션 한 지 몇 년이 지났습니다. 그리고 나를위한 SVN은 여전히 ​​"와우! 너무 많은 일을 할 수 있습니다! SVN은 정말 멋집니다!"

하지만 내 주변의 많은 사람들이 계속 "SVN? 정말? Meh ..."라고 말합니다.

그리고 내가 걱정되는 많은 것들이 있습니다. 팀을 Git / Mercurial 또는 다른 멋진 것으로 옮겨야합니까? 나는 말도 안되는 소리라는 것을 알고 있으며, 분명한 대답은 "당신에게 효과가있는 것들에 머 무르십시오"입니다. SVN은 나를 위해 일합니다 ...하지만 저장소에 새 프로젝트를 만들 때마다 계속 묻습니다. 이제 시간이 되었습니까?

SVN은 정말 그렇게 나쁩니 까? 그것을 고집함으로써 큰 ​​기회를 그리워합니까?

그것은 전적으로 사용법에 달려 있습니다.

한 방에 한 사람의 팀이 있고 그곳에서 대부분의 작업을 수행하는 경우, 이미 원하는 빌드 및 배포 프로세스가 있고 코드를 사람들과 광범위하게 공유하지 않으려는 경우 오픈 소스 프로젝트), 땀을 흘리지 않아야합니다.

1 년 전에 Subversion에서 git으로 전환했을 수 있습니다. Git은 대부분의 로컬 유스 케이스에도 완벽하게 적합하지만 실제로 빛나는 부분은 분산 개발입니다. 로컬로 사용하면 github을 원격 백업 및 코드에 대한 웹 인터페이스로 사용하는 것이 좋으며 계약자가 쉽게 참여할 수 있습니다. 그러나 Subversion에서 나오지 않았기 때문에 지금 당장 많이 나가지는 않습니다.

끊임없는 과대 광고에 휩쓸 리지 마십시오. 작동하는 무언가가 있습니다. 비즈니스 요구 사항이 다른 것보다 더 잘 충족 될 때까지 계속 사용하십시오. 현재 사용중인 것보다 더 나은 비즈니스 요구 사항을 충족합니다.)

SVN이 귀사를 위해 일한다면 다른 곳으로 이동하는 데 필요한 돈 / 시간 / 노력을 투자 할 이유가 없지만 새롭고 반짝이기 때문에 많은 사람들이 원합니다.

JBK가 생각하는대로 "팀"에 달려있는 결정이 아니라 모든 관심있는 당사자 (적어도 시스템 관리자 포함)와상의 한 후 관리에 달려있는 결정입니다. 기술적 결정이 아닌 기술 스택 변경에 돈을 쓰는 것은 사업상의 결정입니다.

나는 결코 무지에서 결정을 내려서는 안된다고 생각합니다. 당신이 무엇을 놓치고 있는지 모른다면, 당신이 할 때까지 길을 길게 시도해야하며, 정보에 근거한 결정을 내릴 수 있습니다. 분산 제어로의 도약은 시도하지 않고 실제로 이해하지 못하며, 수행하는 동안 오래된 습관을 버릴 수 없습니다. DVCS의 가장 큰 장점은 원하는 이유에 관계없이 원하는 수의 분기를 만들 수 있다는 것입니다. 한 달 동안 사용 해보고 5 개 이상의 지점을 만들지 않은 경우 자체 용어로 테스트하지 않았습니다. 이것은 자식을 "얻지"않는 대부분의 사람들의 실수입니다. 그 후, svn으로 돌아 가면 적어도 자신의 이유를 알게 될 것입니다.

나는 Git을 사용하지 않았지만 Mercurial을 사용했으며 실제로 큰 일이 무엇인지 알지 못합니다. 체크인 및 체크 아웃과 같은 기본 항목이 더 복잡하다는 점을 제외하고는 SVN과 매우 흡사합니다 (1 단계가 아닌 2 단계 필요). 그 대가로, 실제로 훨씬 더 간단하게 할 필요가 없었던 더 많은 고급 재료를 만들어야합니다. DVCS가 본질적으로 우수하다는 주장에 대한 저의 반응은 기본적으로 "좋아요, 당신의 말을 받아 들일 것입니다"라고 SVN을 계속합니다.

여기서 명백한 대답은 팀이 진공 상태에서 누군가가 샷을 호출하지 않도록 모든 사람에게 최고의 옵션이 무엇인지 결정하고 토론하게하는 것입니다. 해결해야 할 다양한 의견과 우려가있을 수 있지만, 무엇을 사용해야할지에 대한 독재적인 노력보다는 합의에 대한 답변을 제안하는 것이 좋습니다.