GIT vs. Perforce- 2 개의 VCS가 들어올 것입니다… 하나는 떠날 것입니다

GIT vs. Perforce- 2 개의 VCS가 들어올 것입니다… 하나는 떠날 것입니다 [닫힘]

---

그래서 저는 직장에서 GIT를 판매하는 과정에 있습니다. 가장 먼저 필요한 것은 GIT가 이미 익숙한 일에서 더 낫다는 것을 모든 사람에게 설득하는 것입니다. 현재 Perforce를 사용하고 있습니다. 비슷한 판매를하는 다른 사람이 있습니까? 좋은 링크 / 조언이 있습니까?

가장 큰 장점 중 하나는 네트워크 연결이 끊어진 상태에서도 작업 할 수 있다는 것입니다. 또 다른 승리 IMO는 추가 / 체크 아웃이 처리되는 방식입니다. 더 많은 포인트를 환영합니다! 또한 총 10-20 명의 개발자가 있습니다.

---

Perl 5 인터프리터 소스 코드는 현재 Perforce에서 git로 변환하는 과정을 겪고 있습니다. 아마도 Sam Vilain의 git-p4raw수입업자가 관심을 가질 것입니다.

어쨌든 모든 중앙 집중식 VCS와 대부분의 분산 된 VCS에서 얻을 수있는 주요 승리 중 하나는 원시적이고 빠른 속도 입니다. 당신이 그것을 경험할 때까지, 단지 몇 분의 1 초만에 전체 프로젝트 역사를 가까이에 두는 것이 얼마나 자유 롭다는 것을 상상할 수 없습니다. 각 커밋에 대한 전체 차이를 포함하는 전체 프로젝트 기록의 커밋 로그를 생성하는 것도 몇 분의 1 초로 측정 할 수 있습니다. Git은 너무 빨라 모자가 날아갈 것입니다. 네트워크를 통해 왕복해야하는 VCS는 기가비트 이더넷 링크를 통해서도 경쟁 할 기회가 없습니다.

또한 git을 사용하면 커밋을 만들 때 신중하게 선택하는 것이 매우 쉬워 져 작업 복사본 (또는 단일 파일 내)의 변경 사항이 여러 커밋에 분산되고 필요한 경우 다른 분기에 분산 될 수 있습니다. 이를 통해 작업하는 동안 정신적 메모를 적게 할 수 있습니다. 작업을 신중하게 계획 할 필요가 없으며 어떤 변경 사항을 적용할지 미리 결정하고 다른 작업을 연기 할 수 있습니다. 원하는대로 변경할 수 있으며 커밋 할 때 거의 항상 아주 쉽게 풀 수 있습니다. 은닉 은 여기에서 매우 큰 도움이 될 수 있습니다.

나는 함께, 이러한 사실들로 인해 내가 git을 사용하기 전보다 자연스럽게 더 많은 집중 커밋을 만들 수 있음을 발견했습니다. 이는 결국 귀하의 기록을 일반적으로 더 유용하게 만들뿐만 아니라 .NET과 같은 부가 가치 도구에 특히 유용합니다 git bisect.

지금 당장 생각할 수없는 것이 더있을 것 같습니다. git에서 팀을 판매한다는 제안의 한 가지 문제는 위에서 언급했듯이 많은 이점이 상호 연관되어 있고 서로 플레이한다는 것입니다. 따라서 단순히 git의 기능 및 이점 목록을보고 그 방법을 추론하기가 어렵습니다. 워크 플로를 변경하고 어떤 변경 사항을 개선할지 결정합니다. 이를 고려하고 명시 적으로 지적해야합니다.

---

저는 직장에서 Perforce를 사용합니다. 코드 작업을 할 때 서버에 연결할 수없는 경우에도 버전 제어를 원하기 때문에 Git을 사용합니다. 아니요, 오프라인 작업을 조정하는 것은 동일하지 않습니다. 다음은 git이 큰 이점이되는 곳입니다.

