Unreal Revision Control

언리얼 프로젝트 우하단 Revision Control 또는 Tools > Connect to Source Control...을 통해 소스 컨트롤러를 설정할 것

그래서 이렇게 Perforce를 선택하고, 다음과 같이 옵션을 넣어주면 됨

Use P4 Config = Perforce 환경변수를 .p4config 파일에서 자동으로 읽어오겠다는 옵션

Perforce는 두 가지 설정 방식이 있다고 함

A) 수동 입력 방식: Server, User, Workspace 직접 입력

B) .p4config 자동 방식: .p4config 파일 안에 P4PORT, P4USER, P4CLIENT 이런거 설정해서 언리얼/ CLI/ P4V가 자동으로 동일 설정을 사용하도록. 일단 난 저 파일을 세팅 안했던터라 껐음

Workspace = 폴더 이름 (로컬 폴더 경로 X)

Available Workspace = 정상 연결되면 자동으로 뜸

다하면 Accept Settings

그럼 이제 위와 같이 연결되었다고 뜨고, 파일에 변경사항이 있을 때 머 아이콘이랑 오른쪽 아래에 뜰거임

아님 우하단에 1 files needs to be check-out 이라는게 뜰지도

안뜨면 직접 view changes 들어가면 볼 수 있음

여기서 조은점.

change list를 구분할 수 있음. 그리고 따로 submit을 날릴 수 있음

이 변경 묶음들에 대해.. 

1) Submit Changelist = 이 changelist에 들어있는 파일들을 서버(depot)에 공식 반영

2) Validate Changelist = Submit 전에 문제 없는지 미리 검사 (충돌 가능성 등)

- changelist가 unsaved modifications를 포함하는지 알려줌

3) Revert Unchanged = 체크아웃했지만 실제로 내용이 안 바뀐 파일들만 되돌리기

- 실수로 여러 파일 체크아웃 시

- 열어보기만 했던 uasset 같은거 정리

4) Revert Files = 이 changelist에 들어있는 모든 변경을 취소 (depot 기준으로 되돌리기)

5) Shelve Files = 변경 내용을 서버에 임시 저장, 공식 반영(submit)은 아님

6) Edit Changelist = Changelist의 이름, 포함 파일, 파일 이동

- description도 여기에 정의

 

그리고 컨텐츠 브라우저에 뜨는건

red checkbox = I have this file checked out: 여기서는 source control에 연결된거니까 우클릭 > source control > check in을 할 수 있음. (submit just this one file, instead of that whole changelist), History도 볼 수 있고, Diff against depot은 현재 서버상태랑 비교 가능

 

---

Checkout = “이 파일 내가 수정하겠다고 서버에 선언”

Submit = “수정이 끝났고, 이걸 공식 버전으로 반영”

 

Mark for Add는 뭐지

“이 로컬 파일을 다음 Submit 때 Depot에 ‘새 파일’로 추가하겠다고 표시”

Checkout이 이미 Depot에 있는 파일을 수정 시작하는거라면 이건 새 파일에 대해 추적 시작

Git으로 비유하면 git add.. 그리고 Submit은 git commit

이름이 이런 이유는 perforce의 철학.. 이 단계에서는 의사 표시만 한다(표시만 해둔다, 실제 반영은 submit에서만)

언제쓰냐면.. 새로 만든 파일에 대해.

근데 p4 reconcile을 하면 이 명령이 자동으로 Add, Edit, Delete를 한 번에 마킹해줘서 수동으로 Mark for add를 거의 안 씀

 

Perforce의 기본 철학

파일은 기본적으로 읽기 전용
→ “수정하려면 먼저 허락(Checkout)을 받아라”

 

Checkout 어케하는지

언리얼에서는 파일을 수정하려는 순간 자동으로 Checkout됨

그래서 그냥 수정하면 언리얼이 자동으로 "p4 edit Aurora/Source/Aurora.cpp"을 호출

 

그럼 다른사람이 Checkout하면 어케되는지

파일 타입에 따라 다른데, filetype + lock 정책으로 제어

1) 바이너리 파일 (언리얼 에셋, uasset / umap)

: 기본동작은 Exclusive Checkout (단독 잠금)

=> 바이너리는 머지 불가능하기에 perforce는 사전 충돌 방지를 선택. A가 .uasset을checkout한 상태에서 B가 같은 파일을에 대해 checkout을 시도하면 불가능하고, File is already checkout out by A 일케 뜸. 선택지 : 기다린다 / A한테 Revert 요청 / A가 Submit 후 Sync

2) 텍스트 파일 (C++, ini 등)

: 기본동작은 Multiple Checkout 허용

=> 둘 다 수정 가능한데 Submit 순서가 중요. 늦게 submit한 사람이 충돌 발생하면 알아서 resolve (git과 동일)

 

Perforce에서 브랜치 개념

있긴한데 Git이랑 다름. 두 가지 방식이 있음

1) Classic Branch (옛날 방식, 거의 안 씀)

- p4 branch, 경로 매핑 기반, 관리 번거롭.....암튼 요즘 안쓴다고 하니 그만 알아봄

2) Stream

: Depot 내부의 구조화된 브랜치 시스템

main (stable)
 ├─ dev
 │   ├─ dev-audio
 │   ├─ dev-render
 │   └─ dev-gameplay
 └─ release

머 이런식으로 stream == branch라서 dev에서 작업하고 main으로 merge(integrate) 해주면 됨

 

다른 브랜치에서도 checkout이 적용되는지

: 다른 Stream(브랜치)에 있으면, 같은 파일이라도 Checkout은 서로 독립적으로 가능

stream은 단순한 참조가 아니라,,, 각 Stream = 서로 다른 Depot 경로임 (like this)

main: //depot/main/Aurora/Content/MyAsset.uasset
dev : //depot/dev/Aurora/Content/MyAsset.uasset

그래서 perforce 입장에서는 같은 이름이지만 서로 다른 파일..이라고 인식하고 checkout은 독립적으로 일어나지만

충돌은 머지할 때 발생할테니까

dev와 main에서 같은 에셋이 수정될 경우 바이너리면 어느 쪽을 쓸지 수동으로 선택해야하고, 텍스트면 merge/resolve

 

그럼 checkout이라는 개념이 있는 존재하는 이상 굳이 브랜치를 안나누고 하나로 하는게 잠글 수 있어서 좋은거 아닌가?

그렇긴 함. ( 에셋 충돌을 원천적으로 차단하고, 현재 누가 뭘 하는지 명확히 알 수 있음 )

근데 대규모면 병목, 실험적인 수정, 빌드 안정성 관리 등의 이슈로 stream이 필요하긴 함.

단일 Stream: Checkout = 팀 전체 영향
Stream 분리: Checkout = Stream 내부 영향

 

우리는 그냥 단일 스트림 쓰는걸로?