중앙 집중식 및 분산 형 버전 제어 시스템 비교

중앙 집중식 및 분산 형 버전 제어 시스템 비교

---

중앙 집중식 버전 제어 시스템 (DVCS) 을 사용할 때의 장점과 단점 은 무엇입니까 ? DVCS에서 문제가 발생했으며 이러한 문제에 대해 어떻게 보호 했습니까? 토론 도구는 불가지론적이고 불타 오르는 것을 최소화하십시오.

어떤 DVCS 도구를 사용할 수 있는지 궁금한 사람들을 위해 가장 잘 알려진 무료 / 오픈 소스 DVCS 목록은 다음과 같습니다.

• Linux Kernel 및 Ruby on Rails에서 사용하는 Git (C로 작성) .
• Mozilla 및 OpenJDK에서 사용하는 Mercurial (Python으로 작성) .
• Ubuntu 개발자가 사용하는 Bazaar (Python으로 작성) .
• Darcs , (Haskell로 작성).

---

에서 내 대답 다른에 대한 질문 :

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

중앙 집중식 VCS 시스템은 축복받은 하나의 진정한 소스가 있으므로 좋은 의도로 설계되었습니다. 모든 개발자는 해당 소스에서 작업 (체크 아웃) 한 다음 변경 사항을 추가 (커밋)하면 비슷하게 축복받습니다. CVS, Subversion, ClearCase, Perforce, VisualSourceSafe 및 다른 모든 CVCS의 유일한 실제 차이점은 각 제품이 제공하는 워크 플로우, 성능 및 통합입니다.

분산 VCS 시스템은 한 저장소가 다른 저장소와 마찬가지로 우수하고 한 저장소에서 다른 저장소로 병합되는 것은 또 다른 형태의 통신 일 뿐이라는 의도로 설계되었습니다. 어떤 저장소를 신뢰해야하는지에 대한 의미 론적 가치는 소프트웨어 자체가 아닌 프로세스에 의해 외부에서 부과됩니다.

한 유형 또는 다른 유형을 사용하는 것 사이의 진정한 선택은 조직적인 것입니다. 프로젝트 나 조직이 중앙 집중식 제어를 원하는 경우 DVCS는 시작이 아닙니다. 개발자가 중앙 저장소에 대한 보안 광대역 연결없이 국가 / 전 세계에서 작업 할 것으로 예상되는 경우 DVCS가 아마도 당신의 구원이 될 것입니다. 둘 다 필요하면 fsck'd입니다.

---

분산 시스템이 신뢰할 수있는 복사본을 허용하지 않는다고 생각하는 사람들에게는 분산 시스템에 신뢰할 수있는 복사본이있는 곳이 많이 있다는 점에 유의하십시오. 완벽한 예는 Linus의 커널 트리 일 것입니다. 물론 많은 사람들이 자신의 나무를 가지고 있지만 거의 모두가 Linus의 나무로 흐릅니다.

그것은 분산 된 SCM이 다른 일을하는 많은 개발자들에게만 유용하다고 생각하는데 사용했지만 최근에는 중앙 집중식 저장소가 분산 저장소를 더 잘 할 수 있다고 결정했습니다.

예를 들어, 자신의 개인 프로젝트에서 일하는 솔로 개발자라고 가정 해보십시오. 중앙 집중식 저장소가 당연한 선택 일 수 있지만이 시나리오를 고려하십시오. 네트워크 액세스 (비행기, 공원 등)에서 멀리 떨어져 있고 프로젝트 작업을 원합니다. 로컬 사본을 가지고 있으므로 제대로 작업 할 수 있지만 한 기능을 완료하고 다른 기능으로 이동하거나 수정해야 할 버그를 발견했기 때문에 실제로 커밋하고 싶습니다. 요점은 중앙 집중식 리포지토리를 사용하면 모든 변경 사항을 함께 매쉬하고 비논리적 변경 집합에서 커밋하거나 나중에 수동으로 분할하게된다는 것입니다.

