#gdc13 #review Working Together: Solutions for Collaborative Asset Creation

2017-07-16

No Locking 모델로 가야 모두 행복하다. merge conflicts로 고통받는 사람 빼고. merge conflict를 어떻게 해결할 수 있을까?

PART 1

merge는 피할 수 없다. 이런 결론은 내고 어떻게 하면 merge를 쉽게 할 수 있을까? 자동으로 할 수 있을까? 여기에 집중하는 게 인상적이다. 발표자료 논리 전개도 훌륭함.

동시 편집을 지원하는 자체 엔진을 사용한 적이 있다. DB로 VCS를 구현한 상태였다. 처음엔 merge conflicts가 없는 멋진 세상에 살고 있다고 생각했다. 하지만 version history, branch 등을 지원하다 보면 뭘 자꾸 조금씩 포기해야 한다. 아니면 결국 허접한 VCS를 다시 만들었을 뿐이다. merge conflicts는 다시 문제가 된다. 문제를 해결한 게 하나도 없다.

No Locking 모델에서는 merge를 피할 수 없다. 어떻게 하면 자동으로 할 수 있을까? 어떻게 하면 좀 더 쉽게 할 수 있을까?

왜 애샛은 머지가 힘든가? 소스 코드 머지는 잘하는데 말이야. 잘하고 있는 것과 비교하는 접근이 좋다. 여기에서 힌트를 많이 얻는다.

line-oriented data로만 바꿔도 머지 고통을 줄일 수 있다. 하지만 여기서 만족하진 않는다.

사실 우리가 해결하는 conflicts는 syntactic conflicts다. 만약 semantic merge가 가능하다면? 똑같은 property를 다른 값으로 수정하는 진짜 conflict를 제외하고는 자동으로 merge 할 수 있다. mana와 hp를 각각 추가했다면 둘 다 추가하면 된다.

data 머지를 바로 하지 말자. delta command를 머지 대상으로 본다.

변경인지 추가인지 구분하기 어려운 상황이 있어서 모든 object에 GUID를 추가한다. array는 머지가 힘들어 금지하고 set을 지원.

좋은 선택. 어느 세월에 다 만들고 있나.

진짜 conflict가 나타났다. 그냥 auto merge. 뭐 이것도 나쁘지 않다. VCS에서는 동시 commit이 없이 어떻게든 줄을 세워 줄 것이고 항상 뒤에 값으로 덮어쓰게 해도 문제는 없을 것 같다. merge conflict를 해결 안 하고 <<<<<< 이런 문자를 포함한 채 커밋하는 게 더 위험하긴 하다. 실행도 안 되고 프로그래머 분노까지 유발한다.

https://bitbucket.org/bitsquid/json_merger/

PART 2

이 생각을 못 했네. 동시 편집을 지원하려면 single shared ‘data world’ 역할을 하는 DB 같은 게 있어야 한다고 생각했었다. HOST 역할을 하는 사람이 커밋하고 이런 거 다 책임지면 간단히 해결되네.

발표

• 발표자: Niklas Frykholm (Bitsquid)
• 발표자료: github.com/niklasfrykholm/blog
• 발표영상: GDC Extras Archive - archive.org

• tags:
• gdc 51
• gdc13 17
• bitsquid 1
• asset 10