SVN을 잘못 사용하면 Mercurial이 정답입니까?

직장에서는 SVN을 사용하지만 이름 만 사용합니다. 우리는 분기하거나 병합하지 않습니다. 우리는 저장소의 사본 두 개를 보관합니다. 하나는 배포 할 때 복사되는 "태그"분기 역할을하며 버그 수정을 위해 보관하고 즉시 "이것은 최대한 빨리 실행되어야합니다"유형의 기능입니다. 한 복사본의 변경 사항을 다른 복사본 ( "트렁크")에 복사해야합니다. 리포지토리의 단일 폴더 내에 12 개의 프로젝트가 있지만 분리하지 않고 있습니다. 간단히 말해 우리가 SVN을 사용하는 유일한 것은 커밋 할 수 있다는 것입니다. 다른 모든 것은 수동으로 수행됩니다.

나는 Mercurial을 평가하고있다. 나는 과거에 Git을 사용했으며 (DVCS를 사용한 팀의 유일한 사람입니다) 머큐리얼을 빨리 집어 들고 있습니다. 나는 분기가 간단하고 합병이 훨씬 쉬우므로 머큐리얼을 팀의 나머지 팀에게 "더 나은 방법"으로 소개하는 것에 대해 토론하고 있습니다. 그들이 준비되면 지점. 우리는 SVN의 모든 이점을 얻을 것입니다 (그리고 SVN을 아무도 모르기 때문에 지금은 많은 이점을 얻지 못합니다). 우리는 망했다. 워크 플로는 조금 더 단순 해 보입니다. "커밋"은 로컬이고 "푸시"는 SVN의 커밋과 같습니다.

이것이 좋은 접근 방법입니까? 이 팀은 매우 유연하고 업무 품질을 개선하고 업무를보다 쉽게 ​​수행 할 수있는 모든 작업을 수행 할 것입니다. CIO는 SVN을 사용하지 않는 방법에 대해 언급했을 때 " 더 나은 것을 사용할 수 있습니까? " 그래서 그는 그것도 함께하고 있습니다.

예.

OP에서 "SVN"을 "Perforce"로 바꾸면 현재 작업을 시작할 때, 심지어 수동 변경 복사까지 내가 찾은 상황과 거의 비슷합니다. 우리는 2 년 동안 Mercurial을 사용하고 있으며 모든 사람들이 그것이 큰 변화라고 동의합니다.

우리는 QA에 믿을 수 없을 정도로 유용한 지원 사례별로 분기 및 병합 할 수 있는 능력이 있으며, 필요할 때마다 많은 수의 버리기 분기 및 리포지토리를 생성 할 수 있습니다. 클라우드 테스트 환경에 기능을 검증하십시오. 이는 라이브 배포를 수행 할 때 거의 100 % 확실 하게 작동 한다는 확신을 가지고 있습니다 (산세 환경 / DB 문제, 분명히 VCS 범위를 벗어남).

기본적으로, 우리가 수은으로 전환하면서 얻은 것은 호흡 공간입니다. 더 이상 지점 비용이나 필연적으로 따라가는 끔찍한 병합 세션에 대해 걱정할 필요가 없습니다. 모든 것이 훨씬 쉽습니다. 우리는 또한 FogBugz를 매우 많이 사용하므로 Kiln (호주 된 수은)과의 연계가 실제로 도움이됩니다.

hginit 사이트 에 대한 의견 도 실제로 작동하는 버전 제어 워크 플로의 개요로 사용됩니다 (회사의 특정 QA 워크 플로에 맞게 조정한다고 가정).

버전 관리를 이동하는 데있어 가능한 유일한 결함은 변경의 원동력이되고, 주제를 읽고 기꺼이 툴링을 최대한 활용하는 사람이 필요하다는 것입니다. 하다.

DCVS 사용 여부와 관련된 팀 규모 및 팀 배포에 대한 의견에 동의하지 않습니다. 실제로는 코드 배포에 관한 것입니다. 병렬로 여러 개발주기가 발생하는 경우, 레거시 시스템의 지원 사례 또는 여러 기능 또는 새로운 시스템 (소리에 따라)이 DVCS를 사용하면 도움이됩니다.

다른 도구로 문제를 해결하지 못할 수도 있습니다.이 기사를 읽어야한다고 말하면 가장 도움이됩니다.

