프로젝트가 주로 VS6으로 작성되었으나...
일부 모듈이 VS2003으로 작성되어 있다...
덕분에 일괄빌드/DailyBuild를 하려고 배치파일 작성하는데...
VS6도 설치해야 하고 SDK, DDK 도 설치해야 하는데...
VS2003까지 설치하기는 좀 뭐해서...

코드프로젝트를 뒤지는 중에 발견한거...
http://www.codeproject.com/macro/vsconvert.asp

그 밑에 리플로 달아놓은 어느 중국인이 만든 변환툴이...
사실 쓰기가 더 좋다는거!
http://www.csksoft.net/blog/post/UnPrjConvertor.html

ActiveX로 만든 프로젝트는 그래도 안바뀌네...아씨...

TRAC과 서브버전을 설치하여 사용하다보니...
각 파일들의 버전관리가 애매하다...

실시간 고객의 수정요구로 수정한 파일에 버전이 없다면 아무리 서브버전으로 소스관리를 잘 한다고 해도 그 파일을 다시 만들어 낼 소스코드를 찾을수 없다.

그래서 생각한 원칙은...

일단 수정해서 commit 을 할때는 resource.rc 파일의 버전을 1씩 증가시킨후 commit을 수행한다.
즉 3.0.0.1 과 같은 버전이 있어 수정을 하나라도 했다면 3.0.0.2 와 같이 수정한다.
이는 고객에게서 수정요구 사항이 들어와서 현장에서 패치(파일교체)를 수행해도 나중에 그 소스코드 찾는걸 쉽게 한다.

문제는 3.0.0.1121 와 같이 숫자가 크게 되는 경우는 어떻게 할까?
9999 즉 10000 이상이 되면 세번째 버전을 증가 시키는 방법등 여러가지 방법이 있겠다.

제품버전이 2.0 이라면
각 파일별 버전은 3.0.1.1231 와 같은 식으로 이루어 진다...
제품버전과 파일별 버전에 유사성 또는 통일성을 갖을수는 없을까?
아...코딩할 생각은 안하고 맨날 쓸데없는 생각만...
(다음주는 Daily Build 시스템을 구축해야 하는데....)

서브버전의 디렉토리 구조는

─┬──  trunk
   ├──  tags
   ├──  branches

위와 같은 구조로 나뉜다.

Tags는 릴리즈된 코드(적어도 외부에 한번이라도 공개된 코드)를 보관하면 된다.
(소스코드 전체가 보관되는게 아니니 용량 걱정 할 필요도 없고 버전만 확인하여 배포된 소스코드를 그대로 얻을수 있으니 편리하다)

문제는 Branches 의 용도인데...
"서브버전을 이용한 실용적인 버전관리" 에서는 릴리즈시(릴리즈 몇일전부터) trunk에서 분리해서 간단한 버그만 수정하여 trunk에서 작업은 그대로 계속진행하고 릴리즈 작업을 branches에서 진행하도록 한다 라고 조언한다.

그러면 테스트 삼아 작성되는 새로운 기능추가나 별도의 작업으로 진행되다 나중에 추가되는것들은 어떻게 진행되어야 할까?