1. 분기 속도-git은 최대 몇 초가 걸립니다.
2. 충돌-P4Merge의 자동 해결은 일주일 분량의 작업을 한 번 파괴했습니다. 그 이후로 병합 할 때 차라리 손으로 해결하고 싶습니다. Git에서 충돌에 대해 메시지를 표시하면 실제로 충돌입니다. 나머지 시간 동안 git은 문제를 올바르게 해결하고 많은 시간을 절약합니다.
3. 병합 추적-두 개의 다른 브랜치에서 지속적으로 병합을받는 한 브랜치가있는 경우, 이것이 perforce로 인해 얼마나 골치 아픈지 알 수 있습니다. git을 사용하면 git의 병합 결과가 실제로 조상을 아는 새로운 커밋이기 때문에 두통이 최소화됩니다.
4. 권한-파일 작업을 시도한 횟수를 추적하지 못했지만 Perforce에서 체크 아웃되지 않았기 때문에 할 수 없습니다. 오프라인에서 XCode (또는 견고한 Perforce SCM 플러그인이없는 편집기)로 작업 한 경우 이것이 얼마나 짜증나게 할 수 있는지 알고 있습니다. Git에서는 그것에 대해 걱정할 필요가 없습니다. 변경합니다. Git은 나를 멈추지 않고 백그라운드에서 추적합니다.
5. 메인 트리를 깔끔하게 유지하기-git을 사용하면 커밋을 정렬하고 코드를 정리하여 히스토리가 멋지고 깔끔하게 보이도록 할 수 있습니다. "이전 체크인의 일부 여야했기 때문에이 파일을 체크인하는"쓰레기는 없습니다. 아무도 도와주지 않기 때문에 그런 커밋을 스쿼시합니다.
6. 스 태싱-p4 shelve 명령을 사용하려면 perforce 서버 버전이 2010.1 이상이어야합니다.
7. 패치 만들기-git에서 쉽게 할 수 있습니다. 명령 줄을 사용하지 않고 Perforce에서 가능한지 알 수 없습니다.
8. GUI에서 패치를 메일 링합니다. 여기서도 git이 이깁니다.
9. 디스크 공간-Perforce를 사용하면 모든 분기가 복사본입니다. 즉, 소스 트리가 크면 디스크 공간이 빨리 소모됩니다. 건물을 짓기 시작하면 추가 공간을 계산하지 않습니다. 왜 분기와 디스크 공간 사이에 링크가 있습니까? git을 사용하면 100 개의 분기를 가질 수 있으며 한 번에 하나의 분기 만 존재합니다. 특별히 두 가지 버전에서 동시에 작업하려면 복제하고 작업을 수행 한 다음 원하는 경우 아무것도 잃지 않고 하나의 복제본을 제거 할 수 있습니다.
10. XCode4를 사용하는 경우 perforce 지원이 중단되고 이제 git 지원이 기본 제공됩니다. 저처럼 크로스 플랫폼 작업을 수행하는 경우 이것은 매우 중요합니다. Visual Studio에서는 git 확장을 사용할 수 있습니다. perforce를 사용하면 두 OS에서 똑같이 유쾌합니다. 음, 이제 XCode4가 현장에있는 Mac에서 조금 더.
11. 잘못된 체크인 (또는 git bisect 규칙) 찾기-버그가 도입 된 위치를 파악하기 위해 perforce로 바이너리 검색을 시도한 적이 있습니까? 꽤 번거롭지 않습니까? 중간에 다른 지점의 통합이 있으면 훨씬 더 번거 롭습니다. 왜? 그러한 작업에 대한 자동화가 없기 때문입니다. perforce와 대화하려면 자신 만의 도구를 작성해야하며 일반적으로 시간이 없습니다. git을 사용하면 시작 지점 ( "좋은"지점과 "나쁜"지점)을 제공하고 검색을 자동화합니다. 더 좋은 점은 빌드 및 테스트 프로세스를 자동화 할 수있는 스크립트가있는 경우 git을 스크립트에 연결할 수 있으며 체크인을 찾는 전체 프로세스가 자동화됩니다. 그렇게되어야합니다.
12. 리팩터링에서 변경 사항 추적-BigClass를 SmallClass1 및 SmallClass2로 분할 해보십시오. Perforce에게 BigClass는 이제 더 이상 존재하지 않으며 두 개의 새로운 클래스 (SmallClass1 및 SmallClass2가 소스 트리에 합류했습니다). Perforce에는 BigClass와 SmallClass1 및 SmallClass2 사이에 관계가 없습니다. 반면 Git은 BigClass의 x %가 이제 SmallClass1에 있고 BigClass의 y %가 SmallClass2에 있고 BigClass가 더 이상 존재하지 않는다는 것을 알 수있을만큼 똑똑합니다. 이제 여러 지점에서 변경 사항을 검토하는 사람의 관점에서 Git 또는 Perforce 중 더 유용하다고 생각되는 접근 방식을 알려줍니다. 개인적으로 나는 Git의 접근 방식이 코드의 실제 변경 사항을 더 정확하게 반영하기 때문에 선호합니다. Git은 파일 자체가 아닌 파일 내의 내용을 추적하기 때문에이를 수행 할 수 있습니다.
13. 중앙 집중식 또는 분산 형 : Git은 DVCS 시스템이고 perforce는 중앙 집중식입니다. 중앙 집중식 VCS는 나중에 분산 될 수 없지만 DVCS (특히 git)는 중앙 집중화 될 수 있습니다. 비즈니스에 필요한 경우 git에 매우 세밀한 액세스 제어를 추가하는 여러 제품이 있습니다. 개인적으로 장기적으로 더 큰 유연성을 제공하는 시스템을 선택하겠습니다.
14. 분기 매핑 : Perforce에서 바로 분기를 수행하려면 분기 매핑을 생성해야합니다. 여기에는 이유가 있지만 Perforce가 분기를 개념화하는 방법과 관련이 있습니다. 개발자 또는 팀으로서 이것은 단순히 작업 흐름에서 한 단계 더 나아가는 것을 의미하며 전혀 효율적이라고 생각하지 않습니다.
15. 팀 간 작업 공유 : Perforce를 사용하면 제출물을 분리 할 수 ​​없습니다. A 팀은 기능 A를, B 팀은 기능 B를, C 팀은 버그 수정 작업을하고 있습니다. 이제 Teams A와 B는 기능을 구현하기 위해 많은 버그를 수정해야합니다. 유일한 것은 변경 사항을 커밋 할 때 (아마도 기한에 이르렀 기 때문에) 그렇게 규율을받지 않았기 때문에 "버그 수정"은 버전 제어에 관한 새로운 내용도 포함하는 대규모 제출의 일부입니다. 가지가 우려됩니다. 그러나 팀 C는 현재 포인트 릴리스를 수행하고 있으며 다른 팀에서 버그 수정을 받고 싶습니다. Git을 사용하는 경우 C 팀은 다른 팀의 관련 변경 사항을 선택하고 분할하여 부분적으로 구현 된 기능을 도입 할 걱정없이 필요한 것만 가져올 수 있습니다. Perforce를 사용하면
16. 플랫폼 변경-미래에 어떤 이유로 든 Perforce를 사용하여 선택한 플랫폼을 변경하기로 결정한 경우 Perforce.com과 선택한 플랫폼 용 도구를 사용할 수 있습니다.
17. 미래의 놀라운 소스 제어 엔진 X로 변경-소스 제어에 사용하는 것을 변경하기로 결정한 경우 Perforce에서 소스 제어 기록을 추출하여 새로운 시스템 X로 옮기는 것은 악몽이 될 것입니다. 당신이 할 수있는 것은 추측입니다-Perforce에서 Git으로의 마이그레이션을 위해 Google을 사용하여 제가 말하는 내용을 이해하십시오. 적어도 오픈 소스 인 Git을 사용하면 관련된 많은 추측을 제거합니다.

