Git 사용자를위한 Perforce?

Git 사용자를위한 Perforce? [닫은]

---

"Git for Perforce 사용자"문서는 많지만 그 반대는 거의 없습니다.

나는 이전에 Git 만 사용했으며 최근에는 Perforce를 많이 사용해야하는 작업을 시작했으며 많은 시간을 혼란스럽게 생각합니다. Git에서 익숙한 개념은 Perforce에 전혀 매핑되지 않는 것 같습니다.

Git에 익숙한 사람을 위해 Perforce를 사용하기위한 몇 가지 팁을 모으고 싶은 사람이 있습니까?

---

이것은 지난 몇 주 동안 계속해서 작업 한 것입니다. 여전히 발전하고 있지만 도움이 될 수 있습니다. 저는 Perforce 직원입니다.

Git 사용자를위한 Perforce 소개

Git에서 Perforce로 또는 Perforce에서 Git으로 이동하는 것이 쉽지 않다고 말하는 것은 큰 과소 평가입니다. 표면적으로 똑같은 일을하는 두 가지 도구이기 때문에 접근 방식이 더 다를 수 없습니다. 이 간단한 글은 Git에서 온 새로운 Perforce 사용자가 새로운 세계를 이해하도록 돕기 위해 노력할 것입니다.

우리가 뛰어 들기 전에 간단한 우회; Git을 선호한다면 Git을 Perforce와 함께 사용할 수 있습니다. Perforce 서버와 동기화 된 Git 리포지토리를 생성하는 Git Fusion이라는 도구를 제공합니다. Git과 Perforce 사람들은 동일한 코드를 사용하여 조화롭게 작업 할 수 있으며, 대부분 동료가 버전 관리를 선택해도 영향을받지 않습니다. Git Fusions 13.3은 Perforce 웹 사이트 에서 구할 수 있습니다 . Perforce 관리자가 설치해야하지만 설치하면 저장소 슬라이싱 기능이 Git 사용자에게 매우 유용 할 수 있습니다.

관리자가 Git Fusion을 설치하도록 설득력이 없다면 Git 자체에 Git-P4라는 Perforce 바인딩이 제공되어 Git을 사용하여 Perforce 작업 공간에서 파일을 변경하고 제출할 수 있습니다. 이에 대한 자세한 내용은 https://git.wiki.kernel.org/index.php/GitP4를 참조하십시오.

아직도 여기에? 좋아, 퍼 포스를 보자.

정리할 용어의 차이점

세부 사항에 들어가기 전에 Git과 Perforce의 몇 가지 용어 차이를 간략하게 다루어야합니다.

첫 번째는 결제 입니다. Git에서 이것은 주어진 브랜치에서 작업 영역으로 코드 사본을 얻는 방법입니다. Perforce에서는이를 명령 행 또는 GUI P4V "최신 개정 가져 오기"에서 동기화 라고합니다. Perforce는 P4V 또는 명령 행에서 checkout 이라는 단어를 사용하여 p4 edit버전 제어 시스템에서 파일을 변경할 계획임을 의미합니다. 이 문서의 나머지 부분에서는 Perforce라는 단어 의미에서 체크 아웃을 사용합니다.

두 번째는 Git commit 과 Perforce submit 이다. Git에서 커밋 할 곳은 Perforce로 제출합니다. 모든 작업은 공유 Perforce 버전 관리 서비스에 대해 수행되므로 Perforce에는 해당하는 기능이 없습니다 git push. 마찬가지로 우리는 없습니다 pull; 위의 sync 명령은 파일을 가져옵니다. 아래에 간략하게 설명 된 P4Sandbox 도구를 사용하도록 선택하지 않는 한 Perforce에는 순수 로컬 제출 개념이 없습니다.

Perforce의 주요 개념

Perforce를 두 가지 주요 개념으로 단순화하려면 저장소와 작업 공간에 중점을 둘 것입니다. Perforce 저장소는 Perforce 서버에있는 파일의 저장소입니다. Perforce 서버는 여러 저장소를 가질 수 있으며 각 저장소는 여러 파일을 포함 할 수 있습니다. Perforce 사용자가 저장소와 서버를 서로 바꾸어 사용한다는 말을 자주들을 수 있지만 서로 다릅니다. Perforce 사이트는 여러 서버를 선택할 수 있지만 가장 일반적으로 모든 파일은 하나의 서버에 있습니다.

