Git, Mercurial 및 Bazaar의 상대적 강점과 약점은 무엇입니까? [닫은]

여기서 사람들은 Git, Mercurial 및 Bazaar의 상대적 강점과 약점으로 무엇을보고 있습니까?

SVN 및 Perforce와 같은 버전 제어 시스템과 서로를 고려할 때 어떤 문제를 고려해야합니까?

SVN에서 이러한 분산 버전 제어 시스템 중 하나로의 마이그레이션을 계획 할 때 고려해야 할 요소는 무엇입니까?

힘내는 매우 빠르며 확장 성이 뛰어나며 개념에 대해 매우 투명합니다. 이것의 단점은 학습 곡선이 비교적 가파르다는 것입니다. Win32 포트는 사용 가능하지만 일류 시민은 아닙니다. Git은 해시를 버전 번호로 사용자에게 노출합니다. 이를 통해 단일 해시가 항상 정확히 동일한 내용을 참조하므로 공격자가 탐지되지 않고 기록을 수정할 수는 없지만 사용자에게는 번거로울 수 있습니다. Git은 파일 내용을 파일간에 이동하고 파일을 1 단계 개체로 보지만 디렉토리를 추적하지 않는 경우에도 파일 내용을 추적하는 고유 한 개념을 가지고 있습니다. 자식의 또 다른 문제는 rebase 와 같은 많은 작업이 있다는 것입니다) 히스토리를 쉽게 수정할 수있게합니다 (해시에서 참조하는 컨텐츠는 절대 변경되지 않지만 해당 해시에 대한 참조는 손실 될 수 있음). 일부 순수 주의자 (자신 포함)는 그다지 좋아하지 않습니다.