글쎄, 그것은 내 2 센트입니다. Perforce의 방어에서 저는 고객 지원 규칙을 말해야하며 타임 랩스보기 도구도 마찬가지입니다. git로 타임 랩스 뷰를 얻는 방법을 모르겠습니다. 그러나 편리함과 시간 절약을 위해 나는 언제든지 git과 함께 갈 것입니다.

---

perforce에서 전환하려면 많은 설득력이 필요합니다. 두 회사에서 나는 그것을 사용하기에 충분했습니다. 둘 다 서로 다른 사무실을 가진 회사 였지만 사무실에는 충분한 인프라가 설치되어있어 분리 / 분리 기능을 가질 필요가 없었습니다.

얼마나 많은 개발자가 전환에 대해 이야기하고 있습니까?

진짜 질문은-git이 제공 할 수있는 조직의 요구 사항을 충족하지 못하는 perforce에 대한 것은 무엇입니까? 마찬가지로 git이 perforce에 비해 어떤 약점을 가지고 있습니까? 직접 대답 할 수없는 경우 여기에서 요청해도 도움이되지 않습니다. 회사의 비즈니스 사례를 찾아야합니다. (예 : 전체 소유 비용이 낮을 수 있습니다 (중간 학습 단계의 생산성 손실, 높은 관리 비용 (적어도 초기) 등).)

