우리는 Subversion Geeks이며 Mercurial의 이점을 알고 싶습니다.

데 읽기 내가 의욕이나 힘내 또는 다른 DVCS을 고려 고려 여부를해야하는 이유 서브 버전 괴짜을 해요 .

관련 후속 질문이 있습니다. 나는 그 질문을 읽고 권장 링크와 비디오를 읽고 이점을 보았지만 사람들이 말하는 전반적인 사고 방식을 보지 못했습니다.

우리 팀은 60 개의 프로젝트로 구성된 하나의 큰 코드 기반에서 작업하는 8-10 명의 개발자로 구성되어 있습니다. 우리는 Subversion을 사용하고 주요 트렁크가 있습니다. 개발자가 새로운 Fogbugz 사례를 시작하면 svn 분기를 만들고 분기에서 작업을 수행하고 완료되면 트렁크로 다시 병합합니다. 때때로 그들은 오랜 기간 동안 지점에 머물러 있고 트렁크를 지점에 병합하여 변경 사항을 적용 할 수 있습니다.

Linus가 브랜치를 만드는 사람들에 대해 이야기하고 다시는하지 않는 것을 보았을 때 그것은 우리가 아닙니다. 우리는 아무 문제없이 일주일에 50-100 개의 지점을 만듭니다. 가장 큰 도전은 합병이지만 우리는 그것도 꽤 잘 해냈습니다. 나는 지점의 전체 루트가 아닌 fogbugz case & checkin으로 병합하는 경향이 있습니다.

우리는 원격으로 일하지 않으며 지점에서 지점을 만들지 않습니다. 코드베이스의 해당 섹션에서 작업하는 유일한 사람이라면 트렁크에 대한 병합이 원활하게 진행됩니다. 다른 사람이 동일한 코드 섹션을 수정 한 경우 병합이 지저분해질 수 있으며 일부 수술을 수행해야 할 수도 있습니다. 갈등은 갈등입니다. 코드를 이해하기에 충분히 똑똑하지 않은 한 어떤 시스템이 대부분의 시간에 어떻게 그것을 얻을 수 있는지 모르겠습니다.

브랜치를 생성 한 후 다음 60k + 파일 체크 아웃에 약간의 시간이 걸리지 만 사용하는 모든 소스 제어 시스템에 문제가됩니다.

우리가 보지 못했던 DVCS의 이점이 우리에게 큰 도움이 될 것입니까?

"DVCS를 중앙 집중식으로 만 사용하려는 경우 어떤 이점이 있습니까?" 그런 식으로 물어도 그렇지 않습니다. 작업 당 하나의 브랜치는 VCS에서 매우 일반적입니다. 당신이 그것에 대해 생각한다면, 하루 동안 트렁크와 독립적으로 변경되는 개발자 컴퓨터에 소스 코드의 로컬 작업 복사본을 갖는 것은 아무도 그것을 호출하지 않더라도 지점입니다. 그와 워크 플로의 유일한 차이점은 해당 지점에 중앙 서버에서도 영구적 인 이름을 부여한다는 것입니다. 그것은 리누스와 다른 사람들이 말하는 종류의 가지가 아닙니다.

DVCS를 이해하려면 근본적인 사고가 필요합니다. 당신은 당신이 원하는 누구에게나 공유 할 수있는 많은 지점으로 당신이 무엇을 할 것인지 스스로에게 물어봐야합니다. 여기에는 나만 볼 수있는 가지가 포함됩니다.

가능성은 끝이 없습니다. 예를 들어, 두 사람이 인터페이스의 반대편에서 일하는 것은 어떻습니까? 정기적으로 서로 코드를 공유해야하지만 아직 모든 사람과 공유 할만큼 안정적이지 않습니다. 그들은 공유 할 지점을 만든 다음 준비가되면 중앙 저장소로 다시 병합 할 수 있습니다.

중간 로컬 커밋을 수행하는 능력은 그 자체로 가치가 있습니다. 그것은 당신이 스스로 경험해야 할 것입니다.

귀하의 리포지토리를 현지에서 확보함으로써 얻은 속도 또한 그 자체로 가치가 있습니다. 예, 60k 파일 리포지토리의 경우 VCS에서 초기 클론이 불가피하게 느려질 것입니다. 그러나 일단 그런 후에는 DVCS를 사용하여 새 분기를 확인하는 것이 훨씬 빠릅니다.

특별한 경우 DVCS로 전환하면 이점이 없습니다. 기존 시스템에 만족하고 필요한 모든 작업을 수행하므로 전환해야하는 이유는 무엇입니까? SVN은 여전히 ​​활발한 오픈 소스 프로젝트이며 hg 또는 git보다 모든 주요 IDE 및 개발 도구와 더 잘 통합되어 있습니다. 팀 규모와 프로젝트 수를 고려할 때 기존 도구가 제대로 작동 할 때 새 도구로 변환하는 데 시간을 내고 싶습니까?

