'형상관리@'에 해당되는 글 11건
- 2011.08.03 svn:ignore에서 제외하기
- 2010.11.18 SVN 주석 규칙
- 2010.10.18 소스 병합(Merge) Tip
- 2010.07.23 형상관리 상황 보기 - Eclipse SVN Repository
- 2010.07.21 버전 관리에 대한 이것저것...
- 2010.07.21 Subversion을 활용한 소스 관리 전략
- 2010.03.25 미루던 일, SVN에서 소스 Checkout하기
- 2009.05.15 Eclipse - Maven Project를 Dynamic Web Project로 만들기
- 2009.05.02 Subversion 명령어
- 2009.02.04 Eclipse에서 Subversion 사용하기
- 2009.01.08 Subversion 관리
- svn:ignore에서 제외하기
- 日常茶飯事
- 2011. 8. 3. 02:29
todo=여기에 대한 정립을 하자. 결론은 .classpath를 잘 추가하면 된다. 그리고 .settings/도 올려야 함.
todo=svn사용시 제외 항목들(svn ignore)
target/
web-app/plugins/
web-app/WEB-INF/classes/ =todo
.classpath 파일을 svn:ignore에 포함시키면 안되는데 습관적으로 추가시켜 버렸다.
.classpath 파일을 형상관리하도록 다시 설정해야 함.
- Subclipse 기준
Team - Show Properties
svn:ignore 속성 변경후 commit ([todo] 이걸 먼저 add to version control 처리를 해야 하나?)
그리고 나서 update, commit
- 주석은 반드시 달아야 한다.
- 관련 티켓이 있으면 적어둔다(#ticket_no)
- 글머리를 이용한다.
- 관련 티켓이 있으면 적어둔다(#ticket_no)
- 글머리를 이용한다.
- [Branch] 새로운 브랜치를 시작하는 경우
- [Merge] 병합하는 경우, 어디와 어디를 병합했는지도 적는다.
예) [Merge] trunk를 B01 branch에 병합, B01 branch를 trunk에 병합 - [Tag]
예) [Tag] 운영계에 반영
- 소스 병합(Merge) Tip
- 日常茶飯事
- 2010. 10. 18. 22:38
1. 먼저 SVN Repositories에서 trunk의 History를 확인한다.
trunk의 변경사항을 알면 merge 작업시 도움이 된다.
(어떤 파일을 수정했는지)
2. 충돌난 소스를 확인한다. : 아주 많을것이다.
3. trunk에서 변경된 파일을 확인한다. : 이 부분은 branch에서도 같은 부분을 작업했을수도 있으므로 자세히 확인한다.
4. 나머지 충돌난 파일은 branch에서 작업한 내용이므로 한꺼번에 충돌을 해소해도 된다.(Edit Conflict, Mark as Merged)
- trunk에서는 존재하는 파일인데 branch에서 삭제한 파일은 추가된 이미지(
)로 보인다.
JEE Perspective에서 직접 삭제한다.
- Override and Update로 잘못 받은 파일은 Revert하면 된다.
(어차피 merge는 로컬에서만 발생하였다.)
- branch에서 어떤 부분을 수정했는지 보려고 할때 trunk와 머지해보면 알수 있다.
머지하면 로컬 소스가 변경되므로 Revert 기능으로 되돌리면 된다.
(이때 branch에서 삭제되어서 trunk와 머지하면 추가되는 파일은 Revert를 해도 안지워진다. 직접 지운다. 그리고 나서 branch와 동기화를 해본다.)
trunk의 변경사항을 알면 merge 작업시 도움이 된다.
(어떤 파일을 수정했는지)
2. 충돌난 소스를 확인한다. : 아주 많을것이다.
3. trunk에서 변경된 파일을 확인한다. : 이 부분은 branch에서도 같은 부분을 작업했을수도 있으므로 자세히 확인한다.
4. 나머지 충돌난 파일은 branch에서 작업한 내용이므로 한꺼번에 충돌을 해소해도 된다.(Edit Conflict, Mark as Merged)
- trunk에서는 존재하는 파일인데 branch에서 삭제한 파일은 추가된 이미지(
JEE Perspective에서 직접 삭제한다.
- Override and Update로 잘못 받은 파일은 Revert하면 된다.
(어차피 merge는 로컬에서만 발생하였다.)
- branch에서 어떤 부분을 수정했는지 보려고 할때 trunk와 머지해보면 알수 있다.
머지하면 로컬 소스가 변경되므로 Revert 기능으로 되돌리면 된다.
(이때 branch에서 삭제되어서 trunk와 머지하면 추가되는 파일은 Revert를 해도 안지워진다. 직접 지운다. 그리고 나서 branch와 동기화를 해본다.)
- 형상관리 상황 보기 - Eclipse SVN Repository
- 日常茶飯事
- 2010. 7. 23. 19:48
SVN을 trunk만 사용하다 branch와 tag를 사용하는데 어디가 최신 소스인지, 내가 작업을 해야 하는 곳인지 헷갈린다.
일반적으로 trunk가 최신 소스일거다.
특별한 작업이 있다면 branch가 있을거고.
SVN Repository를 보자.
리비전 608에서 태그를 달아서 610이 되었다.
아마도 trunk 608과 동일하겠지. 그후 trunk에서 변경사항이 없었다.
항상 여기서 확인하자.
- 소스 체크아웃할때도 여기에서 소스 위치와 WebContent 위치를 확인할 것.
- 프로젝트 생성시 web.xml 생성하지마.
- svn:ignore 반드시 설정할 것.
일반적으로 trunk가 최신 소스일거다.
특별한 작업이 있다면 branch가 있을거고.
SVN Repository를 보자.
아마도 trunk 608과 동일하겠지. 그후 trunk에서 변경사항이 없었다.
항상 여기서 확인하자.
- 소스 체크아웃할때도 여기에서 소스 위치와 WebContent 위치를 확인할 것.
- 프로젝트 생성시 web.xml 생성하지마.
- svn:ignore 반드시 설정할 것.
- 버전 관리에 대한 이것저것...
- 日常茶飯事
- 2010. 7. 21. 19:49
- 버전 관리되고 있는 파일을 버전 관리에서 제외하기 : 참고
- 동기화
- SVN Repository에서 해당 파일을 삭제한다.(서버)
- 로컬 개발 환경에서 해당 파일을 백업받아 둔다.
- SVN에서 update 받는다.
- 백업받아둔 파일을 다시 넣으면 svn:ignore 가 활성화된다.
- 커밋한다.
- Maven 또는 Ivy 로 관련 라이브러리를 관리하는 것도 좋겠다.
- 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에서 커밋을 마음놓고 해도 된다.
단, 테스트가 된 소스를 올려야겠지.
- 미루던 일, SVN에서 소스 Checkout하기
- 日常茶飯事
- 2010. 3. 25. 20:00
Trac 소스 브라우저로 소스를 검토함.
Eclipse로 받으면 되는데 귀찮아서 미루다가 오늘 함.
SVN Repository Exploring 퍼스펙티브에서 Checkout함.
거봐 금방되는데.(소스만 내려받는거면 진짜 금방된다. 서버세팅도 금방된다.)
- 이때 Check out as a project in the workspace로 프로젝트를 생성하면 소스 보기만 된다.
Java Project가 아니라서 컴파일이 되지 않음.
소스 따라가기도 안됨.
아이콘 모양이 다르다.
New Project Wizard를 이용해서 프로젝트를 선택할 것.
- 이클립스에서 생성된 프로젝트를 그대로 올렸다면(.settings/, .classpath, .project 가 존재) New Project Wizard가 활성화되지 않는다.1
Eclipse로 받으면 되는데 귀찮아서 미루다가 오늘 함.
SVN Repository Exploring 퍼스펙티브에서 Checkout함.
거봐 금방되는데.(소스만 내려받는거면 진짜 금방된다. 서버세팅도 금방된다.)
- 이때 Check out as a project in the workspace로 프로젝트를 생성하면 소스 보기만 된다.
Java Project가 아니라서 컴파일이 되지 않음.
소스 따라가기도 안됨.
아이콘 모양이 다르다.
New Project Wizard를 이용해서 프로젝트를 선택할 것.
- 이클립스에서 생성된 프로젝트를 그대로 올렸다면(.settings/, .classpath, .project 가 존재) New Project Wizard가 활성화되지 않는다.1
- 2010-03-26 추가 [본문으로]
- Eclipse - Maven Project를 Dynamic Web Project로 만들기
- 日常茶飯事
- 2009. 5. 15. 07:09
SVN에서 소스를 받는데 Maven Project여서 몇가지 수정했다.
- 또는 Dynamic Web Project 생성시 Content Directory 와 Java Source Directory 위치를 잡아준다.
프로젝트 생성전 저장소를 항상 확인해 둘 것.
- Java Build Path - Source 에서 PROJECT/src/main/java 를 추가하고 기존 소스경로는 삭제한다.(기존 소스경로 src/를 먼저 삭제해야 할수도 있다.1)
- PROJECT/.settings/org.eclipse.wst.common.component 수정
/WebContent 를 /src/main/webapp 로 변경한다.
프로젝트 생성전 저장소를 항상 확인해 둘 것.
- 2011-08-22 추가 [본문으로]
- Subversion 명령어
- 日常茶飯事
- 2009. 5. 2. 08:49
요즘 Unix 에서 svn 명령어를 사용할 일이 있어서 정리해 본다.
$ svn status //항상 확인할 것. 로컬 작업본의 변경 상태를 보여준다.
? WEB-INF/classes
M index.jsp
M index.html
$ svn status - u //서버 저장소의 변경 상태를 보여준다.
$ svn status board
$ svn co http://SVN_SERVER:8080/svn/repos/trunk/SSO
A SSO/prod
A SSO/prod/verify.sso
$ svn update
$ svn update board/
U board/view.jsp
업데이트 된 리비전 81.
$ svn update main/notice.jsp //특정 파일만 업데이트하기
$ svn commit -m "" test/welcome.html //=-=> 문법 맞나?
$ svn update
무시함 '.' //권한이 없는 사용자인 경우였음. root 로 하면 된다.
$ svn log number.txt
$ svn diff number.txt //작업본(working copy)의 변경 내용을 볼 때
$ svn diff -r HEAD number.txt //저장소와 작업본을 비교
? WEB-INF/classes
M index.jsp
M index.html
$ svn status - u //서버 저장소의 변경 상태를 보여준다.
$ svn status board
$ svn co http://SVN_SERVER:8080/svn/repos/trunk/SSO
A SSO/prod
A SSO/prod/verify.sso
$ svn update
$ svn update board/
U board/view.jsp
업데이트 된 리비전 81.
$ svn update main/notice.jsp //특정 파일만 업데이트하기
$ svn commit -m "" test/welcome.html //=-=> 문법 맞나?
$ svn update
무시함 '.' //권한이 없는 사용자인 경우였음. root 로 하면 된다.
$ svn log number.txt
$ svn diff number.txt //작업본(working copy)의 변경 내용을 볼 때
$ svn diff -r HEAD number.txt //저장소와 작업본을 비교
- Eclipse에서 Subversion 사용하기
- 日常茶飯事
- 2009. 2. 4. 15:38
Eclipse 3.3.2
Subclipse 1.0.0 (http://subclipse.tigris.org/update 에서 업데이트한다.)
Subclipse 1.0.0 (http://subclipse.tigris.org/update 에서 업데이트한다.)
- Subversion 관리
- 日常茶飯事
- 2009. 1. 8. 14:55
- 저장소 관리
- 서비스 등록
- 저장소 여러 개 사용하기
- 저장소 생성
> svnadmin create --fs-type fsfs d:/svn_base/rep1 //rep1 이라는 저장소 생성
- svnserve.conf 설정(d:/svn_base/rep1/conf/)
anon-access = none //익명사용자의 접근을 막는다.
auth-access = write
password-db = passwd
authz-db = ../../conf/authz //여러 저장소에서 각각 지정하지 말고 한곳에서 관리하도록 할 수 있다.
- 권한 설정(authz) : Path-Based Authorization
[/]
* =
pantarei = rw
[rep1:/prj1/trunk]
mir = rw
[rep2:/]
* = r #읽기전용
- 서버 시작
> svnserve -d -r d:/svn_base //svn 프로토콜을 사용, 3690 포트 사용
- 서비스 등록
sc \\DEVTEST create svnserve binpath= "C:/Subversion/bin/svnserve.exe
--service -r D:/Resources/svn_repos" DisplayName= "Subversion svnserve"
- 저장소 여러 개 사용하기
- 위와 같이 저장소를 모아둔 디렉토리를 기준으로 svnserve 를 실행시킨다.
- > svnserve -d -r d:/svn_base/rep2 --listen-port 3691
- password-db, authz-db 를 한곳에서 관리한다.
- 버전 정보 보기
> svnadmin --version //svnlook --version 동일
svnadmin, 버젼 1.4.6 (r28521)
Dec 20 2007, 16:19:22에 컴파일 됨
...
svnadmin, 버젼 1.4.6 (r28521)
Dec 20 2007, 16:19:22에 컴파일 됨
...
Recent comment