나는 당신이 힘든 판매를하고 있다고 생각합니다-perforce는 대체하려고 시도하기에 꽤 좋은 것입니다. pvc 또는 안전 장치를 부팅하려는 경우 생각할 필요가 없습니다.

---

전환 후 / 전환 후 사람들을 행복하게 유지하는 측면에서 초기에 접해야 할 사항 중 하나는 로컬 브랜치가 Git에 얼마나 비공개가 될 수 있는지, 그리고 실수를 할 수있는 자유가 얼마나 많은지입니다. 그들 모두가 현재 코드에서 몇 개의 비공개 브랜치를 복제하도록 한 다음 거기에서 실험을 진행합니다. 일부 파일의 이름을 바꾸고, 항목을 체크인하고, 다른 브랜치에서 항목을 병합하고, 기록을 되 감고, 한 세트의 변경 사항을 다른 세트 위에 리베이스하는 등의 작업을 수행합니다. 그들의 최악의 사고조차도 동료들에게 영향을 미치지 않는 방법을 보여줍니다. 개발자가 원하는 것은 개발자가 안전하다고 느끼고 더 빠르게 학습 할 수 있고 (Git는 중요한 학습 곡선이 가파르 기 때문에) 결국 개발자로서 더 효과적 일 수있는 상황입니다.

중앙 집중식 도구를 배우려고 할 때 분명히 저장소의 다른 사용자에게 문제를 일으키는 일부 바보를 만드는 것에 대해 걱정할 것입니다. 난처함에 대한 두려움만으로도 사람들이 실험을하지 못하게 할 수 있습니다. 특별한 "교육"저장소가 있어도 도움이되지 않습니다. 개발자는 필연적으로 교육 중에 본 적이없는 프로덕션 시스템의 상황에 직면하게되어 다시 걱정하게됩니다.

그러나 Git의 분산 된 특성은이를 제거합니다. 지역 브랜치에서 어떤 실험이든 시도해 볼 수 있으며 끔찍하게 잘못되면 브랜치를 버리고 아무도 알 필요가 없습니다. 어떤 것이 든 로컬 브랜치를 생성 할 수 있기 때문에 실제 라이브 리포지토리에서보고있는 문제를 복제 할 수 있지만 "빌드를 깨뜨 리거나"자신을 속일 위험이 없습니다. 작업을 마치 자마자 깔끔한 작은 패키지로 일괄 작업하지 않고도 모든 것을 확인할 수 있습니다. 따라서 오늘 4 시간 동안 사용한 두 가지 주요 코드 변경 사항뿐만 아니라 중간에 기억했던 빌드 수정 사항과 동료에게 무언가를 설명하는 동안 발견 한 문서의 철자 오류 등이 있습니다. 그리고 프로젝트가 방향을 바꾸고 있기 때문에 주요 변경 사항이 취소되면

