소스 인덴테이션과 버전관리

최근 subversion 프로젝트에서 메인 개발자에 의한 code fork가 이루어지고 있는 것이 하나 있다.

Subversion with space라는 프로젝트인데, 이 코드 포크는 단지 함수호출시 사용되는 괄호 앞에 공백을 두는 것이 좋으냐를 가지고 일어난 것인데, 이것 때문에 수많은 커미터들의 코드를 예쁘게(?) 만든뒤 새로운 코드 저장소에 수동으로 반영한다는 것이다. 아직 소스에 접근이 불가능하여 릴리즈는 된 것 같지는 않다. 아니면, 이들이 재미로 하고 있던지..

관련 메일링리스트는
* [VOTE] space before paren policy
* [FORK] Subversion-With-Space

흔히, 커미터들에게 코드 작성 규칙을 엄격히 하고, 그 규칙대로 되어 있지 않은 코드를 수정해서 커밋하라고 하면 될텐데, 왜 이렇게까지 해야하나라고 생각하기 쉽다.

사내에서 진행되는 프로젝트들도 그렇게 취급하기 쉬울 것이다. 하지만 이들이 누구인가 코드를 관리하는 툴을 만드는 소스코드에 대한 것이 그렇게 쉽게 취급되지 않는다는 것은, 뭔가 철학이 있지 않을까이다.

1. 한 줄 한 줄이 커밋되는 순간 단 하나의 공백이 추가/삭제되어도 이는 변경이라 말한다.
2. 코드를 복사해야하는 이유가 있다면, 원본의 수정내역도 같이 복사되어야한다. 즉, 복사된 코드의 커밋에 히스토리가 없어져서는 안된다는 것이다.
3. 코드 관리는 각 줄이 모두 의미있는 커밋의 집합으로 이루어지므로 나중에 줄 별로 annotate(blame)해 볼 수 있어야한다.

이렇게 코드 변경을 중요시하는데, 공백이 하나 더 들어가서 생기는 변경으로 인해 그 라인의 중요한 히스토리를 숨기게 된다면, 즉 한 번더 확인해야 히스토리를 열람할 수 있게 된다면, 관리의 헛점이 생기는 것이다.

소스 관리는 이렇게 해야하는데, 우리는 과거에 흔히

1. 커밋로그 없이 커밋.
2. 전혀 의미 없는 것인데도 불구하고 주기적으로, 습관적으로 커밋.
3. 변경 내역이 여러개인데, 중요한 내용만 기록하여 커밋.

하지 않았나?

적어도 우리팀은 이제 이런 일은 없으니 안심하자. :)