티스토리 뷰
다음과 같은 시나리오를 살펴 보자.
"소스 디렉토리 A 의 a.c의 내용을 복사하여 소스 디렉토리 B의 b.c 로 사용해야할 일이 생겼다. 제품이 늘어 나고 있거든!"
(물론 코드는 되도록 복사해서 사용해서는 안되지만 우리는 그런 완벽한 세상에서 살지 않으므로...)
이 경우.
위에 연출된 두 명령의 마지막 svn log는 다르기 마련이며, 전자는 꽤 겸손한 로그가 출력된다.
마찬가지로 이름을 바꿔야할 경우에도 command line의 mv를 사용하는 것이 아니라 svn mv 를 사용해야 변경기록을 모두 유지 할 수 있게 된다.
만약 svn log를 사용하여 복사한 다음 수정된 기록만 보고 싶을 때는
svn log --stop-on-copy a.c
라는 명령으로 보면 된다.
한 줄 한 줄 커밋된 과정을 소중하게 생각하는 것이 변경 기록 관리의 기본자세이다.
"소스 디렉토리 A 의 a.c의 내용을 복사하여 소스 디렉토리 B의 b.c 로 사용해야할 일이 생겼다. 제품이 늘어 나고 있거든!"
(물론 코드는 되도록 복사해서 사용해서는 안되지만 우리는 그런 완벽한 세상에서 살지 않으므로...)
이 경우.
$ pwd
/work/project_x/src/agent
$ cp a.c ../log
$ cd ../log
$ svn add a.c
$ svn commit
$ svn log a.c
위와 같이 하면, 중대한 것을 잃게 된다. a.c 의 지금까지의 변경기록이다. 다음과 같이 해야 정석이다./work/project_x/src/agent
$ cp a.c ../log
$ cd ../log
$ svn add a.c
$ svn commit
$ svn log a.c
$ pwd
/work/project_x/src/agent
$ svn cp a.c ../log
$ cd ../log
$ svn commit
$ svn log a.c
/work/project_x/src/agent
$ svn cp a.c ../log
$ cd ../log
$ svn commit
$ svn log a.c
위에 연출된 두 명령의 마지막 svn log는 다르기 마련이며, 전자는 꽤 겸손한 로그가 출력된다.
마찬가지로 이름을 바꿔야할 경우에도 command line의 mv를 사용하는 것이 아니라 svn mv 를 사용해야 변경기록을 모두 유지 할 수 있게 된다.
만약 svn log를 사용하여 복사한 다음 수정된 기록만 보고 싶을 때는
svn log --stop-on-copy a.c
라는 명령으로 보면 된다.
한 줄 한 줄 커밋된 과정을 소중하게 생각하는 것이 변경 기록 관리의 기본자세이다.
반응형
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
링크
TAG
- perl
- nodejs
- Subversion
- 식물
- url
- MySQL
- SSO
- 디버깅
- Tattertools plugin
- OpenID
- 커피
- 덴드롱
- 대화
- macosx
- writely
- VIM
- TCP/IP
- ssh
- SVN
- BlogAPI
- Linux
- 구근
- tattertools
- 수선화
- 킹벤자민
- 퀴즈
- 오픈소스
- 벤자민
- JavaScript
- 클레로덴드럼
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
글 보관함