---

개인적으로 git에서 나를 팔 았던 명령은 bisect 였습니다. 이 기능은 현재로서는 다른 버전 관리 시스템에서 사용할 수 없다고 생각합니다.

즉, 사람들이 소스 제어를 위해 GUI 클라이언트에 익숙하다면 git에 깊은 인상을받지 못할 것입니다. 현재 모든 기능을 갖춘 유일한 클라이언트는 명령 줄입니다.

---

사람들이 사용하는 Perforce 기능은 무엇입니까?

• 단일 컴퓨터의 여러 작업 공간
• 번호가 매겨진 변경 목록
• 개발자 브랜치
• IDE와 통합 (Visual Studio, Eclipse, SlickEdit, ...)
• 많은 빌드 변형
• 복합 작업 공간
• 일부 수정 사항 통합
• 기타

모든 사람들이 명령 줄에서 가져 와서 놓는 것이면 git이이를 다루고 다른 모든 RTS도 마찬가지이기 때문에 묻습니다.

---

Apparently GitHub now offer git training courses to companies. Quoth their blog post about it:

I’ve been down to the Google campus a number of times in the last few weeks helping to train the Androids there in Git. I was asked by Shawn Pearce (you may know him from his Git and EGit/JGit glory – he is the hero that takes over maintanance when Junio is out of town) to come in to help him train the Google engineers working on Andriod in transitioning from Perforce to Git, so Android could be shared with the masses. I can tell you I was more than happy to do it.

[…]

Logical Awesome은 이제 공식적 으로 모든 회사에 이러한 유형의 사용자 지정 교육 서비스를 제공하고 있습니다. Git으로 전환하려는 경우 조직의 교육 및 계획을 지원할 수 있습니다.

내 강조.

---

저는 오랫동안 Perforce를 사용해 왔으며 최근에는 GIT도 사용하기 시작했습니다. 내 "객관적인"의견은 다음과 같습니다.

Perforce 기능 :

1. GUI 도구는 기능이 더 풍부한 것 같습니다 (예 : 타임 랩스보기, 개정 그래프)
2. 헤드 리비전 동기화시 속도 (전체 히스토리 전송 오버 헤드 없음)
3. Eclipse / Visual Studio 통합은 정말 좋습니다.
4. 변경 목록 당 하나의 브랜치에서 여러 기능을 개발할 수 있습니다 (GIT보다 이점이 있는지 아직 100 % 확신 할 수 없습니다).
5. 다른 개발자가 어떤 종류의 파일을 체크 아웃했는지 "스파이"할 수 있습니다.

GIT 기능 :

1. I got impressions that GIT command line is much simpler than Perforce (init/clone, add, commit. No configuration of complex Workspaces)
2. Speed when accessing project history after a checkout (comes at a cost of copying whole history when syncing)
3. Offline mode (developers will not complain that unreachable P4 server will prohibit them from coding)
4. Creating a new branches is much faster
5. The "main" GIT server does not need plenty of TBytes of storage, because each developer can have it's own local sandbox
6. GIT is OpenSource - no Licensing fees
7. If your Company is contributing also to OpenSource projects then sharing patches is way much easier with GIT

Overall for OpenSource/Distributed projects I would always recommend GIT, because it is more like a P2P application and everyone can participate in development. For example, I remember that when I was doing remote development with Perforce I was syncing 4GB Projects over 1Mbps link once in a week. Alot of time was simply wasted because of that. Also we needed set up VPN to do that.

If you have a small company and P4 server will be always up then I would say that Perforce is also a very good option.

---

We have been using Git for sometime, recently our Git server's harddrive crashed and we could not revert back to the latest state. We managed to get back to few days old state. When the server was back up. Everyone in the team pulled/pushed their changes and voila, the server is back to current state.