Perforce 작업 공간 또는 클라이언트는 Perforce 서버의 파일 세트를 사용자 파일 시스템의 위치에 맵핑하는 시스템의 오브젝트입니다. 모든 사용자는 사용하는 각 머신에 대한 작업 공간을 가지고 있으며 종종 동일한 머신에 대해 둘 이상의 작업 공간을 갖습니다. 작업 공간의 가장 중요한 부분은 작업 공간 맵핑 또는보기입니다.

작업 공간보기는 로컬 시스템에 맵핑되어야하는 저장소의 파일 세트를 지정합니다. 서버에서 사용 가능한 모든 파일을 원하지 않을 가능성이 높으므로 중요합니다. 작업 공간보기를 사용하면 관심있는 세트 만 선택할 수 있습니다. 작업 공간은 여러 저장소의 컨텐츠를 맵핑 할 수 있지만 한 서버의 컨텐츠 만 맵핑 할 수 있다는 점에 유의해야합니다.

이와 관련하여 Perforce를 Git과 비교하려면 Git을 사용하여 관심있는 Git 저장소 세트를 선택하고 선택하십시오. 각 저장소는 일반적으로 관련 파일 만 포함하도록 엄격하게 지정됩니다. 이것의 장점은 사용자가 수행 할 구성이 없다는 것입니다. 당신은 당신이 관심있는 것들의 git clone을하고 당신은 끝났습니다. 하나 또는 두 개의 저장소로만 작업하는 경우 특히 좋습니다. Perforce를 사용하면 원하는 코드를 선택하고 선택하는 데 약간의 시간이 필요합니다.

많은 Perforce 상점은 작업 공간보기를 자동으로 생성하거나 스크립트 또는 템플릿 작업 공간을 사용하여보기를 생성 할 수있는 스트림을 사용합니다. 마찬가지로 많은 사람들이 자신의 작업 공간을 직접 생성하도록 사용자를 떠납니다. 하나의 작업 공간에 여러 모듈을 매핑 할 수 있다는 장점은 한 번의 체크인으로 여러 코드 모듈을 쉽게 수정할 수 있다는 것입니다. 체크인과 동기화 된 유사한 클라이언트보기를 가진 사람은 모든 코드가 올바른 상태에있게됩니다. 이것은 또한 지나치게 의존적 인 코드로 이어질 수 있습니다. Git을 강제 분리하면 모듈성이 향상 될 수 있습니다. 고맙게도 Perforce는 또한 엄격한 모듈성을 지원할 수 있습니다. 도구 사용 방법에 대한 질문입니다.

왜 작업 공간인가?

Git에서 나올 때 전체 작업 공간 개념이 가치있는 것보다 더 많은 어려움을 느끼는 것이 쉽다고 생각합니다. 약간의 Git 저장소를 복제하는 것과 비교할 때 이것은 의심의 여지없이 사실입니다. 작업 공간이 빛나고 Perforce가 몇 년이 지난 후에도 여전히 비즈니스에 종사하는 이유는 작업 영역이 개발자를 위해 수백만 개의 파일 프로젝트를 파싱하는 환상적인 방법이며, 여전히 모든 소스를 빌드 및 릴리스하기가 쉽지 않은 이유입니다. 하나의 권위있는 출처. 작업 공간은 Perforce가 확장 할 수있는 주요 이유 중 하나입니다.

작업 공간은 저장소의 파일 레이아웃과 사용자 시스템의 레이아웃이 필요할 경우 달라질 수 있다는 점에서 좋습니다. 많은 회사에서 회사 조직을 반영하도록 저장소를 구성하여 사람들이 사업 단위 나 프로젝트별로 컨텐츠를 쉽게 찾을 수 있도록합니다. 그러나 그들의 빌드 시스템은이 계층에 대해 덜 신경 쓰지 못했습니다. 작업 공간을 통해 도구에 적합한 방식으로 저장소 계층 구조를 다시 매핑 할 수 있습니다. 또한 코드가 인간에게 완전히 혼동되는 매우 구체적인 구성이어야하는 매우 융통성없는 빌드 시스템을 사용하는 회사에서 사용하는 것을 보았습니다. 이러한 회사는 작업 공간을 통해 사람이 탐색 할 수있는 소스 계층 구조를 보유하고 있으며 빌드 도구는 필요한 구조를 갖습니다.