분산 리포지토리를 사용하면 평소와 같이 업무를 수행하고, 커밋하고, 이동합니다. 다시 넷 액세스 권한을 갖게되면 "하나의 진정한 리포지토리"로 푸시하고 아무것도 변경되지 않습니다.

분산 리포지토리에 대한 다른 좋은 점은 말할 것도없고 항상 사용 가능한 전체 기록입니다. 네트워크에서 멀리 떨어져있을 때 개정 로그를 확인해야합니까? 버그가 어떻게 도입되었는지 확인하려면 소스에 주석을 달아야합니까? 분산 저장소로 모두 가능합니다.

분산 형 vs 중앙 집중 형이 소유권이나 권위있는 복사본 또는 이와 유사한 것이라고 믿지 마십시오. 분산 현실은 SCM 진화의 다음 단계입니다.

---

실제로 비교는 아니지만 큰 프로젝트가 사용하는 것은 다음과 같습니다.

중앙 집중식 VCS

• 파괴

  Apache, GCC, Ruby, MPlayer, Zope, Plone, Xiph, FreeBSD, WebKit, ...

• CVS

  CVS

분산 VCS

• 자식

  Linux 커널, KDE, Perl, Ruby on Rails, Android, Wine, Fedora, X.org, Mediawiki, Django, VLC, Mono, Gnome, Samba, CUPS, GnuPG, Emacs ELPA ...

• 수은 (hg)

  Mozilla 및 Mozdev, OpenJDK (Java), OpenSolaris, ALSA, NTFS-3G, Dovecot, MoinMoin, mutt, PETSc, Octave, FEniCS, Aptitude, Python, XEmacs, Xen, Vim, Xine ...

• bzr

  Emacs, Apt, Mailman, MySQL, Squid 등도 Ubuntu 내에서 홍보되었습니다.

• darcs

  ghc, ion, xmonad, ... Haskell 커뮤니티에서 인기가 있습니다.

• 화석

  SQLite

---

W. Craig Trader 는 DVCS 및 CVCS에 대해 다음과 같이 말했습니다.

둘 다 필요하면 fsck'd입니다.

나는 둘 다 사용할 때 당신이 fsck'd 라고 말하지 않을 것 입니다. 실제로 DVCS 도구를 사용하는 개발자는 일반적으로 변경 사항을 중앙 위치 (일반적으로 릴리스 저장소의 릴리스 브랜치)에 병합 (또는 풀 요청 전송)하려고합니다. DVCS를 사용하는 개발자에게는 아이러니가 있지만 결국 중앙 집중식 워크 플로를 고수하면 분산 방식이 실제로 중앙 집중식보다 나은지 궁금해 할 수 있습니다.

DVCS는 CVCS에 비해 몇 가지 장점이 있습니다.

• 고유하게 인식 할 수있는 커밋이라는 개념으로 인해 피어간에 패치를 쉽게 보낼 수 있습니다. 즉, 패치를 커밋으로 만들고이를 필요로하는 다른 개발자와 공유합니다. 나중에 모든 사람이 함께 병합하려고 할 때 해당 특정 커밋이 인식되고 분기간에 비교할 수 있으므로 병합 충돌 가능성이 줄어 듭니다. 개발자는 사용하는 버전 관리 도구에 관계없이 USB 스틱이나 전자 메일을 통해 서로에게 패치를 보내는 경향이 있습니다. 불행히도 CVCS의 경우 버전 제어는 커밋을 개별적으로 등록하여 변경 사항이 동일하다는 것을 인식하지 못하여 병합 충돌 가능성이 높아집니다.

• 다른 사람에게 보여줄 필요가없는 로컬 실험 분기 (복제 된 저장소도 분기로 간주 될 수 있음)를 가질 수 있습니다. 즉, 업스트림으로 푸시하지 않은 경우 주요 변경 사항이 개발자에게 영향을 미칠 필요가 없습니다. CVCS에서 여전히 브레이킹 체인지가있는 경우이를 수정하고 그때까지 변경 사항을 커밋 할 때까지 오프라인으로 작업해야 할 수 있습니다. 이 접근 방식은 버전 관리를 안전망으로 사용하는 목적을 효과적으로 무효화하지만 CVCS에서는 필수 악입니다.