---

The one important difference between Perforce and git (and the one most commonly mentioned) is their respective handling of huge binary files.

Like, for example, in this blog of an employee at a video game development company: http://corearchitecture.blogspot.com/2011/09/git-vs-perforce-from-game-development.html

However, the important thing is that, the speed difference between git and perforce, when you have a huge 6gb repository, containing everything from documentation to every binary ever built (and finally, oh yes! the actual source history), usually comes from the fact that huge companies tend to run Perforce, and so they set it up to offload all significant operations to the huge server bank in the basement.

This important advantage on Perforce's part comes only from a factor that has nothing whatsoever to do with Perforce, the fact that the company running it can afford said server bank.

And, anyway, in the end, Perforce and git are different products. Git was designed to be solely a VCS, and it does this far better than Perforce (in that it has more features, which are generally easier to use, in particular, in the words of another, branching in Perforce is like performing open-heart surgery, it should only be done by experts :P ) ( http://stevehanov.ca/blog/index.php?id=50 )

Any other benefits which companies that use Perforce gain have come merely because Perforce is not solely a VCS, it's also a fileserver, as well as having a host of other features for testing the performance of builds, etc.

Finally: Git being open-source and far more flexible to boot, it would not be so hard to patch git to offload important operations to a central server, running mounds of expensive hardware.

---

I think the one thing that I know GIT wins on is it's ability to "preserve line endings" on all files, whereas perforce seems to insist on translating them into either Unix, Dos/Windows or MacOS9 format ("\n", "\r\n" or "\r).

This is a real pain if you're writing Unix scripts in a Windows environment, or a mixed OS environment. It's not even possible to set the rule on a per-file-extension basis. For instance, it would convert .sh, .bash, .unix files to Unix format, and convert .ccp, .bat or .com files to Dos/Windows format.

In GIT (I'm not sure if that's default, an option or the only option) you can set it up to "preserve line endings". That means, you can manually change the line endings of a file, and then GIT will leave that format the way it is. This seems to me like the ideal way to do things, and I don't understand why this isn't an option with Perforce.

The only way you can achieve this behavior, is to mark the files as binary. As I see that, that would be a nasty hack to workaround a missing feature. Apart from being tedious to have to do on all scripts, etc, it would also probably break most diffs, etc.

The "solution" that we've settled for at the moment, is to run a sed command to remove all carriage returns from the scripts every time they're deployed to their Unix environment. This isn't ideal either, especially since some of them are deployed inside WAR files, and the sed line has to be run again when they're unpacked.

This is just something I think gives GIT a great advantage, and which I don't think has been mentioned above.

EDIT: After having been using Perforce for a bit longer, I'd like to add another couple of comments:

A) Something I really miss in Perforce is a clear and instance diff, including changed, removed and added files. This is available in GIT with the git diff command, but in Perforce, files have to be checked out before their changes are recorded, and while you might have your main editors (like Eclipse) set up to automatically check files out when you edit them, you might sometimes edit files in other ways (notepad, unix commands, etc). And new files don't seem to be added automatically at all, even using Eclipse and p4eclipse, which can be rather annoying. So to find all changes, you have to run a "Diff against..." on the entire workspace, which first of all takes a while to run, and secondly includes all kind of irrelevant things unless you set up very complicated exclusion lists, which leads me to the next point.

B) In GIT I find the .gitignore very simple and easy to manage, read and understand. However, the workspace ignore/exclude lists configurable in Perforce seem unwieldy and unnecessarily complex. I haven't been able to get any exclusions with wildcards working. I would like to do something like

-//Server/mainline/.../target/...   //Svend_Hansen_Server/.../target/...

To exclude all target folders within all projects inside Server/mainline. However, this doesn't seem to work like I would have expected, and I've ended up adding a line for every project like:

-//Server/mainline/projectA/target/...  //Svend_Hansen_Server/projectA/target/...
-//Server/mainline/projectB/target/...  //Svend_Hansen_Server/projectB/target/...
...

