CVS로 협업중이고 branch를 한번도 하지 않았던 개발 프로젝트. ㅡ.ㅡ
글쓴이: wfellow / 작성시간: 화, 2006/01/10 - 6:45오후
오늘 연달아 질문만 올리네요. ㅡ.ㅡ 그래도 전에 답변 몇개 올렸었으니 용서를 바랍니다.
CVS를 이용하여 버전관리를 하는 프로젝트가 있는데, 당시 CVS의 branch기능을 잘 모르고 사용을 시작해서 모든소스의 버전이 Main Trunk에 버전 1.59, 1.230 이런식으로 넘버링이 되어 있습니다. 중간에 tag를 사용하여 한두번 끊어주긴 했었는데, 이제라도 제대로 Branch를 적용하려 합니다.
질문은 이겁니다. (현재 개발 프로젝트에 CVS를 사용하여 협업을 하신다면, 조언을 부탁드립니다.)
Branch의 기준이나 나름대로의 규칙을 세워 놓으신 것이 있으신지요?
ps: kldp의 CVS사용법 링크말고 실제 사용하시는 실제의 예를 듣고 싶습니다.
Forums:
Subversion에서의 branches의 사용 방법을 답으로 드려도 될
Subversion에서의 branches의 사용 방법을 답으로 드려도 될지 모르겠습니다.
branches는 대부분 테스트 용도로 사용되는 경로로 알고 있습니다.
혹은 Release직전 RC 버전을 테스트하는 용도로도 사용되고 있습니다.
그리고 프로젝트마다 다르지만
branches 디렉토리를 사용자별로 나누고 다시 각 테스트나 RC용으로 분리해서 사용하거나, 그냥 사용하는 경우도 있습니다.
그리고 이건 여담입니다만 제가 CVS에서 subversion으로 넘어오게된 근본적인 이유가 tags와 branches 개념이 까다롭다는 것이었습니다.
Subversion을 사용해보시면 tags, branches의 개념이 명백합니다.
Trac 프로젝트에서 branches 디렉토리를 사용하는 것입니다.
http://projects.edgewall.com/trac/browser/branches
이건 subversion 프로젝트에서 branches 디렉토리입니다.
http://svn.collab.net/viewcvs/svn/branches/
이건 TortoiseSVN 프로젝트에서 branches 디렉토리입니다.
ID와 password는 guest/guest 입니다.
http://tortoisesvn.tigris.org/svn/tortoisesvn/branches/
다시 한번 말씀드립니다.
CVS 사용하시다가 Subversion 사용하시면 정말 편하다고 생각하실겁니다. ^^;
저는 cvs만 써오고 있는데 subversion이 좋다고 해서갈려고
저는 cvs만 써오고 있는데 subversion이 좋다고 해서
갈려고 생각만 하고 있습니다.
제가 cvs에서 브랜칭을 쓰는 기준을 다음과 같습니다.
- 특정 버젼이 릴리스 되면 그 버젼은 브랜칭 시킨다.
- 그 이후에 다음 버젼에 포함될 새로운 기능들은
Main trunk 버젼에서 작업한다.
- 릴리스된 특정 버젼에서 버그가 발견될 경우
브랜칭 버젼에 고쳐서 테스트해서 핫픽스를 내보낸다.
- 다음 버젼을 릴리스할 시점에 이전 브랜칭 버젼을
Main trunk 버젼으로 merger하여서 Main버젼에
이전 버젼의 버그 fix 부분들을 자동 반영시킨다.
(merge를 쓰지 않으면 매 버그마다 브랜칭과 Main 버젼을
모두 고쳐야 하는 불편함이 있습니다..다른 버그 유발한 가능성이 크죠)
제 기준은 이까지인데 cvs 매뉴얼에 나온 내용하고 매우 유사하고
그런 용도로는 딱입니다.
여하튼, subversion이 하도 좋다고들 하셔서 기대가 큽니다.^^;;
권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -
브랜치의 사용이유를 생각하면 명백할 것 같습니다.브랜치는 브랜치 한
브랜치의 사용이유를 생각하면 명백할 것 같습니다.
브랜치는 브랜치 한 코드에서의 수정이 메인 브랜치의 것에 영향을 주지 않도록 해주는 것입니다.
따라서 이런 상황이 필요한 경우에 해주면 됩니다.
그렇기 때문에 spacelee님의 글에서 처럼 특정 릴리즈(사내 버그 테스트용 릴리즈, 베타 버전 릴리즈 등)와 함께 그 릴리즈를 브랜치를 하는 것이 보통입니다.
릴리즈를 한다고 해도 메인 브랜치에대한 개발이 중단되는 것은 아닙니다.
이것과 더불어 릴리즈에 대한 버그 발생으로 인해서 수정 사항이 발생합니다.
이런 경우 브랜치가 없다면 메인 브랜치에 대한 개발은 거의 중지될 수 밖에 없습니다.
메인 브랜치란것이 Trunks인가요?
위의 spacelee님의 글이 아주 정리가 잘 되었는데,
kimsk99님의 글을 보니 좀 헷갈립니다.
제 소견에 위의 글에서 메인 브랜치라고 한 것들이 정확히 말하면 main trunk라고 해야 맞는 표현이 적절한 것 같아보입니다.
KT하이텔, 앱스 개발자
회사에서 CVS를 사용중입니다.HEAD의 경우에는 기본적인 소스 관리
회사에서 CVS를 사용중입니다.
HEAD의 경우에는 기본적인 소스 관리 측면에서 유지를 시킵니다.
개발은 브렌치를 활용해서 개발을 하고 그런 후에 HEAD 에 머지를 하도록 합니다.
또한 여러개의 프로젝트가 시작되는 경우에 HEAD 에 기반 하여 브렌치를 나누어 주고 개발이 끝난후에 다시 머지를 하도록 합니다.
정식 릴리지를 내는 경우에는 HEAD 에서 버전을 하나 떠 놓기도 합니다.
여러개의 프로젝트가 많이 진행되면 약간은 머지의 문제가 발생하는데요, 그런경우 개발자 끼리 이야기해서 중재를 합니다.
아직까지 해결 하지 못한 부분이 하나 있습니다.
브렌치로 작업을 진행 했는데 HEAD 와 상이한 기능을 하는 경우가 발생을 하는 경우가 가장 큰 골치 꺼리더군요..
이런 경우 옵션 처리를 한다고는 하지만..
약간은 머리가 어지러울때가 있습니다.
결론적으로 작업 기준으로 브렌치를 생성 합니다.
머지는 각자 개발자가 합니다. 머지 한 걸 감시 지도 하는 사람은 따로 있습니다.
CVS 에 소스 관리 하시는 분이 따로 있습니다.
질문 주신 분의 답변에 해당하는 내용은 아니지만 하도 답답한 마음에 이렇
질문 주신 분의 답변에 해당하는 내용은 아니지만 하도 답답한 마음에 이렇게 덧글을 남깁니다.
저희 팀도 CVS에서 브랜치를 사용했으면 하지만 이런 저런 이유로 상당히 힘든 상태입니다.
쓰고 싶은데 익숙하지 않은 내용에 대한 반발과 과연 익숙해 질 때까지 버틸 수 있을지 등의 문제로 아직도 적용 못하고 버벅이고 있습니다.
가장 큰 문제가 릴리즈가 너무 잦다는 것입니다. 상용으로 돌고 있는 게임 서버 코드인데 거의 한달에 한 번씩 릴리즈가 됩니다. 새로운 게임 내용을 추가한다는 명목인데, 서버팀원으로는 제발 안했으면 좋겠습니다. 8)
게다가 릴리즈 바로 하루 전까지도 릴리즈 항목이 정해지지 않은 상태에서 테스트 후 잘 돌면 넣는 상황이라 릴리즈 브랜치를 언제 만들어야 할지도 난감한 상태입니다.
현재는 릴리즈 브랜치의 역할을 하는 로컬 버전을 놓고 거기에 추가하면서 작업을 하고 있기는 한데 예전 버전으로 완벽하게 복구할 수 없는 것, 실수로 로컬 버전을 날리면 복구할 수 없다는 것 등의 문제로 브랜치로 옮기고 싶은데, 실력부족에 설득도 잘 못하고, 아 싱숭생숭합니다.
그냥 넋두리로 생각해주세요.
한달에 한번이면 양호한것 같습니다. ^^;저희는 일주일에 2번도 릴리
한달에 한번이면 양호한것 같습니다. ^^;
저희는 일주일에 2번도 릴리즈됩니다. ㅠㅠ;
(사방으로 patch가 서로 왔다갔다 거리는데...
한 일주일 지나면 어느 버전에 어떤 기능이 패치가 되었는지 기억도 나지 않습니다. Log를 봐도 잘 이해가 안돼죠...)
CVS의 경우에는 모르겠지만,
Subversion의 경우에는 그냥 TortoiseSVN으로 복사하듯이 Drag&Drop하면 그냥 Branches가 만들어집니다.
그리고 삭제도 물론 쉽고요..
어차피 Subversion이 CVS와의 명령어 호환성을 염두에 두고 만들어졌으니 Subversion으로의 이동을 추천(강추)해 드립니다.
먼저 유용한 답변들을 주신 모든 분들께 감사를 드립니다. 위의 글들을 참
먼저 유용한 답변들을 주신 모든 분들께 감사를 드립니다. 위의 글들을 참고하여 저희 CVS의 릴리즈 체계에 반영을 하고자 합니다.(그냥 공표를 하고 나서 따르라고 하렵니다. 독재자!)
아직은 버전관리의 부분적인 방법으로서 svn을 사용하는 것보다는 cvs를 이용하는 것이 개발자들의 반발을 조금이나마 줄이는 것이라 판단되어 여러분이 강력추천해 주신 svn으로의 이전은 신중히 하려 합니다. 험한 시대의 샘플이 되기는 싫거든요^^
감사합니다.
ps: 특히 xster님의 답변이 찡합니다.
-----[꼬릿말 절취선 시작]-----
삽질전에 먼저 구글신께 기도하자.
-----[꼬릿말 절취선 끝]-----
정책이라면
정책이라면 정책인데, 사람마다, 회사마다 다를 수 있습니다.
보통 버전컨트롤 하는 이유중 하나가 여러개의 버전을 가져가야 하는 경웁니다.
트렁크는 항상 언제든 돌아가는 상태로 두고, 수정, 버그픽스, 새로운 feature 등 필요할 때마다 브랜칭합니다. 완성되면 트렁크에 머지하는데, 머지하기 전에 택을 두는것이 보통입니다. 즉, 항상 작업은 브랜치에서, 작업이 끝나면 트렁크에 택 달고 작업 머지 이것이 대략 바람직한 사용법이 아닐까 합니다.
참고로 현재 제가 작업하고 있는 소스트리는 약 200개의 택이 붙어있네요. 명명규칙은 릴리즈는 -release로 끝나고, 브랜치는 -branch로 끝나는 등 상식수준입니다.
위에서 자주 릴리즈 하는 이야기를 하셨는데, 릴리스 원하면 아무때나 해줍니다. 왜냐하면 트렁크는 항상 잘 돌아가는 상태기 때문에 누군가 새버전 원하면 릴리즈 합니다(공식 릴리즈와는 다를 수 있습니다).
약간 잘못되서
약간 잘못되서 수정합니다.
"브랜칭 -> 수정 -> 택 -> 머지"로 되어 있는데, "택 -> 브랜칭 -> 수정 -> 머지" 로 바꿉니다. 왜 그런지 아시면 버전컨트롤 하산하셔도 될 듯.
위 익명 약간
위 익명 약간 잘못되서 수정합니다. (같은 익명입니다 :)
"브랜칭 -> 수정 -> 택 -> 머지"로 되어 있는데, "택 -> 브랜칭 -> 수정 -> 머지" 로 바꿉니다. 왜 그런지 아시면 버전컨트롤 하산하셔도 될 듯.
[ 익명 capcha validation은 아직도 캐쉬 문제 있는 듯 ]
댓글 달기