최근들어 사내 Subversion 커밋요건이 강화되었다.
외부에 공개되어도 괜찮을 것이라 생각하여 간단히 기술하고 그 생각을 적어보고자 한다.

2월 21일 공지

1단계는 SVN 로그 입력이 전혀 안되어 있을 경우 Commit을 불허 합니다. 즉, 로그 입력을 안하면, Commit이 실패하게 됩니다.

2단계는 SVN 로그 입력시 리뷰자가 없을시에 Commit을 불허합니다. 리뷰는 생활화하셔야 됩니다. 단순히 보여주기 위한 리뷰가 되어서는 안됩니다. 따라서 소스 코드 수정시 리뷰가 반드시 진행되어야 하고, 그 이후에 Commit이 이루어 져야 합니다. 따라서 리뷰자가 로그상에 없다면 Commit을 실패하게 됩니다.

[실행 파일명][실행 파일의 버전][개발자 성명][BT:버그 번호]
[RV:Review 참석자][Review 날짜]


3월 14일 공지

일시 : 2006-03-16(목) 12:00

내용 : SVN 서버상의 BugTrack 번호 입력 여부 필터링

제한 사항 : 입력이 안되었을 시 해당 내용은 로그로 기록되고, 매달 1일 오전 1시를 기준으로 유닛장에게 메일을 이용하여 남겨진 로그 파일을 전송.


워낙 개발자들이 말을 안듣다보니 svn의 commit 훅을 이용하여 이러한 제한을 가하게 되는 것인데, 이것은 비단 말을 안듣기 때문에 이러하는 것이 아니라 습관이 안들어서 습관을 기르기 위한 것이라고 생각하면된다.

어쩌면 늦은 감이 있지만, 정말 잘하였다라고 생각한다.
(조 책임님, 화이팅입니다.)

컴파일러에게는 철저히 오류를 고쳐주듯이 svn에게도 철저히 지키면 된다.
이것이 개인이 일하는 것에서 팀이 일하는 것으로 바꿔가는 것이다. 조직력은 다른데서 나오는 것이 아니라 같은 방법으로 계속 훈련하여 개발 기간을 단축하고 조직을 효율적으로 운영하는데 있다. 그것은 인간적인 훈련보다는 기계화되고 시스템화된 방법으로 훈련하는 것이 가장 빠르다고 생각한다.
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
  1. wookay 2006.03.16 10:37 신고

    리뷰를 하면서 대화를 많이 할 수 있을거 같아 좋을것 같습니다.^^ 저두 커밋하고 찜찜한게 많더라구요.

    • 주인 2006.03.16 10:50 신고

      습관을 바꾸는 것은 괴로운 것이죠.
      특히나 팀의 습관을 바꾸는 것은 더욱 힘듭니다.
      이 사람들이 계속 같이 있는 것이라는 보장이 없으므로 그렇죠..

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

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

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

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

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

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

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

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

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

하지 않았나?

적어도 우리팀은 이제 이런 일은 없으니 안심하자. :)
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

+ Recent posts