• 오늘날의 세계에서 회사는 일반적으로 해외 개발자와 협력합니다 (또는 더 나은 경우에는 재택 근무를 원합니다). DVCS를 사용하면 모든 사람이 자신의 저장소를 가지고 있기 때문에 안정적인 네트워크 연결이 필요하지 않기 때문에 이러한 종류의 프로젝트에 도움이됩니다.

… 일반적으로 해결 방법이있는 몇 가지 단점 :

• Who has the latest revision? In a CVCS, the trunk usually has the latest revision, but in a DVCS it may not be plainly obvious. The workaround is using rules of conduct, that the developers in a project have to come to an agreement in which repo to merge their work against.

• Pessimistic locks, i.e. a file is locked when making a check-out, are usually not possible because of concurrency that may happen between repositories in DVCS. The reason file locking exists in version control is because developers want to avoid merge conflicts. However, locking has the disadvantage of slowing development down as two developers can't work on same piece of code simultaneously as with a long transaction model and it isn't full proof warranty against merge conflicts. The only sane ways regardless of version control is to combat big merge conflicts is to have good code architecture (like low coupling high cohesion) and divide up your work tasks so that they have low impact on the code (which is easier said than done).

• 독점 프로젝트에서 전체 저장소가 공개적으로 사용 가능 해지면 재앙이 될 것입니다. 불만을 품거나 악의적 인 프로그래머가 복제 된 저장소를 손에 넣는 경우 더욱 그렇습니다. 소스 코드 유출은 독점 기업에게 심각한 고통입니다. DVCS는 저장소를 복제하기 만하면되는 반면 일부 CM 시스템 (예 : ClearCase)은 해당 액세스를 제한하려고하므로이를 단순하게 만듭니다. 그러나 제 생각에는 회사 문화에 충분한 역기능이 있다면 전 세계의 버전 관리가 소스 코드 유출을 방지하는 데 도움이되지 않습니다.

---

올바른 SCM을 검색하는 동안 다음 링크가 큰 도움이되었습니다.

1. 더 나은 SCM 이니셔티브 : 비교 . 약 26 개의 버전 관리 시스템 비교.
2. Comparison of revision control software. Wikipedia article comparing about 38 version control systems covering topics like technical differences, features, user interfaces, and more.
3. Distributed version control systems. Another comparison, but focussed mainly on distributed systems.

---

To some extent, the two schemes are equivalent:

• A distributed VCS can trivially emulate a centralised one if you just always push your changes to some designated upstream repository after every local commit.
• A centralised VCS won't usually be able to emulate a distributed one quite as naturally, but you can get something very similar if you use something like quilt on top of it. Quilt, if you're not familiar with it, is a tool for managing large sets of patches on top of some upstream project. The idea here is that the DVCS commit command is implemented by creating a new patch, and the push command is implemented by committing every outstanding patch to the centralised VCS and then discarding the patch files. This sounds a bit awkward, but in practice it actually works rather nicely.

Having said that, there are a couple of things which DVCSes traditionally do very well and which most centralised VCSes make a bit of a hash of. The most important of these is probably branching: a DVCS will make it very easy to branch the repository or to merge branches which are no longer needed, and will keep track of history while you do so. There's no particular reason why a centralised scheme would have trouble with this, but historically nobody seems to have quite gotten it right yet. Whether that's actually a problem for you depends on how you're going to organise development, but for many people it's a significant consideration.