Perforce의 작업 공간은 사용자가 작업하려는 파일 세트를 매핑하는 데 사용될뿐만 아니라 서버가 사용자가 동기화 한 각 파일의 개정을 정확하게 추적하는데도 사용됩니다. 이를 통해 시스템은 파일을 스캔하지 않고도 동기화 할 때 올바른 파일 세트를 사용자에게 전송하여 업데이트해야 할 파일을 확인할 수 있습니다. 많은 양의 데이터를 사용하면 성능이 크게 향상 될 수 있습니다. 이것은 또한 매우 엄격한 감사 규칙이있는 산업에서 매우 인기가 있습니다. Perforce 관리자는 어떤 개발자가 어떤 파일을 동기화했는지 쉽게 추적하고 기록 할 수 있습니다.

Perforce 작업 공간의 모든 기능에 대한 자세한 정보는 P4 구성을 참조하십시오 .

명시 적 체크 아웃 및 암시 적 체크 아웃

One of the biggest challenges for users moving from Git to Perforce is the concept of explicit checkout. If you are accustomed to the Git/SVN/CVS workflow of changing files and then telling the version control system to look for what you've done, it can be an extremely painful transition.

The good news is that if you so choose you can work with a Git style workflow in Perforce. In Perforce you can set "allwrite" option on your workspace. This will tell Perforce that all files should be written to disk with the writable bit set. You may then change any file you wish without explicitly telling Perforce. To have Perforce reconcile those changes you made you can run "p4 status". It will open files for add, edit, and delete as appropriate. When working this way you will want to use "p4 update" instead of "p4 sync" to get new revisions from the server; "p4 update" checks for changes before syncing so will not clobber your local changes if you haven't run "p4 status" yet.

Why Explicit Checkout?

A question I frequently receive is "why would you ever want to use explicit checkout?" It can at first blush seem to be a crazy design decision, but explicit checkout does have some powerful benefits.

One reason for using explicit checkout is it removes the need to scan files for content changes. While with smaller projects calculating hashes for each file to find differences is fairly cheap, many of our users have millions of files in a workspace and/or have files that are 100's of megabytes in size, if not larger. Calculating all the hashes in those cases is extremely time consuming. Explicit checkout lets Perforce know exactly which files it needs to work with. This behavior is one of the reasons Perforce is so popular in large file industries like the game, movie, and hardware industries.

Another benefit is explicit checkout provides a form of asynchronous communication that lets developers know generally what their peers are working on, or at least where. It can let you know that you may want to avoid working in a certain area so as to avoid a needless conflict, or it can alert you to the fact that a new developer on the team has wandered into code that perhaps they don't need to be editing. My personal experience is that I tend to work either in Git or using Perforce with allwrite on projects where I'm either the only contributor or an infrequent contributor, and explicit checkout when I'm working tightly with a team. Thankfully the choice is yours.

Explicit checkout also plays nicely with the Perforce concept of pending changelists. Pending changelists are buckets that you can put your open files into to organize your work. In Git you would potentially use different branches as buckets for organizing work. Branches are great, but sometimes it is nice to be able to organize your work into multiple named changes before actually submitting to the server. With the Perforce model of potentially mapping multiple branches or multiple projects into one workspace, pending changelists make it easy to keep separate changes organized.

If you use an IDE for development such as Visual Studio or Eclipse I highly recommend installing a Perforce plugin for your IDE. Most IDE plugins will automatically checkout files when you start editing them, freeing you from having to do the checkout yourself.

Perforce Replacements For Git Features

• git stash ==> p4 shelve
• git local branching ==> either Perforce shelves or task branches
• git blame ==> p4 annotate or Perforce Timelapse View from the GUI

