깃, 머큐리얼, 바자의 상대적 강점과 약점은?
여기 계신 분들은 깃, 머큐리얼, 바자의 상대적인 장단점으로 무엇을 보십니까?
SVN 및 Perforce와 같은 버전 제어 시스템과 서로를 고려할 때 어떤 문제를 고려해야 합니까?
SVN에서 이러한 분산 버전 제어 시스템 중 하나로의 마이그레이션을 계획할 때 어떤 요소를 고려하시겠습니까?
깃은 매우 빠르고, 매우 잘 확장되며, 개념에 대해 매우 투명합니다.이것의 단점은 학습 곡선이 상대적으로 가파르다는 것입니다.Win32 포트를 사용할 수 있지만, 일반 시민은 아닙니다.Git는 해시를 버전 번호로 사용자에게 노출합니다. 이는 (단 하나의 해시가 항상 동일한 내용을 참조한다는 점에서) 보장을 제공하지만, 공격자는 탐지되지 않고는 이력을 수정할 수 없습니다.Git는 파일 내용이 파일 간에 이동할 때에도 고유한 추적 개념을 가지고 있으며 파일을 1단계 객체로 보고 있지만 디렉토리를 추적하지 않습니다.git의 또 다른 문제는 이력을 쉽게 수정할 수 있는 많은 연산(예: 리베이스)이 있다는 것입니다. (어떤 의미에서는 해시에 의해 언급되는 내용은 절대 변하지 않지만 해당 해시에 대한 참조는 손실될 수 있습니다.) 일부 순수주의자들(나 자신도 포함되어 있음)은 이를 별로 좋아하지 않습니다.
바자는 상대적으로 빠릅니다(역사가 얕은 트리의 경우 매우 빠르지만, 현재 역사 길이에 따라 확장이 어렵습니다). 전통적인 SCM(CVS, SVN 등)의 명령줄 인터페이스에 익숙한 사용자가 쉽게 학습할 수 있습니다.Win32는 개발팀에서 1등급 대상으로 꼽힙니다.다양한 구성요소에 대한 플러그형 아키텍처를 갖추고 있으며 스토리지 형식을 자주 교체합니다. 이를 통해 새로운 기능(예: 다양한 개념을 기반으로 한 리비전 제어 시스템과의 통합 지원 개선)을 도입하고 성능을 향상시킬 수 있습니다.바자 팀은 디렉토리 추적 및 이름 변경 지원 1급 기능을 고려합니다.전 세계적으로 고유한 revision-id 식별자를 모든 리비전에 사용할 수 있지만, 트리-로컬 revnos(표준 리비전 번호, svn 또는 다른 기존 SCM에서 사용하는 것과 더 유사함)는 리비전 식별을 위한 컨텐츠 해시 대신 사용됩니다.Bazaa는 로컬 시스템에 복사하는 대신 원격 서버에 이력이 저장되고 필요할 때 네트워크를 통해 자동으로 참조되는 "Lightweight 체크아웃"을 지원합니다. 현재 DSCM 중에서 유일합니다.
둘 다 사용 가능한 형태의 SVN 통합을 가지고 있습니다. 그러나 bzr-svn은 git-svn보다 훨씬 더 능력이 뛰어납니다. 이는 주로 그러한 목적으로 도입된 백엔드 포맷 개정 때문입니다.[업데이트, 2014년 기준: 타사 상용 제품인 SubGit은 SVN과 Git 간의 양방향 인터페이스를 제공합니다. 이 인터페이스는 bzr-svn과 비교해도 충실도가 우수하고 상당히 정교합니다. 예산 및 라이센스 제약 조건이 허용될 때 git-svn보다 사용할 것을 강력히 권장합니다.
Mercurial을 광범위하게 사용한 적이 없기 때문에 Mercurial에 대해 자세히 설명할 수 없습니다. Git와 마찬가지로 수정을 위한 컨텐츠 해시 주소 지정 기능이 있고 Git와 마찬가지로 디렉토리를 퍼스트 클래스 개체로 취급하지 않으며 빈 디렉토리를 저장할 수 없습니다.그러나 Git을 제외한 다른 어떤 DSCM보다도 빠르며, 경쟁사보다 훨씬 뛰어난 IDE 통합성(특히 Eclipse의 경우)을 가지고 있습니다.Mercurial은 성능 특성(Git에 비해 약간 뒤떨어짐)과 우수한 크로스 플랫폼 및 IDE 지원을 고려할 때 win32 중심 또는 IDE 기반 구성원 수가 많은 팀에게 매력적일 수 있습니다.
SVN에서 마이그레이션할 때 우려되는 점은 SVN의 GUI 프론트엔드와 IDE 통합이 분산 SCM보다 더 성숙하다는 것입니다. 또한 현재 SVN에서 사전 커밋 스크립트 자동화를 많이 사용하는 경우(커밋을 진행하기 전에 유닛 테스트를 통과해야 함),공유 지점에 대한 병합 요청을 자동화하기 위해 PQM과 유사한 도구를 사용할 수 있습니다.
SVK는 Subversion을 백업 저장소로 사용하는 DSCM으로 SVN 중심의 도구와 상당히 잘 통합되어 있습니다.그러나 다른 주요 DSCM(심지어 Darcs)보다 성능과 확장성이 현저히 떨어지며, 기록의 길이나 파일의 수 면에서 큰 폭으로 증가하기 쉬운 프로젝트는 피해야 합니다.
[작성자 정보:저는 Git와 Perforce를 업무용으로 사용하고, Baza를 개인 프로젝트와 임베디드 라이브러리로 사용합니다. 고용주 조직의 다른 부분에서는 Mercurial을 많이 사용합니다.전생에 저는 SVN을 중심으로 많은 자동화를 구축했습니다. 그 전에는 GNU Arch, BitKeeper, CVS 등을 경험했습니다.Git는 처음에는 상당히 불쾌했습니다. 사용자의 워크플로우 선택에 따라 제작된 툴킷과 달리 개념이 많이 사용되는 환경인 GNU Arch와 같은 느낌이 들었지만, 그 이후로 상당히 편안해졌습니다.
Ogre 3D 프로젝트의 Steve Streeting(2009년 9월 28일)은 이 주제에 대한 블로그 항목을 발표하여 Git, Mercurial 및 Baza를 비교하기도 했습니다.
결국 그는 확실한 승자가 없는 세 가지 모두에서 장단점을 발견합니다.긍정적인 측면에서, 그는 당신이 어떤 것으로 할지 결정하는 데 도움이 되는 훌륭한 테이블을 제공합니다.
짧게 읽었고 적극 추천합니다.
여기 계신 분들은 깃, 머큐리얼, 바자의 상대적인 장단점으로 무엇을 보십니까?
제 생각에 Git의 강점은 깨끗한 기본 디자인과 매우 풍부한 기능들입니다.또한 멀티브랜치 저장소 및 지점별 워크플로우 관리에 가장 적합한 지원 기능을 갖추고 있습니다.매우 빠르고 저장소 크기도 작습니다.
유용하지만 익숙해지려면 노력이 필요한 기능들이 있습니다.여기에는 작업 영역과 저장소 데이터베이스 사이의 보이는 중간 단계 아라(인덱스)가 포함되며, 이는 더 복잡한 경우에 더 나은 병합 해결을 가능하게 하며, 증분 커밋 및 더러운 트리와의 커밋을 가능하게 합니다. 일종의 파일 ID를 사용하여 이름과 복사본을 추적하는 대신 유사 휴리스틱을 사용하여 탐지합니다.이것은 잘 작동하고 파일 간의 코드 이동을 따라 할 수 있고 도매 이름뿐만 아니라 비난(annotate)을 허용합니다.
단점 중 하나는 MS 윈도 지원이 뒤떨어져 꽉 차 있지 않다는 점입니다.또 다른 단점은 Mercurial과 같이 문서화가 잘 되어 있지 않고, 경쟁 제품에 비해 사용자 친화성이 떨어지지만 변화한다는 것입니다.
제 생각에 머큐리얼의 강점은 좋은 성능과 작은 저장소 크기, 좋은 MS Windows 지원에 있습니다.
가장 큰 단점은 지역 지점(단일 저장소의 여러 지점)이 여전히 2급 시민이라는 점과 태그를 구현하는 이상하고 복잡한 방식이라는 점입니다.또한 파일 이름 변경을 처리하는 방식은 최적이 아니었습니다(그러나 이 가능성은 바뀌었습니다).수은은 문어 합병(부모가 두 명 이상임)을 지원하지 않습니다.
제가 듣고 읽은 바자의 주요 장점은 중앙 집중화된 워크플로우를 쉽게 지원한다는 것입니다(중앙 집중화된 개념이 보이지 않는 단점도 있음). 파일과 디렉토리의 이름을 모두 추적한다는 것입니다.
비선형 이력이 긴 대규모 저장소의 성능과 저장소 크기(적어도 너무 크지 않은 저장소의 경우 성능이 향상됨), 기본 패러다임이 저장소당 하나의 랜치(데이터를 공유하도록 설정할 수 있음), 중앙 집중화된 개념(변경 사항도 있음) 등의 단점이 있습니다.
Git는 C, 셸 스크립트 및 Perl로 작성되며 스크립트화 가능합니다. Mercurial은 C(core, performance)와 Python으로 작성되며 확장용 API를 제공합니다. Baza는 Python으로 작성되며 확장용 API를 제공합니다.
SVN 및 Perforce와 같은 버전 제어 시스템과 서로를 고려할 때 어떤 문제를 고려해야 합니까?
SVN(Subversion), Perforce 또는 ClearCase와 같은 버전 제어 시스템은 중앙 집중식 버전 제어 시스템입니다.Git, Mercurial, Baza(그리고 Darcs, Monotone, BitKeeper)는 분산 버전 제어 시스템입니다.분산 버전 제어 시스템은 훨씬 더 넓은 범위의 워크플로우를 허용합니다.준비되면 게시"를 사용할 수 있습니다.이들은 분기 및 병합, 분기별 워크플로우를 보다 잘 지원합니다.여러분은 사람들로부터 기부금을 쉽게 받을 수 있도록 헌신적인 접근 권한을 가진 사람들을 믿을 필요가 없습니다.
SVN에서 이러한 분산 버전 제어 시스템 중 하나로의 마이그레이션을 계획할 때 어떤 요소를 고려하시겠습니까?
고려하고 싶은 요소 중 하나는 SVN을 통한 intracting 지원입니다. Git는 git-svn, Baza는 bzr-svn, Mercurial은 hgs 서브버전 확장입니다.
면책 사항:저는 Git 사용자이자 소규모 시간 기여자이며, Git 메일링 리스트를 시청(및 참여)합니다.머큐리얼과 바자는 그들의 문서, IRC 및 메일링 리스트에 대한 다양한 토론, 다양한 버전 제어 시스템을 비교하는 블로그 게시물 및 기사(일부는 Git Wiki의 GitComparison 페이지에 나와 있음)를 통해서만 알고 있습니다.
머큐리얼과 바자는 겉으로 보기에는 그들과 매우 닮았습니다.오프라인 커밋 및 여러 분기 병합에서와 같이 둘 다 기본적인 분산 버전 제어를 제공하며 둘 다 python으로 작성되며 둘 다 git보다 느립니다.일단 코드를 자세히 들여다보면 많은 차이가 있지만 일상적인 업무에 대해서는 머큐리얼이 조금 더 추진력이 있는 것처럼 보이지만 사실상 동일합니다.
깃은, 시작하지 않은 사람들을 위한 것이 아닙니다.머큐리얼과 바자보다 훨씬 빠르며 리눅스 커널을 관리하기 위해 작성되었습니다.그것은 세 개 중에서 가장 빠르며, 또한 세 개 중에서 꽤 큰 차이로 가장 강력합니다.Git의 로그 및 커밋 조작 도구는 일치하지 않습니다.하지만, 그것은 또한 사용하기에 가장 복잡하고 위험합니다.특히 깃의 내부 동작을 이해하지 못하면 커밋을 잃거나 저장소를 망치는 것은 매우 쉽습니다.
Python 개발자 http://wiki.python.org/moin/DvcsComparison 과의 최근 비교를 살펴보세요.그들은 세 가지 중요한 이유를 바탕으로 Mercurial을 선택했습니다.
Mercurial과 함께 하기로 한 것은 세 가지 중요한 이유 때문입니다.
- 소규모 조사에 따르면 파이썬 개발자들은 바자나 깃보다 머큐리얼 사용에 더 관심이 있다고 합니다.
- 머큐리얼은 파이썬(Python)으로 쓰이는데, 이는 파이썬 개발자가 '자신의 개 사료를 먹는다'는 경향과 일치합니다.
- 수은은 bzr보다 상당히 빠릅니다(그것은 깃보다 느리지만, 훨씬 작은 차이입니다).
- 머큐리얼은 바자보다 SVN 사용자들이 배우기 쉽습니다.
(http://www.python.org/dev/peps/pep-0374/) 에서)
Sun은 Solaris 코드 기반을 위해 Sun Teamware VCS를 대체할 후보로 git, Mercurial 및 Baza를 평가했습니다.아주 흥미롭더라.
바자회에서 매우 중요한 누락된 것은 cp입니다.SVN에서와 같이 동일한 기록을 공유하는 파일을 여러 개 가질 수 없습니다. 예를 들어 여기와 여기를 참조하십시오.만약 당신이 cp를 사용할 계획이 없다면, bzr은 svn을 대체하는 아주 좋은 (그리고 매우 사용하기 쉬운) 대체품입니다.
제가 좋아하던 바자를 한동안 사용하고 있었는데 작은 프로젝트에 불과했고 그마저도 꽤 느렸습니다.배우기는 쉽지만 빠르지는 않습니다.하지만 그것은 매우 x-플랫폼입니다.
저는 현재 1.6 버전이 다른 VCS와 사용하는 명령어가 훨씬 비슷해서 마음에 드는 Git를 사용하고 있습니다.
DVCS를 사용한 경험의 주요 차이점은 다음과 같습니다.
- Git은 가장 활기찬 커뮤니티를 가지고 있으며 Git에 대한 기사를 보는 것이 일반적입니다.
- GitHub 진짜 대박.Launchpad.net 은 괜찮지만 Github의 즐거움만큼 좋은 것은 없습니다.
- Git의 워크플로우 툴 수는 매우 많습니다.그것은 모든 곳에 통합되어 있습니다.Bzr을 위한 것들이 있지만, 거의 없거나 잘 유지되고 있습니다.
요약하면 제가 DVCS에서 이를 자를 때는 Bzr도 훌륭했지만 지금은 Git와 Github에 대해 매우 만족합니다.
이것은 이 작은 텍스트 상자 중 하나에 입력하는 데 많은 시간이 걸리는 컨텍스트에 많은 의존적인 큰 질문입니다.또한, 대부분의 프로그래머들이 하는 일반적인 일에 사용될 때 이 세 가지 모두 상당히 유사하게 보이기 때문에, 차이점을 이해하는 것조차도 상당히 난해한 지식을 필요로 합니다.
이러한 도구에 대한 분석을 보다 구체적인 질문이 있을 때까지 분석할 수 있다면 아마도 훨씬 더 나은 답변을 얻을 수 있을 것입니다.
바자는 깃보다 배우기 쉬운 IMHO입니다.Git은 github.com 에서 좋은 지원을 받고 있습니다.
두 가지를 다 사용해 보시고 어떤 것이 가장 적합한지 결정해보셔야 할 것 같습니다.
여기 계신 분들은 깃, 머큐리얼, 바자의 상대적인 장단점으로 무엇을 보십니까?
이것은 매우 공개적인 질문입니다. 화염병에 가까운 것입니다.
깃이 가장 빠르지만, 셋 다 충분히 빠릅니다.Bazaa는 가장 유연하며(SVN 저장소에 대한 투명한 읽기-쓰기 지원) 사용자 환경에 신경을 많이 씁니다.수은은 중간 어딘가에 있습니다.
세가지 시스템 모두 팬보이가 많습니다.저는 개인적으로 바자회 팬입니다.
SVN 및 Perforce와 같은 버전 제어 시스템과 서로를 고려할 때 어떤 문제를 고려해야 합니까?
전자는 분산형 시스템입니다.후자는 중앙 집중식 시스템입니다.게다가 Perforce는 독점적이고 다른 모든 것들은 말처럼 자유롭습니다.
중앙 집중식과 분산식은 해당 범주에서 언급한 어떤 시스템보다도 훨씬 더 중요한 선택입니다.
SVN에서 이러한 분산 버전 제어 시스템 중 하나로의 마이그레이션을 계획할 때 어떤 요소를 고려하시겠습니까?
첫째, 거북이를 대신할 좋은 대체물이 부족합니다.SVN. 바자가 거북이 변형 작업을 하고 있지만, 2008년 9월 현재 아직은 없습니다.
그러면 핵심 인력들에게 분산형 시스템을 사용하는 것이 업무에 어떤 영향을 미치는지 교육하는 것입니다.
마지막으로, 이슈 추적기, 야간 구축 시스템, 자동화 테스트 시스템 등 나머지 시스템과의 통합입니다.
주요 문제는 분산형 SCM이기 때문에 사용자의 사고방식에 약간의 변화가 필요하다는 것입니다.사람들이 이 아이디어에 익숙해지면 기술적인 세부 사항과 사용 패턴이 적합해질 것입니다. 하지만 초기 장애물을 과소평가하지 마십시오. 특히 기업 환경에서는 더욱 그렇습니다.모든 문제는 사람의 문제라는 것을 기억하세요.
ddaa.myopenid.com 에서 이를 언급했지만 다시 한 번 언급할 가치가 있다고 생각합니다. Baza는 원격 SVN 저장소를 읽고 쓸 수 있습니다.즉, 나머지 팀원들이 아직 Subversion을 사용하고 있을 때 Baza를 개념 증명으로 로컬에서 사용할 수 있습니다.
편집: 이제 거의 모든 툴이 SVN과 상호작용하는 방식을 갖게 되었지만, 이제 개인적인 경험이 있습니다.git svn매우 잘 작동합니다.딸꾹질을 최소화한 채로 몇 달째 쓰고 있습니다.
리누스 토르발스의 좋은 비디오가 있습니다.그는 Git의 제작자이기 때문에 이것이 그가 홍보하는 것이지만 영상에서 그는 분산된 SCM이 무엇인지, 중앙 집중식 SCM보다 더 나은 이유를 설명합니다.git(mercurial은 괜찮은 것으로 간주됨)와 cvs/svn/perforce를 많이 비교합니다.분산 SCM으로의 마이그레이션에 대한 청중들의 질문도 있습니다.
저는 이 자료가 깨달음을 주었으며 저는 분산형 SCM에 팔렸습니다.하지만 리누스의 노력에도 불구하고 저의 선택은 머큐리얼입니다.그 이유는 bitbucket.org , github보다 더 나은(더 관대한) 것을 발견했기 때문입니다.
여기서 한 가지 경고를 해야 할 것이 있습니다. 리누스는 꽤 공격적인 스타일을 가지고 있습니다. 그가 웃기려고 한다고 생각하지만 저는 웃지 않았습니다.그 외에도, 분산 SCM을 처음 사용하는 분들과 SVN에서 이동하는 것을 생각한다면 좋은 비디오입니다.
http://www.youtube.com/watch?v=4XpnKHJAok8
DVCS(분산 버전 제어 시스템)는 중앙 집중식 VCS와는 다른 문제를 해결합니다.그것들을 비교하는 것은 망치와 드라이버를 비교하는 것과 같습니다.
중앙 집중화된 VCS 시스템은 축복받은 진정한 하나의 소스(True Source)가 있으므로 좋음(Good)을 목표로 설계되었습니다.모든 개발자는 해당 소스에서 작업(체크아웃)한 다음 변경사항을 추가(커밋)하면 유사하게 축복됩니다.CVS, Subversion, ClearCase, Perforce, VisualSourceSafe와 다른 모든 CVCS 간의 유일한 실질적인 차이점은 각 제품이 제공하는 워크플로우, 성능 및 통합에 있습니다.
Distributed VCS 시스템은 한 저장소의 성능이 다른 저장소와 비슷하다는 의도로 설계되었으며, 한 저장소에서 다른 저장소로 병합되는 것은 통신의 또 다른 형태일 뿐입니다.신뢰할 저장소에 대한 의미적 가치는 소프트웨어 자체가 아닌 프로세스에 의해 외부에서 부과됩니다.
프로젝트나 조직에서 중앙 집중식 제어를 원하는 경우 DVCS는 시작부터 시작하지 않는 것이 좋습니다.개발자들이 중앙 저장소에 대한 안전한 광대역 연결 없이 국가/세계 전역에서 작업할 것으로 예상되는 경우 DVCS를 사용할 수 있습니다.둘 다 필요하다면, 당신은 곤경에 빠집니다.
언급URL : https://stackoverflow.com/questions/77485/what-are-the-relative-strengths-and-weaknesses-of-git-mercurial-and-bazaar
'programing' 카테고리의 다른 글
| 장고의 AJAX를 통해 매개 변수를 게시하는 동안 "CSRF 토큰 누락 또는 부정확" (0) | 2023.09.27 |
|---|---|
| MySQL 열 유형 "TIMESTamp"에는 "NOT NULL DEFAULT CURRENT_TIMESTamp ON UPDATE CURRENT_TIMESTamp"가 함축적으로 포함되어 있습니다. (0) | 2023.09.27 |
| Android Spinner : 아이템 회피초기화 중에 선택한 호출 (0) | 2023.09.27 |
| 예상되는 Oracle 예외에 대한 PHP 경고 억제 (0) | 2023.09.27 |
| operator.item getter() 및 sort()는 어떻게 작동합니까? (0) | 2023.09.27 |