'SVN Branch'에 해당되는 글 2건
- 2010.07.21 Subversion을 활용한 소스 관리 전략
- 2010.07.21 Eclipse에서 브랜칭, 태깅하기
- Subversion을 활용한 소스 관리 전략
- 日常茶飯事
- 2010. 7. 21. 17:38
- 소스 형상 관리를 하다보면 이런 경우가 많다.
현재 운영되고 있는 시스템인데 현업으로부터 빈번한 수정사항이 나와서 소스변경이 잦다.
가끔 개선사항으로 일정 기간이 소요되는 작업이 나오는데 소스를 로컬에서 관리한다.
Subversion을 소스 저장소로만 사용하고 있다.
Subversion의 기능을 좀더 활용해 보자.
아래와 같은 과정을 거치도록 한다.
* 메인 스트림은 trunk, 개발 스트림은 B1으로 이해하자.
1. 모든 소스를 형상관리 시스템에 올려서 동기화 시킨다.
2. 현재 소스가 운영되고 있는 소스와 동일하다. : R1 태깅
3. 2주일 정도의 작업량이 들어와서 소스를 수정해야 한다.
현재는 형상관리 시스템과 운영되고 있는 소스와 일치시키기 위해 개발되고 있는 소스는 개발자의 로컬에만 존재한다.
개발자 장비가 없으면 수정하던 작업이 진행이 안된다.
이건 문제가 있다.
4. 메인 스트림과 별도의 개발 스트림을 만든다. : B1 브랜칭
5. B1에서 개발을 진행한다. : 소스를 수정하고 커밋한다.
6. 개발 진행중에 현재 운영중인 시스템에서 버그가 발견된다.
trunk에서 버그가 발견된 것이다.
현재 운영중인 소스(2)를 가져온다. : R1으로 스위칭
별도의 프로젝트를 만들어서 가져와도 되지만 동일한 소스때문에 헷갈릴 수도 있다. 작업이 끝나면 소스는 하나만 유지하자.
7. R1에서 버그를 수정하고 테스트한다.
R1에서 커밋을 하려고 하면 태그를 수정하겠냐고 물어본다. 하면 안된다.
태그는 특정 시점에 대한 스냅샷이다.
R1을 바탕으로 B1 브랜치도 만들어졌다.
8. trunk로 스위칭해서 커밋한다.
9. trunk에서 수정된 소스를 B1에도 적용한다.
그래야 버그가 처리된 소스가 최종적으로 적용된다.
B1에서 URL을 trunk로 두고 머지한다. 소스가 충돌나면 해결하고 커밋한다.
10. R2 태깅, 운영계에 적용, 이제부터 운영되는 소스는 R2다.
11. 개발이 완료되었음. branch에서 커밋
12. 개발계에 B1 소스를 올린다.
- 메인 스트림에서 버그나 수정사항이 나오면 trunk에서 수정해서 B1으로 머지한다.
테스트되는 소스는 B1이지만 trunk와 동일한 소스이다. trunk의 수정사항이 모두 반영된 소스이다.
테스트하면서 나온 수정사항은 B1에서 수정한다.(이 때 최신 소스는 B1이다. 그리고 이것으로 테스트되어야 한다)
13. 테스트가 완료되면 trunk에서 URL을 B1으로 두고 머지하고 R3 태깅, 운영계에 적용
- 2010-07-22
문득 trunk에서 태깅을 해야 하나 하는 생각이 든다.
현재 운영되고 있는 소스는 trunk의 최신본(HEAD)이다.
마지막 태깅된 소스와 동일하다.
브랜칭을 하기 전의 태깅은 필수고 trunk에서 직접 소스를 수정해서 반영하는 경우도 있으므로 태깅은 필수다.
이제는 개발자들이 trunk에서 커밋을 마음놓고 해도 된다.
단, 테스트가 된 소스를 올려야겠지.
현재 운영되고 있는 시스템인데 현업으로부터 빈번한 수정사항이 나와서 소스변경이 잦다.
가끔 개선사항으로 일정 기간이 소요되는 작업이 나오는데 소스를 로컬에서 관리한다.
Subversion을 소스 저장소로만 사용하고 있다.
Subversion의 기능을 좀더 활용해 보자.
아래와 같은 과정을 거치도록 한다.
1. 모든 소스를 형상관리 시스템에 올려서 동기화 시킨다.
2. 현재 소스가 운영되고 있는 소스와 동일하다. : R1 태깅
3. 2주일 정도의 작업량이 들어와서 소스를 수정해야 한다.
현재는 형상관리 시스템과 운영되고 있는 소스와 일치시키기 위해 개발되고 있는 소스는 개발자의 로컬에만 존재한다.
개발자 장비가 없으면 수정하던 작업이 진행이 안된다.
이건 문제가 있다.
4. 메인 스트림과 별도의 개발 스트림을 만든다. : B1 브랜칭
5. B1에서 개발을 진행한다. : 소스를 수정하고 커밋한다.
6. 개발 진행중에 현재 운영중인 시스템에서 버그가 발견된다.
trunk에서 버그가 발견된 것이다.
현재 운영중인 소스(2)를 가져온다. : R1으로 스위칭
별도의 프로젝트를 만들어서 가져와도 되지만 동일한 소스때문에 헷갈릴 수도 있다. 작업이 끝나면 소스는 하나만 유지하자.
7. R1에서 버그를 수정하고 테스트한다.
R1에서 커밋을 하려고 하면 태그를 수정하겠냐고 물어본다. 하면 안된다.
태그는 특정 시점에 대한 스냅샷이다.
R1을 바탕으로 B1 브랜치도 만들어졌다.
8. trunk로 스위칭해서 커밋한다.
9. trunk에서 수정된 소스를 B1에도 적용한다.
그래야 버그가 처리된 소스가 최종적으로 적용된다.
B1에서 URL을 trunk로 두고 머지한다. 소스가 충돌나면 해결하고 커밋한다.
10. R2 태깅, 운영계에 적용, 이제부터 운영되는 소스는 R2다.
11. 개발이 완료되었음. branch에서 커밋
12. 개발계에 B1 소스를 올린다.
- 메인 스트림에서 버그나 수정사항이 나오면 trunk에서 수정해서 B1으로 머지한다.
테스트되는 소스는 B1이지만 trunk와 동일한 소스이다. trunk의 수정사항이 모두 반영된 소스이다.
테스트하면서 나온 수정사항은 B1에서 수정한다.(이 때 최신 소스는 B1이다. 그리고 이것으로 테스트되어야 한다)
13. 테스트가 완료되면 trunk에서 URL을 B1으로 두고 머지하고 R3 태깅, 운영계에 적용
여기서 중요한 점은 메인 스트림에서 변경되는 소스를 개발 스트림에도 적용을 한다는 것이다.
그리고 메인 스트림으로 반영하는 것은 운영계에 올리기 전에 한다.
운영계에 올리는 소스는 반드시 태그를 걸어 둔다.
그리고 메인 스트림으로 반영하는 것은 운영계에 올리기 전에 한다.
운영계에 올리는 소스는 반드시 태그를 걸어 둔다.
- 2010-07-22
문득 trunk에서 태깅을 해야 하나 하는 생각이 든다.
현재 운영되고 있는 소스는 trunk의 최신본(HEAD)이다.
마지막 태깅된 소스와 동일하다.
브랜칭을 하기 전의 태깅은 필수고 trunk에서 직접 소스를 수정해서 반영하는 경우도 있으므로 태깅은 필수다.
이제는 개발자들이 trunk에서 커밋을 마음놓고 해도 된다.
단, 테스트가 된 소스를 올려야겠지.
- Eclipse에서 브랜칭, 태깅하기
- 日常茶飯事
- 2010. 7. 21. 03:07
Merge하는 부분은 여기를 참고하는 것이 더 좋다.
지금 현재 개발 프로세스는 운영기에 소스를 적용한 뒤에 SVN 저장소에 커밋을 한다.
개발 브랜치를 따로 가져가서 소스를 관리하자.
- 먼저, 브랜치를 만든다.
Subversive를 사용하면 branches/가 이미 만들어져 있다.
브랜치 이름은 Trac 마일스톤 이름(또는 티켓 번호)과 동일하게 가져가면 좋을 거 같다.
- 브랜치에서 작업을 하고 커밋을 한다.
- 메인 스트림으로 돌아와서(Switch) 병합한다.(Merge)
URL은 수정 작업을 한 브랜치의 URL을 선택한다.1
리비전을 선택할 수도 있다.
- 충돌이 나는 경우 소스 비교가 제대로 되지 않으므로 주의한다.
소스를 검토해서 수정후 Mark as Merged를 하면 충돌 표시가 사라진다. 커밋한다.
trunk에 있는 소스 리비전은 47
그래서 Remote File에 보이는 리비전도 47이다.
branches에서 merge한 소스는 48이다.(int balance //branch)
Edit Conflicts를 하면 오른쪽 뷰어(Repository로 표시됨, 지금은 Remote File 47)는 다른 리비전을 보여주고 Working 소스는 현재의 리비전인 47을 보여주기 때문에 소스 비교하기가 힘들다.
직접 수정하는 것이 편하다.
- 자주 병합을 해서 빅뱅을 피하라고 함.
- Revert 기능을 이용하면 병합하기 전으로 되돌릴 수 있다.
- 특정 리비전에 의미있는 태깅을 할 수 있다.
지금 현재 개발 프로세스는 운영기에 소스를 적용한 뒤에 SVN 저장소에 커밋을 한다.
개발 브랜치를 따로 가져가서 소스를 관리하자.
- 먼저, 브랜치를 만든다.
Subversive를 사용하면 branches/가 이미 만들어져 있다.
브랜치 이름은 Trac 마일스톤 이름(또는 티켓 번호)과 동일하게 가져가면 좋을 거 같다.
- 브랜치에서 작업을 하고 커밋을 한다.
- 메인 스트림으로 돌아와서(Switch) 병합한다.(Merge)
URL은 수정 작업을 한 브랜치의 URL을 선택한다.1
리비전을 선택할 수도 있다.
- 충돌이 나는 경우 소스 비교가 제대로 되지 않으므로 주의한다.
소스를 검토해서 수정후 Mark as Merged를 하면 충돌 표시가 사라진다. 커밋한다.
그래서 Remote File에 보이는 리비전도 47이다.
branches에서 merge한 소스는 48이다.(int balance //branch)
Edit Conflicts를 하면 오른쪽 뷰어(Repository로 표시됨, 지금은 Remote File 47)는 다른 리비전을 보여주고 Working 소스는 현재의 리비전인 47을 보여주기 때문에 소스 비교하기가 힘들다.
직접 수정하는 것이 편하다.
- 자주 병합을 해서 빅뱅을 피하라고 함.
- Revert 기능을 이용하면 병합하기 전으로 되돌릴 수 있다.
- 특정 리비전에 의미있는 태깅을 할 수 있다.
- 이 경우는 메인 스트림(trunk)에서 로 입력한 브랜치를 가져오게 된다. [본문으로]
Recent comment