/pnotes/assets/2017-07-16-gdc13-working-together-solutions-for-collaborative-asset-creation-01.jpg

/pnotes/assets/2017-07-16-gdc13-working-together-solutions-for-collaborative-asset-creation-02.jpg

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

PART 1

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

/pnotes/assets/2017-07-16-gdc13-working-together-solutions-for-collaborative-asset-creation-03.jpg

/pnotes/assets/2017-07-16-gdc13-working-together-solutions-for-collaborative-asset-creation-04.jpg

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

/pnotes/assets/2017-07-16-gdc13-working-together-solutions-for-collaborative-asset-creation-05.jpg

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

/pnotes/assets/2017-07-16-gdc13-working-together-solutions-for-collaborative-asset-creation-06.jpg

/pnotes/assets/2017-07-16-gdc13-working-together-solutions-for-collaborative-asset-creation-07.jpg

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

/pnotes/assets/2017-07-16-gdc13-working-together-solutions-for-collaborative-asset-creation-08.jpg

/pnotes/assets/2017-07-16-gdc13-working-together-solutions-for-collaborative-asset-creation-09.jpg

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

/pnotes/assets/2017-07-16-gdc13-working-together-solutions-for-collaborative-asset-creation-10.jpg

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

/pnotes/assets/2017-07-16-gdc13-working-together-solutions-for-collaborative-asset-creation-11.jpg

/pnotes/assets/2017-07-16-gdc13-working-together-solutions-for-collaborative-asset-creation-12.jpg

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

/pnotes/assets/2017-07-16-gdc13-working-together-solutions-for-collaborative-asset-creation-13.jpg

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

/pnotes/assets/2017-07-16-gdc13-working-together-solutions-for-collaborative-asset-creation-14.jpg

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

/pnotes/assets/2017-07-16-gdc13-working-together-solutions-for-collaborative-asset-creation-15.jpg

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

/pnotes/assets/2017-07-16-gdc13-working-together-solutions-for-collaborative-asset-creation-16.jpg

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

PART 2

/pnotes/assets/2017-07-16-gdc13-working-together-solutions-for-collaborative-asset-creation-17.jpg

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

발표