http://thedailywtf.com/Articles/Source-Control-Done-Right.aspx

나는 기사의 요점이 여기에 요약되어 있다고 생각하지만 그것을 읽으십시오.

결국 : 실제로 도구에 대해 아님

다른 소스 제어 시스템을 다루고 통합하는 데 소비 한 모든 시간에 한 가지 결론을 얻었습니다. 도구가 아니라 사용 방법입니다. 그것은 끔찍한 해킹 진술이지만, 특히 여기에 해당됩니다. 빌드에 대한 레이블 지정, 예외에 의한 분기 등 소스 코드 변경을 올바르게 관리하는 데 사용되는 경우 가장 작은 소스 제어 시스템 (* cough * SourceSafe * cough *)조차도 여러 가지 우연한 커밋과 함께 Mercurial 설정을 훨씬 능가합니다. 푸시합니다.

아닙니다. 기술은 이런 종류의 문제를 거의 해결하지 못합니다.

Mercurial은 Subversion보다 더 복잡합니다 (예, 분기 및 병합이 더 좋고 아마도 더 쉬우나 Subversion의 모델은 Mercurial의 모델보다 훨씬 간단합니다). Subversion을 이러한 방식으로 사용하는 경우 Mercurial을 사용할 수 있습니다.

• a) 적절하거나 더 나은
• b) 부적절하지만 현재의 Subversion 사용보다 낫습니다.
• c) 지금처럼 부적절하게
• d) 지금보다 더 나쁘다

c)와 d) 가장 가능성이 높은 결과처럼 들린다. a) 또는 b)로 끝나는 이유를 적어 둡니다.

대규모 팀의 작동 방식에 대해서는 말할 수 없지만 소규모 팀의 경우 큰 SVN 문제는 실제로 SVN 문제가 아닙니다. 개발 문제입니다. 최신 개발 표준을 따르지 않는 경우 (가장 중요한 것은 지속적인 통합을 수행하는 경우) 버전 관리는 설명하고있는 정확한 혼란으로 바뀝니다. 새 시스템으로 뛰어 들기 전에 문제에 대한 근본 원인 분석을 수행해야합니다. ...

아니요. 도구는 방법론을 대체하지 않습니다.

당신이 경우 SCM으로 서브 버전을 사용하지 않는 , 당신은 할 수 도 의욕을 사용하지 않는 (그리고 대부분의 아마 일어날 것입니다)

SVN은 필요한 작업을 수행 할 수 있으며 의심스러운 보수를 위해 미드 스트림 말을 변경할 필요가 없습니다.

무엇을 하든지 신뢰 문제를 극복해야합니다. 누군가 자신의 작업 흐름을 바꾸도록 모든 사람을 설득 할 수 있어야합니다. 당신이 당신 편에 논리와 사실이 있더라도 최상의 상황에서도 쉽지 않습니다. 조직에서 가장 어려운 일 중 하나입니다. 당신이 그것을 찌르거나 거칠면 신뢰를 잃고 그 신뢰를 다시 얻기가 매우 어려울 것입니다.

사람들이 성공적으로 시도한 것을 알고있는 몇 가지가 있습니다. 아마도 그들 중 하나가 당신의 팀을 위해 일할 것입니다 :

1. 팀을위한 일련의 워크샵을 제공하기 위해 "코치"를 가져 오십시오. 이것은 아마도 외부인이되어야 할 것입니다. 그녀의 내용을 잘 알고 있으며 모든 수준의 이해력을 가진 사람들에게 효과적으로 이러한 기술을 가르치고 팀의 워크 플로에 새로운 VCS (*)를 적용하기위한 실용적인 계획을 세울 수있는 사람이어야합니다.

2. "skunk-works"프로젝트를 시작하여 소규모 프로젝트에서 새 VCS를 테스트하고 검증하십시오. 새로운 것을 시도하고 실패한 실험을 꾸미지 않아도되는 "알파"개발자를 선택하십시오. 스 unk 크 작업이 워크 플로우에서 CONCRETE의 반박 할 수없는 개선을 시연 할 수있을 때, 팀원에게 나머지 롤아웃을 시도하면 도움을 줄 수있는 몇 명의 전도자가 있습니다.

(*) "새로운 VCS"에 의해 반드시 수은 또는 자식을 의미하는 것은 아니며 SVN 일 수도 있습니다 (올바로 완료).