Bazaar는 상당히 빠르지 만 (이력이 얕은 나무에서는 매우 빠르지 만 현재는 역사 길이에 따라 확장이 잘되지 않습니다), 기존 SCM (CVS, SVN 등)의 명령 줄 인터페이스에 익숙한 사용자에게는 쉽게 배울 수 있습니다. Win32는 개발 팀에 의해 일류 대상으로 간주됩니다. 다양한 구성 요소를위한 플러그 가능한 아키텍처를 가지고 있으며 스토리지 형식을 자주 대체합니다. 이를 통해 새로운 개념 (예 : 서로 다른 개념을 기반으로하는 개정 제어 시스템과의 통합 지원 향상)을 도입하고 성능을 향상시킬 수 있습니다. Bazaar 팀은 디렉토리 추적 및 이름 변경 지원 기능을 고려합니다. 전 세계적으로 고유 한 개정판 ID 식별자를 모든 개정판에 사용할 수 있지만, 트리 로컬 개정판 (표준 개정판 번호, 수정을 식별하기 위해 콘텐츠 해시 대신 svn 또는 기타 더 일반적인 SCM에서 사용되는 것과 더 유사합니다. Bazaar는 "경량 체크 아웃"을 지원하며, 여기서 히스토리는 로컬 시스템으로 복사되지 않고 원격 서버에 기록되며 필요할 때 네트워크를 통해 자동으로 참조됩니다. 현재 이것은 DSCM에서 고유합니다.

둘 다 어떤 형태의 SVN 통합이 가능합니다. 그러나 bzr-svn은 git-svn보다 훨씬 더 성능이 뛰어납니다. 그 목적을 위해 도입 된 백엔드 형식 수정 때문입니다. [업데이트, 2014 년 기준 : 타사 상용 제품 SubGit은 SVN과 Git 사이에 양방향 인터페이스를 제공합니다.이 인터페이스는 bzr-svn과 충실하며 훨씬 더 정교합니다. 나는 강력하게 예산 및 라이센스 제약이 허락 할 때] 자식-SVN의 이상 사용을 권장합니다.

나는 Mercurial을 광범위하게 사용하지 않았기 때문에 Git과 마찬가지로 수정을 위해 컨텐츠 해시 주소를 지정한다는 점을 제외하고는 자세히 언급 할 수 없다. 또한 Git과 마찬가지로 디렉토리를 일급 객체로 취급하지 않으며 빈 디렉토리를 저장할 수 없습니다. 그러나 Git을 제외한 다른 DSCM보다 빠르며 다른 경쟁사보다 IDE 통합 (특히 Eclipse)이 훨씬 뛰어납니다. 성능 특성 (Git의 성능보다 약간 뒤 떨어짐)과 탁월한 크로스 플랫폼 및 IDE 지원을 고려할 때 Mercurial은 많은 수의 win32 중심 또는 IDE 바인딩 멤버를 가진 팀에게 매력적일 수 있습니다.

SVN에서 마이그레이션 할 때 고려해야 할 사항 중 하나는 SVN의 GUI 프론트 엔드와 IDE 통합이 분산 SCM의 것보다 훨씬 성숙하다는 것입니다. 또한 현재 SVN을 사용하여 사전 커밋 스크립트 자동화를 많이 사용하는 경우 (즉, 커밋을 진행하기 전에 단위 테스트를 통과해야 함) PQM 과 유사한 도구를 사용하고 싶을 것입니다 공유 분기에 대한 병합 요청을 자동화 .

SVK는 Subversion을 백업 저장소로 사용하는 DSCM이며 SVN 중심 도구와 매우 잘 통합됩니다. 그러나 다른 주요 DSCM (Darcs 포함)보다 성능 및 확장 성 특성이 크게 저하되므로 기록 기간이나 파일 수 측면에서 크게 성장할 수있는 프로젝트의 경우 피해야합니다.

[저자 소개 : 저는 Git과 Perforce를 업무용으로 사용하고 Bazaar를 개인 프로젝트와 내장형 라이브러리로 사용합니다. 고용주 조직의 다른 부분에서는 Mercurial을 많이 사용합니다. 이전에는 SVN을 중심으로 많은 자동화를 구축했습니다. 그 전에는 GNU Arch, BitKeeper, CVS 및 기타 경험이 있습니다. Git은 처음에는 상당히 과감했습니다. 사용자가 선택한 워크 플로우에 맞게 설계된 툴킷과는 달리 GNU Arch는 개념이 많은 환경 인 것처럼 느껴졌습니다. 그것].

Ogre 3D 프로젝트의 Steve Streeting (2009/9/28)은이 주제에 대해 Git, Mercurial 및 Bazaar를 훌륭하고 직접 비교 한 블로그 항목을 게시했습니다 .

결국 그는 분명한 승자가없는 세 사람 모두에게 강점과 약점을 발견합니다. 플러스 측면에서, 그는 당신이 함께 갈 것을 결정하는 데 도움이되는 훌륭한 테이블을 제공합니다.

짧은 읽기이며 강력히 권장합니다.

여기서 사람들은 Git, Mercurial 및 Bazaar의 상대적 강점과 약점으로 무엇을보고 있습니까?

내 생각에 힘내 힘은 깨끗한 기본 디자인과 매우 다양한 기능입니다. 또한 멀티 브랜치 리포지토리 및 브랜치 중심 워크 플로 관리에 대한 최상의 지원을 생각합니다. 매우 빠르며 저장소 크기가 작습니다.

유용한 기능이 있지만 익숙해 지려면 약간의 노력이 필요합니다. 여기에는 눈에 보이는 것이 포함됩니다 작업 영역과 저장소 데이터베이스 간의 중간 스테이징 영역 (인덱스)이 포함되어있어보다 복잡한 경우의 병합 해결, 증분 커밋 및 더티 트리 커밋; 감지유사한 종류의 파일 ID를 사용하여 추적하지 않고 유사 휴리스틱을 사용하여 이름 및 사본을 합니다. 이는 잘 작동하며 도매 이름 변경뿐만 아니라 파일에서 코드 이동을 따를 수있는 비난 (주석)을 허용합니다.

단점 중 하나는 MS Windows 지원이 뒤쳐지고 가득 차 있지 않다는 것입니다. 인식되는 또 다른 단점은 예를 들어 Mercurial과 같이 잘 문서화되어 있지 않으며 경쟁 제품보다 사용자에게 친숙하지 않지만 변경된다는 것입니다.

내 의견으로는 Mercurial 강점은 우수한 MS Windows 지원에서 우수한 성능과 작은 저장소 크기에 있습니다.

주요 단점은 로컬 브랜치 (단일 저장소의 여러 브랜치)가 여전히 2 차 시민이며 태그를 구현하는 이상하고 복잡한 방식이라는 사실입니다. 또한 파일 이름 변경을 처리하는 방식이 차선책이었습니다 (그러나이 마이그레이션은 변경되었습니다). Mercurial은 문어 병합 (두 부모 이상)을 지원하지 않습니다.

내가 들었던 바자 주요 이점은 중앙 집중식 워크 플로를 쉽게 지원하고 중앙 집중식 개념이 없어야하는 단점이 있음에도 불구하고 파일과 디렉토리의 이름 변경을 추적한다는 것입니다.

가장 큰 단점은 비선형 히스토리가 긴 대규모 리포지토리의 성능 및 리포지토리 크기 (적어도 리포지토리가 너무 크지 않은 경우에는 성능이 향상됨)이며 기본 패러다임은 리포지토리 당 하나의 목장이라는 사실입니다 (데이터를 공유하도록 설정할 수 있음) , 그리고 중앙 집중식 개념 (그러나 그것은 또한 내가 들었던 변화에서).

Git은 C, 쉘 스크립트 및 Perl로 작성되며 스크립트 가능합니다. Mercurial은 C (핵심, 성능) 및 Python으로 작성되었으며 확장을위한 API를 제공합니다. Bazaar는 Python으로 작성되었으며 확장을위한 API를 제공합니다.

SVN 및 Perforce와 같은 버전 제어 시스템과 서로를 고려할 때 어떤 문제를 고려해야합니까?

SVN (Subversion), Perforce 또는 ClearCase와 같은 버전 제어 시스템은 중앙 집중식 버전 제어 시스템입니다. Git, Mercurial, Bazaar (및 Darcs, Monotone 및 BitKeeper)는 분산 버전 제어 시스템입니다. 분산 버전 제어 시스템은 훨씬 광범위한 워크 플로우를 허용합니다. "준비되면 게시"를 사용할 수 있습니다. 분기 및 병합, 분기가 많은 워크 플로를 더 잘 지원합니다. 커밋 액세스 권한을 가진 사람들이 쉽게 기여할 수 있도록 믿지 않아도됩니다.

SVN에서 이러한 분산 버전 제어 시스템 중 하나로의 마이그레이션을 계획 할 때 고려해야 할 요소는 무엇입니까?

고려해야 할 요소 중 하나는 SVN 흡입을 지원하는 것입니다. Git은 git-svn, Bazaar는 bzr-svn, Mercurial은 hgsubversion extension을가집니다.

면책 조항 : 저는 Git 사용자이며 소액 기부자이며 자식 메일 링리스트를보고 참여합니다. Mercurial과 Bazaar는 문서, IRC 및 메일 목록에 대한 다양한 토론, 다양한 버전 제어 시스템을 비교 한 블로그 게시물 및 기사 (일부는 Git Wiki의 GitComparison 페이지에 나와 있음)에서만 알고 있습니다 .

InfoQ는 좋은 비교가 있습니다.

Mercurial과 Bazaar는 표면에서 매우 닮았습니다. 오프라인 커밋 및 여러 분기 병합과 같이 기본 분산 버전 제어를 제공하며 둘 다 파이썬으로 작성되며 둘 다 git보다 느립니다. 코드를 살펴보면 많은 차이점이 있지만 일상적인 작업의 경우 Mercurial이 약간 더 많은 추진력을 갖는 것처럼 보이지만 실제로는 동일합니다.

힘내, 잘, 시작하지 않습니다. Mercurial과 Bazaar보다 훨씬 빠르며 Linux 커널을 관리하기 위해 작성되었습니다. 3 개 중 가장 빠르며 3 개 중 가장 강력합니다. Git의 로그 및 커밋 조작 도구는 타의 추종을 불허합니다. 그러나 사용하기가 가장 복잡하고 위험합니다. 커밋을 잃거나 저장소를 망치는 것은 매우 쉽습니다. 특히 git의 내부 동작을 이해하지 못하는 경우에 특히 그렇습니다.

최근 Python 개발자의 비교를 살펴보십시오 ( http://wiki.python.org/moin/DvcsComparison) . 그들은 세 가지 중요한 이유로 Mercurial을 선택했습니다.

Mercurial과 함께 가기로 선택한 이유는 세 가지 중요한 이유 때문입니다.

• 소규모 조사에 따르면 Python 개발자는 Bazaar 또는 Git보다 Mercurial 사용에 더 관심이 있습니다.
• Mercurial은 Python으로 작성되었으며, 이는 '자신의 개밥을 먹는'Python-dev 경향과 일치합니다.
• Mercurial은 bzr보다 훨씬 빠릅니다 (훨씬 작은 차이로 git보다 느립니다).
• SVuri 사용자는 Mercurial을 Bazaar보다 쉽게 ​​배울 수 있습니다.

( http://www.python.org/dev/peps/pep-0374/에서 )

Sun은 Solaris 코드 기반의 Sun Teamware VCS를 대체 ​​할 후보로 git , Mercurial 및 Bazaar 를 평가했습니다 . 나는 그것을 매우 흥미로웠다.

시장에서 매우 중요한 누락 사항은 cp입니다. SVN에서와 같이 동일한 기록을 공유하는 여러 파일을 가질 수 없습니다 (예 : here 및 here 참조) . cp를 사용하지 않을 계획이라면 bzr은 svn을 대체하는 훌륭한 (그리고 사용하기 매우 쉬운) 대안입니다.

나는 Bazaar를 잠시 동안 사용하고 있었지만 많이 좋아했지만 프로젝트는 작았고 심지어는 느 렸습니다. 배우기 쉽지만 빠르지는 않습니다. 그것은 매우 x 플랫폼입니다.

현재 1.6 버전 이후로 많이 좋아하는 Git을 사용하여 사용할 명령 측면에서 다른 VCS와 훨씬 유사합니다.

DVCS 사용 경험의 주요 차이점은 다음과 같습니다.

1. Git은 가장 활발한 커뮤니티를 가지고 있으며 Git에 관한 기사를 보는 것이 일반적입니다.
2. GitHub는 정말 흔들립니다. Launchpad.net은 괜찮지 만 Github의 즐거움과 같은 것은 없습니다.
3. Git을위한 워크 플로우 도구의 수가 많았습니다. 모든 곳에 통합되어 있습니다. Bzr에는 몇 가지가 있지만 그다지 많지 않거나 잘 관리되지 않았습니다.

요약 Bzr은 DVCS로 치아를 절단 할 때 훌륭했지만 이제는 Git과 Github에 매우 만족합니다.

이 작은 텍스트 상자 중 하나에 입력하는 데 많은 시간이 걸리는 상황에 따라 달라지는 큰 질문입니다. 또한, 이들 세 가지 모두 대부분의 프로그래머가하는 일반적인 작업에 사용될 때 실질적으로 유사 해 보이기 때문에 차이점을 이해하기 위해서는 다소 난해한 지식이 필요합니다.

이러한 도구에 대한 분석을보다 구체적인 질문이있는 시점으로 세분화하면 더 나은 답변을 얻을 수 있습니다.

Bazaar는 git보다 IMHO를 배우기가 더 쉽습니다. Git은 github.com에서 훌륭한 지원을하고 있습니다.

둘 다 사용하고 가장 적합한 것을 결정해야한다고 생각합니다.

여기서 사람들은 Git, Mercurial 및 Bazaar의 상대적 강점과 약점으로 무엇을보고 있습니까?

이것은 화염 미끼에 접해있는 매우 열린 질문입니다.

힘내가 가장 빠르지 만 세 가지 모두 빠릅니다. Bazaar는 가장 유연하며 (SVN 리포지토리에 대한 투명한 읽기 / 쓰기 지원 기능이 있음) 사용자 경험에 많은 관심을 기울입니다. 머큐리얼은 중간에 있습니다.

세 시스템 모두 팬보이가 많습니다. 저는 개인적으로 Bazaar 팬보이입니다.

SVN 및 Perforce와 같은 버전 제어 시스템과 서로를 고려할 때 어떤 문제를 고려해야합니까?

전자는 분산 시스템입니다. 후자는 중앙 집중식 시스템입니다. 또한 Perforce는 독점적이며 다른 모든 언어는 말 그대로 무료 입니다.

중앙 집중식과 분산 형은 범주 내에서 언급 한 시스템보다 훨씬 빠른 선택입니다.

SVN에서 이러한 분산 버전 제어 시스템 중 하나로의 마이그레이션을 계획 할 때 고려해야 할 요소는 무엇입니까?

첫째, TortoiseSVN을 대체 할 좋은 제품이 없습니다. Bazaar는 자체 Tortoise 변형을 개발 하고 있지만 2008 년 9 월 현재는 아직 없습니다.

그런 다음 분산 시스템을 사용하는 것이 업무에 어떤 영향을 미치는지에 대해 핵심 사람들을 교육하십시오.

마지막으로 이슈 트래커, 야간 빌드 시스템, 자동 테스트 시스템 등과 같은 나머지 시스템과의 통합

가장 큰 문제는 이것이 분산 SCM이므로 사용자의 사고 방식을 약간 변경해야한다는 것입니다. 사람들이 아이디어에 익숙해지면 기술적 세부 사항과 사용 패턴이 제자리에 들어가지만 특히 기업 환경에서 초기 장애물을 과소 평가하지 마십시오. 모든 문제는 사람들의 문제라는 것을 기억하십시오.

ddaa.myopenid.com은 그것을 전달하면서 언급했지만 다시 언급 할 가치가 있다고 생각합니다. Bazaar는 원격 SVN 저장소를 읽고 쓸 수 있습니다. 즉, 나머지 팀이 여전히 Subversion을 사용하는 동안 Bazaar를 개념 증명으로 로컬로 사용할 수 있습니다.

편집 : 거의 모든 도구가 이제 SVN과 상호 작용할 수 있는 방법이 있지만 이제는 매우 잘 git svn작동 하는 개인 경험이 있습니다. 최소한의 딸꾹질로 몇 달 동안 사용했습니다.

Linus Torvalds의 git에 대한 좋은 비디오가 있습니다. 그는 Git의 제작자이므로 이것이 홍보하는 것이지만 비디오에서 분산 SCM이 무엇이며 중앙 집중식 SCM보다 나은 이유를 설명합니다. git (수은은 괜찮은 것으로 간주 됨)과 cvs / svn / perforce를 비교하는 것이 많이 있습니다. 분산 SCM으로의 마이그레이션과 관련하여 청중의 질문도 있습니다.

나는이 물질이 깨달음을 얻었고 분산 SCM에 팔렸다. 그러나 Linus의 노력에도 불구하고 나의 선택은 수은입니다. 그 이유는 bitbucket.org이기 때문에 github보다 더 낫습니다.

나는 여기에 경고의 한 마디를 말해야한다 : Linus는 매우 공격적인 스타일을 가지고있다. 나는 그가 웃기를 원하지만 나는 웃지 않았다고 생각한다. 그 외에도 분산 SCM을 처음 사용하고 SVN에서 이동하는 것을 생각하면 비디오가 훌륭합니다.

http://www.youtube.com/watch?v=4XpnKHJAok8

분산 버전 제어 시스템 (DVCS)은 중앙 집중식 VCS와 다른 문제를 해결합니다. 그것들을 비교하는 것은 망치와 드라이버를 비교하는 것과 같습니다.

중앙 집중식 VCS 시스템은 축복 된 하나의 진정한 근원이 있기 때문에 좋은 것으로 의도되도록 설계되었습니다. 모든 개발자는 해당 소스에서 작업 (체크 아웃) 한 다음 변경 사항을 추가 (커밋) 한 다음 마찬가지로 축복을받습니다. CVS, Subversion, ClearCase, Perforce, VisualSourceSafe 및 기타 모든 CVCSe의 유일한 차이점은 각 제품이 제공하는 워크 플로우, 성능 및 통합에 있습니다.

분산 VCS 시스템은 한 저장소가 다른 저장소만큼 우수하고 한 저장소에서 다른 저장소로 병합되는 것은 다른 통신 형식 일뿐입니다. 어떤 리포지토리를 신뢰할 수 있는지에 대한 의미 적 가치는 소프트웨어 자체가 아니라 프로세스에 의해 외부에서 부과됩니다.

프로젝트 또는 조직이 중앙 집중식 제어를 원할 경우 DVCS는 스타터가 아닙니다. 개발자가 중앙 저장소에 대한 안전한 광대역 연결없이 국가 / 세계에서 일할 것으로 예상되는 경우 DVCS는 아마도 당신의 구원 일 것입니다. 둘 다 필요하다면 fsck'd입니다.