The other posited advantage of DVCSes is that they work offline. I've never really had much use for that; I mostly do development either at the office (so the repository's on the local network) or at home (so there's ADSL). If you do a lot of development on laptops while traveling then this might be more of a consideration for you.

There aren't actually very many gotchas which are specific to DVCSes. There's a slightly greater tendency for people to go quiet, because you can commit without pushing and it's easy to end up polishing things in private, but apart from that we haven't had very many problems. This may be because we have a significant number of open source developers, who are usually familiar with the patch-trading model of development, but incoming closed source developers also seem to pick things up reasonably quickly.

---

Distributed VCS are appealing in many ways, but one disadvantage that will be important to my company is the issue of managing non-mergable files (typically binary, e.g. Excel documents). Subversion deals with this by supporting the "svn:needs-lock" property, which means you must get a lock for the non-mergable file before you edit it. It works well. But that work-flow requires a centralised repository model, which is contrary to the DVCS concept.

So if you want to use a DVCS, it is not really appropriate for managing files that are non-mergable.

---

I have been using subversion for many years now and I was really happy with it.

Then the GIT buzz started and I just had to test it. And for me, the main selling point was branching. Oh boy. Now I no longer need to clean my repository, go back a few version or any of the silly things I did when using subversion. Everything is cheap in dvcs. I have only tried fossil and git though, but I have used perforce, cvs and subversion and it looks like dvcs all have really cheap branching and tagging. No longer need to copy all code to one side and therefore merging is just a breeze.

Any dvcs can be setup with a central server, but what you get is among other things

You can checkin any small change you like, as Linus says if you need to use more than one sentence to describe what you just did, you are doing too much. You can have your way with the code, branch, merge, clone and test all locally without causing anyone to download huge amount of data. And you only need to push the final changes into the central server.

And you can work with no network.

So in short, using a version control is always a good thing. Using dvcs is cheaper (in KB and bandwidth), and I think it is more fun to use.

To checkout Git : http://git-scm.com/
To checkout Fossil : http://www.fossil-scm.org
To checkout Mercurial : https://www.mercurial-scm.org

Now, I can only recommend dvcs systems, and you easily can use a central server

---

The main problem (aside from the obvious bandwidth issue) is ownership.

That is to be sure to different (geographic) site are not working on the same element than the other.

Ideally, the tool is able to assign ownership to a file, a branch or even a repository.

To answer the comments of this answer, you really want the tool to tell you who owns what, and then communicate (through phone, IM or mail) with the distant site.
If you have not ownership mechanism... you will "communicate", but often too late ;) (i.e.: after having done concurrent development on an identical set of files in the same branch. The commit can get messy)

---

For me this is another discussion about a personal taste and it's rather difficult to be really objective. I personally prefer Mercurial over the other DVCS. I like to write hooks in the same language as Mercurial is written in and the smaller network overhead - just to say some of my own reasons.

---

Everybody these days is on the bandwagon about how DVCSs are superior, but Craig's comment is important. In a DVCS, each person has the entire history of the branch. If you are working with a lot of binary files, (for example, image files or FLAs) this requires a huge amount of space and you can't do diffs.

---

I have a feeling that Mercurial (and other DVCS) are more sophisticated than the centralised ones. For instance, merging a branch in Mercurial keeps the complete history of the branch whereas in SVN you have to go to the branch directory to see the history.

---

Another plus for distributed SCM even in solo developer scenario is if you, like many of us out there, have more than one machine you work on.

Lets say you have a set of common scripts. If each machine you work on has a clone you can on demand update and change your scripts. It gives you:

1. a time saver, especially with ssh keys
2. a way to branch differences between different systems (e.g. Red Hat vs Debian, BSD vs Linux, etc)

---

W. Craig Trader's answer sums up most of it, however, I find that personal work style makes a huge difference as well. Where I currently work we use subversion as our One True Source, however, many developers use git-svn on their personal machines to compensate for workflow issue we have (failure of management, but that's another story). In any case. its really about balancing what feature sets make you most productive with what the organization needs (centralized authentication, for example).

---

A centralised system doesn't necessarily prevent you from using separate branches to do development on. There doesn't need to be a single true copy of the code base, rather different developers or teams can have different branches, legacy branches could exist etc.

What it does generally mean is that the repository is centrally managed - but that's generally an advantage in a company with a competent IT department because it means there's only one place to backup and only one place to manage storage in.

참고URL : https://stackoverflow.com/questions/111031/comparison-between-centralized-and-distributed-version-control-systems