Working Disconnected

There are two options for working disconnected from the Perforce versioning service (that's our fancy term for the Perforce server).

1) Use P4Sandbox to have full local versioning and local branching

2) Edit files as you please and use 'p4 status' to tell Perforce what you've done

With both the above options you can opt to use the "allwrite" setting in your workspace so that you do not have to unlock files. When working in this mode you will want to use the "p4 update" command to sync new files instead of "p4 sync". "p4 update" will check files for changes before syncing over them.

Perforce Quickstart

All the following examples will be via the command line.

1) Configure your connection to Perforce

export P4USER=matt
export P4CLIENT=demo-workspace
export P4PORT=perforce:1666

You can stick these settings in your shell config file, use p4 set to save them on Windows and OS X, or use a Perforce config file.

1) Create a workspace

p4 workspace

# set your root to where your files should live:
Root: /Users/matt/work

# in the resulting editor change your view to map the depot files you care about
//depot/main/... //demo-workspace/main/...
//depot/dev/...  //demo-workspace/dev/...

2) Get the files from the server

cd /Users/matt/work
p4 sync

3) Checkout the file you want to work on and modify it

p4 edit main/foo; 
echo cake >> main/foo

4) Submit it to the server

p4 submit -d "A trivial edit"

5) Run p4 help simple to see the basic commands that you will need to work with Perforce.

---

The biggest difference between git and p4, which none of the existing answers address, is that they use different units of abstraction.

• In git, the abstraction is the patch (aka diff, aka changeset). A commit in git is essentially the output of running diff between the previous and current state of the files being committed.
• In perforce, the abstraction is the file. A commit in p4 is the full content of the files in the commit at that point in time. This is organised into a changelist, but the revisions themselves are stored on a per-file basis, and the changelist simply collects different revisions of the files together.

Everything else flows from this difference. Branching and merging in git is painless because, from the perspective of git's abstraction, every file can be fully reconstructed by applying a set of patches in order, and therefore to merge two branches, you just need to apply all the patches on the source branch that aren't present in the target branch to the target branch in the correct order (assuming there are no patches on both branches that overlap).

Perforce branches are different. A branch operation in perforce will copy files from one subfolder to another, and then mark the linkage between the files with metadata on the server. To merge a file from one branch to another (integration in perforce terms), perforce will look at the complete content of the file at the 'head' of on the source branch and the complete content of the file at the head of the target branch and if necessary merge using a common ancestor. It is unable to apply patches one by one like git can, which means manual merges happen more often (and tend to be more painful).

---

There's probably not a lot of such documentation because Perforce is a pretty traditional revision control system (closer to CVS, Subversion, etc.) and normally is considered to be less complicated than modern distributed revision control systems.

Trying to map commands from one to the other is not the right approach; concepts from centralized vs. distributed revision control systems aren't the same. Instead, I'll describe a typical workflow in Perforce:

1. Run p4 edit on each file you want to edit. You need to tell Perforce which files you're editing. If you're adding new files, use p4 add. If you're deleting files, use p4 delete.
2. Make your code changes.
3. Run p4 change to create a changeset. Here you can create a description of your change and optionally add or remove files from your changeset too. You can run p4 change CHANGE_NUMBER to edit the description later if necessary.
4. You can make additional code changes if you need to. If you need to add/edit/delete other files, you can use p4 {add,edit,delete} -c CHANGE_NUMBER FILE.
5. Run p4 sync to pull in the latest changes from the server.
6. Run p4 resolve to resolve any conflicts from syncing.
7. When you're ready to submit your change, run p4 submit -c CHANGE_NUMBER.

You can use p4 revert to revert your changes to files.

Note that you can be working on multiple changesets simultaneously as long as none of their files overlap. (A file in your Perforce client can be open in only one changeset at a time.) This sometimes can be convenient if you have small, independent changes.

If you find yourself needing to edit files that you already have open in another changeset, you can either create a separate Perforce client or you can stash your existing changeset for later via p4 shelve. (Unlike git stash, shelving does not revert the files in your local tree, so you must revert them separately.)

참고URL : https://stackoverflow.com/questions/17267218/perforce-for-git-users