And similar lines for bin folders, .classpath and .projet files and more.

C) In Perforce there are the rather useful changelists. However, assume I make a group of changes, check them all and put them in a changelist, to then work on something else before submitting that changelist. If I later make a change to one of the files included in the first changelist, that file will still be in that changelist, and I can't just later submit the changelist assuming that it only contains the changes that I originally added (though it will be the same files). In GIT, if you add a file and them make further changes to it, those changes will not have been added (and would still show in a git diff and you wouldn't be able to commit the file without first adding the new changes as well. Of course, this isn't usefull in the same way the changelist can be as you only have one set of added files, but in GIT you can just commit the changes, as that doesn't actually push them. You could them work on other changes before pushing them, but you wouldn't be able to push anything else that you add later, without pushing the former changes as well.

---

I have no experience with Git, but I have with Mercurial which is also a distributed VCS. It depends on the project really, but in our case a distributed VCS suited the project as basically eliminated frequent broken builds.

I think it depends on the project really, as some are better suited towards a client-server VCS, and others towads a distributed one.

---

Here's what I don't like about git:

First of all, I think the distributed idea flies in the face of reality. Everybody who's actually using git is doing so in a centralised way, even Linus Torvalds. If the kernel was managed in a distributed way, that would mean I couldn't actually download the "official" kernel sources - there wouldn't be one - I'd have to decide whether I want Linus' version, or Joe's version, or Bill's version. That would obviously be ridiculous, and that's why there is an official definition which Linus controls using a centralised workflow.

If you accept that you want a centralised definition of your stuff, then it becomes clear that the server and client roles are completely different, so the dogma that the client and server softwares should be the same becomes purely limiting. The dogma that the client and server data should be the same becomes patently ridiculous, especially in a codebase that's got fifteen years of history that nobody cares about but everybody would have to clone.

What we actually want to do with all that old stuff is bung it in a cupboard and forget that it's there, just like any normal VCS does. The fact that git hauls it all back and forth over the network every day is very dangerous, because it nags you to prune it. That pruning involves a lot of tedious decisions and it can go wrong. So people will probably keep a whole series of snapshot repos from various points in history, but wasn't that what source control was for in the first place? This problem didn't exist until somebody invented the distributed model.

Git actively encourages people to rewrite history, and the above is probably one reason for that. Every normal VCS makes rewriting history impossible for all but the admins, and makes sure the admins have no reason to consider it. Correct me if I'm wrong, but as far as I know, git provides no way to grant normal users write access but ban them from rewriting history. That means any developer with a grudge (or who was still struggling with the learning curve) could trash the whole codebase. How do we tighten that one? Well, either you make regular backups of the entire history, i.e. you keep history squared, or you ban write access to all except some poor sod who would receive all the diffs by email and merge them by hand.

Let's take an example of a well-funded, large project and see how git is working for them: Android. I once decided to have a play with the android system itself. I found out that I was supposed to use a bunch of scripts called repo to get at their git. Some of repo runs on the client and some on the server, but both, by their very existence, are illustrating the fact that git is incomplete in either capacity. What happened is that I was unable to pull the sources for about a week and then gave up altogether. I would have had to pull a truly vast amount of data from several different repositories, but the server was completely overloaded with people like me. Repo was timing out and was unable to resume from where it had timed out. If git is so distributable, you'd have thought that they'd have done some kind of peer-to-peer thing to relieve the load on that one server. Git is distributable, but it's not a server. Git+repo is a server, but repo is not distributable cos it's just an ad-hoc collection of hacks.

A similar illustration of git's inadequacy is gitolite (and its ancestor which apparently didn't work out so well.) Gitolite describes its job as easing the deployment of a git server. Again, the very existence of this thing proves that git is not a server, any more than it is a client. What's more, it never will be, because if it grew into either it would be betraying it's founding principles.

