6. 언제 RCS를 사용해야 할까요 ?

6.1 RCS로 인한 파멸(?)

RCS를 사용함으로써 생길 수 있는 문제점이 무엇인지 알아봅시다.

• 프로그램을 잔뜩 고쳐서 ci를 하려고 했는데 잘못해서 co를 했더니 파일을 덮어 썼다. 그래서 고친게 말짱 도루묵이 되어 버렸다.
• branch 가 많아짐으로 인해 구조가 복잡해 졌다. 차라리 옛날처럼 temp1, temp2 하던 때가 더 편했다.
• 언제 ci를 하는지 모르겠다. 함수 몇 개 추가할 때마다 ci를 수행했더니 나중에 메시지 부분이 너무 많아서 눈에 거슬렸다. 그래서 메시지 몽땅 다 지우고 다시 버전 1.1부터 시작했다.
• lock 이란 것 때문에 복잡해 죽겠다. 자꾸 에러를 낸다. 흐...

대충 이런 것이 있지 않을까요. 버전을 제어한다는 것이 멋있는 것이기는 하지만 잘못하면 거의 망하죠. 일의 속도만 더 느려지고... 하지만 일단 익숙해지기만 하면 RCS의 고마움을 느끼게 될 껍니다.

6.2 RCS 사용의 기본적인 지침(guideline)

그럼 RCS를 사용함에 있어 무엇인가 지침이 없을까.. 잘 쓰시는 분들에겐 저의 말이 틀린 것처럼 들릴 수가 있습니다만... 그들 나름대로의 철학을 가지고 하시는 일이라서... 그럼 어떤 지침이 있는지 알아보죠.

RCS 에서 가장 중요한 것은 언제 ci, co를 하느냐 입니다. 여기에는 저의 아주 실력 좋은 선배님의 지침들을 제 나름대로 구성해서 적겠습니다.

ci의 시점

ci(check in)은 일반적으로 하나의 작업 단위로 이루어져야 한다. 작업 단위 라는 것이 완성이 되어야만 체크인을 하여야 한다는 것이다. 만약 작업 단위 별로 체크인을 하지 않고 무작위로 하게 되면 버전이라는 의미가 퇴색하게 되며, 자신도 헷갈릴 뿐 아니라, 이를 체크아웃 해서 사용하는 다른 공동 사용자(같이 프로그램을 개발하는 사람)에게 피해를 줄 수 있다는 것을 명시해야 한다. 여기서 작업 단위라는 것의 정의를 내려보기로 하죠.

1. 프로그램에서 드러난 논리적/물리적 오류(버그, bug)를 수정하고 정상적인 동작을 확인한 경우가 하나의 작업 단위이다. 따라서 체크인 한다.
2. 어떤 모듈의 인터페이스가 변경되어 이를 사용하는 다른 모듈에까지 영향을 미칠 경우에 바뀌게 되는 모든 모듈, 아님 이와 관련된 파일이 모두 하나의 작업 단위가 되게 한다. 즉, 인터페이스가 바뀐 부분을 체크인 하려면 이와 관련된 다른 곳도 적절하게 수정한 다음 체크인 하여야 한다. 그래야, 프로그램의 일관성을 유지할 수 있다.
3. 새로운 기능을 위해서 모듈에 인터페이스를 추가할 경우에 이 모듈의 선언부와 구현부가 하나의 작업 단위가 된다. 즉 새로운 기능이 완전하게 구현되었을 때 체크인을 한다.

co의 시점

co(check out)은 체크인과는 달리 원하는 버전을 가져오기만 하면 되므로 원본에 피해를 주지 않으므로 체크인에 비해서는 대단한 주의는 필요하지 않다. 다만 아래와 같은 경우는 일어나지 않도록 합시다.

1. 작업 중인 파일을 체크인 하지 않은 상태에서 이전 버전의 내용을 보기 위해 체크아웃 하는 경우가 있다. 이 경우 고친 부분이 다 날아가 버리므로 주의하자. co를 할 때는 항상 (경고)메시지에 주의를 기울여야 한다.
2. 변경된 모든 파일을 체크아웃 하지 않고 일부만 체크아웃 해서 컴파일할 경우 비정상적인 동작을 보이게 된다. 이럴 경우 자신은 분명히 맞게 프로그램을 짰는데 프로그램의 동작이 이상하기 때문에 컴파일러를 의심하게 되는 경우가 많다. (컴파일러가 잘못할 이유가 없다는 것을 항상 명심합시다.) 논리적인 실수도 아니고, 물리적인 실수도 아니기 때문에 에러를 찾기가 힘들죠.
3. 공동 작업자가 체크인 했다고 해서 자신이 무조건 체크아웃 해서는 안된다. 분명히 자신의 작업 진도에 맞추어 체크아웃을 해야 한다. 공동 작업자와의 충분한 대화가 필요할 것이다. rlog 나 rcsdiff를 사용해서 버전의 특징을 조사해 보는 것도 좋은 방법이다.