DVCS없이 작동 할 수없는 개발자가있는 경우 hg 또는 git의 svn 게이트웨이를 지정하십시오. svn 저장소에 대한 체크인은 나머지 팀에서 사용하는 모든 절차와 프로세스를 준수해야한다는 점을 분명히하십시오. 이 방법의 또 다른 장점은 게이트웨이를 이미 사용하고있는 진정한 DVCS 열성 자들이 이제 옷장에서 나올 수 있다는 것입니다.

많은 사람들이 DVCS 사용을 시작한 후에 채택한 워크 플로와 매우 유사한 워크 플로를 이미 사용하고있는 것 같습니다.

DVCS는 사용자의 관점에서 SVN에 비해 다음과 같은 중요한 이점을 제공합니다.

• 리포지토리를 복제하면 많은 작업을 로컬에서 수행 할 수 있습니다.
  • 저장소 로그를 보면 svn 서버를 건드릴 필요가 없으므로 매우 빠를 수 있습니다 .
  • 마찬가지로 스위칭 브랜치에는 서버에 대한 액세스가 필요하지 않으며 로컬 클론도 필요하지 않습니다.
• 브랜치는 히스토리를 통해 다양한 경로이므로 저장소는 모든 브랜치가 생성 한 모든 브랜치와 혼잡 하지 않습니다 (우리는 실제로 SVN에 릴리스 브랜치 만 있지만 branches디렉토리에는 더 이상 관련이없는 많은 하위 디렉토리가 있습니다).
  • git에서 브랜치가 다시 병합되고 참조가 삭제되면 해당 브랜치도 알 수 없습니다.
  • 의욕에서 당신의 선택의 여지가 중 (이 경우는 영구적으로 각각 변경 집합으로 인코딩 된) 지점의 이름을 지정하거나 조용히 것이다 무명 (위상) 지점 작성, 병합 이 때 역사를 merge에 D 다시 default( trunk)
• SVN에서 가지의 가지가 너무 모호하여 유용하지 않습니다. 에서 git그리고 hg그들은 물론 단지 파입니다.
• DVCS는 소프트웨어 개발이 DAG 라는 것을 이해합니다 . 즉, 병합 할 때 여러 부모가있는 변경 세트가 생깁니다. SVN (적어도 내가 사용한 버전)은 실제로 이것을 이해하지 못합니다.

마지막 시점에서

갈등은 갈등입니다. 코드를 이해하기에 충분히 영리하지 않으면 어떤 시스템이 대부분의 시간에 어떻게 그것을 얻을 수 있는지 알 수 없습니다.

사용하는 스위치에서 hg사용하는 전용 svn단독 다음 gitsvn은 병합이 나의 경험이었다 많은 무료로 간단하고 문제 hg와 gitsvn그들이 함께있는 것보다 svn. svn(적어도 우리가 사용하는 버전) 과 병합 하면 훨씬 더 많은 충돌이 발생하며 수동으로 해결해야합니다.

SVN에서 병합이 더 어려운 이유 중 하나는 각 줄마다 다른 두 가지 옵션 만 제공하기 때문입니다.

• 합류하려는 지점의 텍스트
• 병합하려는 지점의 텍스트

DVCS에서 병합하면 일반적으로 세 번째 옵션이 표시됩니다.

• 병합하려는 두 가지 공통 조상의 텍스트

이것이 얼마나 유익한 지 과소 평가하지 말고 단순한 양방향 diff보다 변경에 대한 훨씬 나은 컨텍스트를 제공합니다 .

대체로 시도해 볼 것을 제안합니다. 같은 도구를 사용 gitsvn하고 hgsubversion, 당신은 당신의 현재의 SVN의 repos로를 시도 할 수 있습니다 .

^{복제본을 처음 생성하는 것은 왕실의 PItA이지만 일단 완료하면 기존 CVCS로 DVCS의 기능을 최대한 활용할 수 있습니다.}

이러한 전환 후 주목할만한 중요한 변화가 있습니다. 분기를 훨씬 더 자주 전환하고 Subversion으로 감당할 수있는 것보다 더 자주 커밋합니다. 예를 들어, 여러 작은 기능 분기가 순서대로 구성되어 있으며 각 분기에 몇 달씩 비트를 추가하여 끊임없이 변화하는 트렁크에 순차적으로 모두 다시베이스를 만들 수 있습니다. 기능 분기가 병합되는 순서를 재정렬하는 것은 쉽지 않습니다.

그러나 실제로는 실제로 Subversion에서 멀어지지 않았습니다. 내 로컬 svn 클라이언트로 git을 사용하고 있습니다.