Even if you did believe in the distributed thing, git would still be a mess. What, for instance, is a branch? They say that you implicitly make a branch every time you clone a repository, but that can't be the same thing as a branch in a single repository. So that's at least two different things being referred to as branches. But then, you can also rewind in a repo and just start editing. Is that like the second type of branch, or something different again? Maybe it depends what type of repo you've got - oh yes - apparently the repo is not a very clear concept either. There are normal ones and bare ones. You can't push to a normal one because the bare part might get out of sync with its source tree. But you can't cvsimport to a bare one cos they didn't think of that. So you have to cvsimport to a normal one, clone that to a bare one which developers hit, and cvsexport that to a cvs working copy which still has to be checked into cvs. Who can be bothered? Where did all these complications come from? From the distributed idea itself. I ditched gitolite in the end because it was imposing even more of these restrictions on me.

Git says that branching should be light, but many companies already have a serious rogue branch problem so I'd have thought that branching should be a momentous decision with strict policing. This is where perforce really shines...

In perforce you rarely need branches because you can juggle changesets in a very agile way. For instance, the usual workflow is that you sync to the last known good version on mainline, then write your feature. Whenever you attempt to modify a file, the diff of that file gets added to your "default changeset". When you attempt to check in the changeset, it automatically tries to merge the news from mainline into your changeset (effectively rebasing it) and then commits. This workflow is enforced without you even needing to understand it. Mainline thus collects a history of changes which you can quite easily cherry pick your way through later. For instance, suppose you want to revert an old one, say, the one before the one before last. You sync to the moment before the offending change, mark the affected files as part of the changeset, sync to the moment after and merge with "always mine". (There was something very interesting there: syncing doesn't mean having the same thing - if a file is editable (i.e. in an active changeset) it won't be clobbered by the sync but marked as due for resolving.) Now you have a changelist that undoes the offending one. Merge in the subsequent news and you have a changelist that you can plop on top of mainline to have the desired effect. At no point did we rewrite any history.

Now, supposing half way through this process, somebody runs up to you and tells you to drop everything and fix some bug. You just give your default changelist a name (a number actually) then "suspend" it, fix the bug in the now empty default changelist, commit it, and resume the named changelist. It's typical to have several changelists suspended at a time where you try different things out. It's easy and private. You get what you really want from a branch regime without the temptation to procrastinate or chicken out of merging to mainline.

I suppose it would be theoretically possible to do something similar in git, but git makes practically anything possible rather than asserting a workflow we approve of. The centralised model is a bunch of valid simplifications relative to the distributed model which is an invalid generalisation. It's so overgeneralised that it basically expects you to implement source control on top of it, as repo does.

The other thing is replication. In git, anything is possible so you have to figure it out for yourself. In perforce, you get an effectively stateless cache. The only configuration it needs to know is where the master is, and the clients can point at either the master or the cache at their discretion. That's a five minute job and it can't go wrong.

You've also got triggers and customisable forms for asserting code reviews, bugzilla references etc, and of course, you have branches for when you actually need them. It's not clearcase, but it's close, and it's dead easy to set up and maintain.

All in all, I think that if you know you're going to work in a centralised way, which everybody does, you might as well use a tool that was designed with that in mind. Git is overrated because of Linus' fearsome wit together with peoples' tendency to follow each other around like sheep, but its main raison d'etre doesn't actually stand up to common sense, and by following it, git ties its own hands with the two huge dogmas that (a) the software and (b) the data have to be the same at both client and server, and that will always make it complicated and lame at the centralised job.

---

Using GIT as substitute for bad code line management is common. Many of the disadvantages of Perforce are a result of bad branching strategies. The same for any other centralized tool. If you have to create a ton of branches you are doing something wrong. Why do developers need to create so many branches?

Also, why is working disconnected so important anyway? Just so someone can work on a train? That's about the only place these days you can't get a wireless connection. And even most trains have decent WiFi.

참고URL : https://stackoverflow.com/questions/222782/git-vs-perforce-two-vcs-will-enter-one-will-leave