소스관리 및 자료관리에 관한 좋은 방법

간단합니다. 다른 사람들에게 CVS를 쓰게 할 수 있는 공식적인 권한이 있다면 잔소리하지 말고 그렇게 하라고 시키면 됩니다. :-)

그렇지 않다면 한 사람씩 밥 사줘가면서 설득을 해야겠지요. 단, 그렇게 시간과 돈과 노력을 들여서 결과적으로 사흘 밤 샐거 하루 밤 새는 걸로 줄일 수 있다는 확신이 들 때만 그렇게 하세요. 아무리 좋은 도구와 프로세스가 있다고 해도 사람들하테 그걸 납득시키고 쓰게 만드는 건 절대 쉬운 일이 아닙니다.

so called... 대학원코드군요. :D

컴맹과는 크게 관련이 없을것 같습니다. MyCluster님께서 박사 몇년차정도 되는 실질적인 랩짱이라고 가정할때 그냥 하라고 시키면 되겠지요. 하하...
전에 있던 회사에서 프로젝트를 하나 시작하면서 없던 cvs를 도입해 시작했는데, 다른 분들은 cvs를 처음 접하시는 분들이었지요. import 같은 것은 MyCluster님께서 직접 하시는 것이 안전할 것 같고, 다른 사용자분들께는... checkout과 commit의 개념만을 숙지시켜 사용할 수 있도록 하시는 것이 좋겠지요. 하지만 repository구조를 잘 만들어 import 하는 일 자체도 굉장한 스트레스가 됩니다. 특히 이렇게 몇년동안 개인 하드이곳저곳에 산재되어 있는 코드들이라면 aggeregator역할을 해야 하는 한명은 지독하게 골머리를 썩어야하겠지요.

나머지 팀원들이 전부 컴맹에 가깝다고 하시니 아마도 W2k나 Xp를 사용하시는 분들이 많을것이고, tortoisecvs 같은 gui 툴들을 사용하시면 좀 더 편리하지 않을까 합니다.

처음에 저희 팀에 도입했을 때에는 실질적으로 제가 대부분의 권한을 가질 수 있었기 때문에, 팀원들에게 cvs 세미나를 준비시키고, 레퍼지토리 구조를 짜거나 cvs서버를 셋업하는 일은 제가 다 마쳐놓고 시작했습니다. w2k에서 대부분 작업을 하는 팀원들이어서 wincvs와 tortoisecvs 를 편한대로 사용하라고 했었지요. 시간이 조금 지나가니 다들 컴맹들은 아니어서 vc++의 툴바로 올려서 알아서 잘 사용하더군요. 하지만 역시 cvs와 unix에 익숙하지 않다보니 몇가지 문제는 생깁니다. 예를 들면... 전통적인 commit시의 CR/LF문제나, *.o와 *.obj, 또는 빌드시에 생긴 .dep 따위를 전부 넣어버리는 일이 생긴다거나 하지요. cvsignore같은 것도 정책에 맞게 잘 정해주시는 것이 좋습니다.