* 최신 버전에서는 안된다 (보기 1.12.5)
* 예전 버전에서만 가능하다 ( 보기 1.8.30)
preference 메뉴에서 Korean 설정하면 된다
'cvs'에 해당되는 글 7건
Eclipse 에서 작업 증인 소스를 cvs 저장소의 최근(HEAD) 본과 비교하려면 ?
작업 중인 소스를 선택한 뒤, 오른 쪽 메뉴의 'Compare With' -> 'Latest from HEAD'
파일 선택 후 오른쪽 마우스. -> Team -> Commit
(eclipse indigo 버전 기준)
http://searcher.tistory.com/entry/ECLIPSE-CVS-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0
를 참고하라.
해보지는 않았다.
를 참고하라.
해보지는 않았다.
CVS 설치 후 보니까, 현지 시각 설정이 안되 어 있다. 즉 9 시간 느리다. 어떻게 설정하나?
-------
arbi9:/home/cts/src/pibc>date
2008년 2월 20일 수요일 17시 14분 47초
arbi9:/home/cts/src/pibc>cvs status -v pibd6221.c
===================================================================
File: pibd6221.c Status: Up-to-date
Working revision: 1.1.1.1 Tue Nov 18 02:09:33 2003
Repository revision: 1.1.1.1 /home/cvs/src/pibc/pibd6221.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
Existing Tags:
start (revision: 1.1.1.1)
INITIAL (branch: 1.1.1)
그냥 최대한 빨리 이슈 추적 시스템을 사용하세요.(49)
참고 사이트
CVS http://www.cvshome.org (<-- 현재 제대로 운영되지 않고 있다. http://www.nongnu.org/cvs/ 대신 이곳을 보라)
서브버전 http://subversion.tigris.org
참고 도서
"Mastering Regular Expressions", Jeffrey Friedl
"실용주의 프로그래머를 위한 버전관리 using CVS", 데이비드 토머스, 앤드류 헌트 공저, 인사이트
참고 사이트
CVS http://www.cvshome.org (<-- 현재 제대로 운영되지 않고 있다. http://www.nongnu.org/cvs/ 대신 이곳을 보라)
서브버전 http://subversion.tigris.org
참고 도서
"Mastering Regular Expressions", Jeffrey Friedl
"실용주의 프로그래머를 위한 버전관리 using CVS", 데이비드 토머스, 앤드류 헌트 공저, 인사이트
단순한게 좋다면 CVS 를 쓰지 않았는데, 프로젝트 막판에 CVS 를 도입하기로 했다.
현재 개발자들이 원격에서도 어느 정도 유지해야 하기 때문이다.
그런데 CVS 후속으로 나온 subversion 도 꽤 쓰는 것 같다.
subversion 에 대해서는 찬반이 갈리고 있다.
나는 둘 다 써보지 않았는데, 찬성쪽으로 쏠린다. 게을러서인가보다.
--- 반대 글 (http://youngrok.com/moin.cgi/%EC%8A%A4%ED%94%84%EB%A7%81%EB%85%B8%ED%8A%B8_%EA%B8%B0%EC%88%A0%EB%B3%B4%EA%B3%A0%EC%84%9C)
Subversion 아직 CVS를 쓰고 있다면 Subversion으로 옮겨 타지 말라. Subversion이 CVS보다 나은 점은 없다. 같은 개발진이 만들었다면서, 더 낫게 만들려고 했다면서 왜 이 모양인지. 가장 심각한 문제는 툴의 완성도가 낮다는 것이다. 이클립스에서 편리하게 쓸 수 있는 CVS에 비해 Subversion을 이클립스에서 쓰려면 대단한 인내심이 필요할 것이다. 버그가 너무 많다. 커밋이 잘 안되는 경우는 부지 기수고 merge도 잘 안되고 삭제나 이동도 일반적인 기대와 다르게 동작한다. subclipse는 정말 후졌고 subversive는 그나마 조금 쓸만하지만 여전히 CVS 플러그인에 비하면 너무 부족하다. 더 심각한 문제는 커맨드 라인에서 써도 버그가 발생한다는 것이다. 많은 파일과 디렉토리를 한 번에 커밋하면 락이 걸려서 안되기도 하고 엄청나게 느린 속도로 되는 경우도 있다. 버 그가 좀 있어도 기능이 더 좋다면 이해해 줄 수도 있다. 그러나 실제로 기능을 체감하는 것은 도구를 통해서인데 실질적으로 이클립스의 CVS 플러그인보다 나은 클라이언트를 갖지 못한 Subversion은 기능적으로 더 떨어진다고도 할 수 있다. 그리고 Subversion이 내세우는 장점인 changeset 단위의 revision number도 장점보다는 단점인 것 같다. 실제로 commit은 파일 단위로 일어나는 경우가 훨씬 더 많다. 한 번 생각해보라. commit하는 단위가 하나의 의미적 작업 단위와 일치하는지를. 두 개 이상의 작업 단위를 한 번에 commit하는 경우도 있고 파일에 따라 다른 commit log를 남겨야 해서 한 작업 단위를 여러 번에 나눠서 commit하는 경우도 많을 것이다. 이런 상황에서 changeset 단위 rollback이 큰 의미가 있는 것은 아니다. 어차피 CVS도 시간과 태그로 changeset 단위와 비슷한 개념을 활용할 수 있기 때문에 파일별 revision이 더 나은 것 같다. changeset 때문에 한 저장소에 여러 프로젝트를 관리하기 어렵다는 것도 문제다. revision이 공유되기 때문에 다른 프로젝트의 변경 내용 때문에 내 프로젝트의 revision이 올라가는 현상이 생기는 것이다. 이것 때문에 내 프로젝트의 이전 버전을 찾는데 고생할 때도 있고 export하거나 할 때도 revision이 너무 많아서 오래 걸리는 문제가 있다. 태깅도 좀 문제가 있다. subversion 태깅은 단순 copy라서 더 쉽다고 하는데 그래서 오히려 더 오래 걸리고 무거운 동작이 되버려서 잘 활용 안하는 경향이 있다. 물론 changeset 개념이 있기 때문에 반대로 태깅이 별로 필요 없기도 하지만. CVS는 오랫동안 많은 사람들이 써왔고 몇 가지 부족함이 있긴 하지만 그 부족함은 대부분 툴로 커버할 수 있다. 그리고 거의 모든 배포판에 기본으로 설치된다. 별다른 이유가 없다면 그냥 CVS 쓰기를 권한다. ClearCase 등 상용 SCM도 좋은 기능을 제공하긴 하지만 실제 사용할 때 CVS보다 월등히 나은 점을 발견하기는 쉽지 않을 것이다. 단순 기능 목록에 현혹되지 말고 자신이 실제로 사용하는 기능에 초점을 맞춰서 도구를 선택해야 한다.
--- 찬성 글(http://kldp.org/node/81558)
cvs vs. subversion 새 글 Submitted by 익명 사용자 (미확인) on 수, 2007/06/20 - 11:34am. 제가 있는 회사에서 옛날에는 CVS를 이용해서 개발을 하다가 2년쯤 전부터 subversion으로 바꿔서 개발하고 있습니다. 도끼로 나무하다가 전기톱 들고 하는 기분입니다. 정말 강력하다, 아니 그보다는, 그냥 version control system이라면 기본적으로 제공해야 하는 기능이 이런 건데 우리가 그동안 모르고 있었구나, 그런 기분입니다. 특별히 버그가 문제가 된 적은 없습니다. (솔직히 버그가 있다고 전기톱 버리고 도끼 쓰시겠습니까?) CVS는 이력을 파일 단위로 관리하고, subversion은 repository 전체 단위로 관리합니다. 그래서 "언제부터 언제 사이에 무슨 일이 있었나" 같은 걸 subversion은 아주 쉽게 알아볼 수 있지만 CVS는 어렵습니다. Branch를 나눠서 작업하는 것도 CVS에서는 눈물나는 일이지만 subversion은 큰 문제없이 가능합니다. (사실 요즘 나오는 다른 툴만큼 branch를 멋지게 지원하지는 않습니다. 이런 기능은 arch, git, bazaar 등등에선 때깔나게 지원한다고 하는데 써본 적이 없어서...) CVS는 atomic commit을 지원 안하기 때문에 빌드를 자동화하는 게 곤란합니다. "다른 사람이 커밋을 반쯤 하는 도중에 빌드를 하려고 소스를 받아서 빌드가 깨지는 상황"이 이론적으로 언제든지 발생할 수 있습니다. 기타 등등 subversion의 장점이 한두 가지가 아닙니다. » svn에 대한 의견이 새 글 Submitted by 김성진 on 수, 2007/06/20 - 10:47am. svn에 대한 의견이 이렇다니 의외입니다. 저의 경우 회사에서 CVS를 약 5년간 쓰다가 작년에 SVN으로 바꿨습니다. code commit, revision 관리, 추적, simple한 개념 등등에 있어서 cvs보다 낫다고 저는 평가를 했습니다. 버그의 경우도 심각한 경우를 발견하지 못했는데, 사용 domain에 차이가 있어서 그런 것도 있겠네요. svn이 cvs보다 나은 결정적인 부분은 branch관리나 tag 만들 때 입니다. 단지 revision을 복사하면 되는 것이지, cvs처럼 모든 소스코드에 대해서 tag를 달기위해 몇십분동안 repository를 뒤지는 경우는 없거든요. 소스코드의 양이 몇백메가가 되다 보니..이런 문제가 cvs에선 쉽게 해결이 안되더군요. 환경의 차이라고 생각됩니다. 혹시나 윗 들을 읽고, svn에 대해서 선입견을 가지시는 분들이 계실까 올리는 글입니다. 그리고, 저흰 별도의 툴은 거의 사용하지 않고, 대부분 command line에서 작업합니다.
현재 개발자들이 원격에서도 어느 정도 유지해야 하기 때문이다.
그런데 CVS 후속으로 나온 subversion 도 꽤 쓰는 것 같다.
subversion 에 대해서는 찬반이 갈리고 있다.
나는 둘 다 써보지 않았는데, 찬성쪽으로 쏠린다. 게을러서인가보다.
--- 반대 글 (http://youngrok.com/moin.cgi/%EC%8A%A4%ED%94%84%EB%A7%81%EB%85%B8%ED%8A%B8_%EA%B8%B0%EC%88%A0%EB%B3%B4%EA%B3%A0%EC%84%9C)
Subversion 아직 CVS를 쓰고 있다면 Subversion으로 옮겨 타지 말라. Subversion이 CVS보다 나은 점은 없다. 같은 개발진이 만들었다면서, 더 낫게 만들려고 했다면서 왜 이 모양인지. 가장 심각한 문제는 툴의 완성도가 낮다는 것이다. 이클립스에서 편리하게 쓸 수 있는 CVS에 비해 Subversion을 이클립스에서 쓰려면 대단한 인내심이 필요할 것이다. 버그가 너무 많다. 커밋이 잘 안되는 경우는 부지 기수고 merge도 잘 안되고 삭제나 이동도 일반적인 기대와 다르게 동작한다. subclipse는 정말 후졌고 subversive는 그나마 조금 쓸만하지만 여전히 CVS 플러그인에 비하면 너무 부족하다. 더 심각한 문제는 커맨드 라인에서 써도 버그가 발생한다는 것이다. 많은 파일과 디렉토리를 한 번에 커밋하면 락이 걸려서 안되기도 하고 엄청나게 느린 속도로 되는 경우도 있다. 버 그가 좀 있어도 기능이 더 좋다면 이해해 줄 수도 있다. 그러나 실제로 기능을 체감하는 것은 도구를 통해서인데 실질적으로 이클립스의 CVS 플러그인보다 나은 클라이언트를 갖지 못한 Subversion은 기능적으로 더 떨어진다고도 할 수 있다. 그리고 Subversion이 내세우는 장점인 changeset 단위의 revision number도 장점보다는 단점인 것 같다. 실제로 commit은 파일 단위로 일어나는 경우가 훨씬 더 많다. 한 번 생각해보라. commit하는 단위가 하나의 의미적 작업 단위와 일치하는지를. 두 개 이상의 작업 단위를 한 번에 commit하는 경우도 있고 파일에 따라 다른 commit log를 남겨야 해서 한 작업 단위를 여러 번에 나눠서 commit하는 경우도 많을 것이다. 이런 상황에서 changeset 단위 rollback이 큰 의미가 있는 것은 아니다. 어차피 CVS도 시간과 태그로 changeset 단위와 비슷한 개념을 활용할 수 있기 때문에 파일별 revision이 더 나은 것 같다. changeset 때문에 한 저장소에 여러 프로젝트를 관리하기 어렵다는 것도 문제다. revision이 공유되기 때문에 다른 프로젝트의 변경 내용 때문에 내 프로젝트의 revision이 올라가는 현상이 생기는 것이다. 이것 때문에 내 프로젝트의 이전 버전을 찾는데 고생할 때도 있고 export하거나 할 때도 revision이 너무 많아서 오래 걸리는 문제가 있다. 태깅도 좀 문제가 있다. subversion 태깅은 단순 copy라서 더 쉽다고 하는데 그래서 오히려 더 오래 걸리고 무거운 동작이 되버려서 잘 활용 안하는 경향이 있다. 물론 changeset 개념이 있기 때문에 반대로 태깅이 별로 필요 없기도 하지만. CVS는 오랫동안 많은 사람들이 써왔고 몇 가지 부족함이 있긴 하지만 그 부족함은 대부분 툴로 커버할 수 있다. 그리고 거의 모든 배포판에 기본으로 설치된다. 별다른 이유가 없다면 그냥 CVS 쓰기를 권한다. ClearCase 등 상용 SCM도 좋은 기능을 제공하긴 하지만 실제 사용할 때 CVS보다 월등히 나은 점을 발견하기는 쉽지 않을 것이다. 단순 기능 목록에 현혹되지 말고 자신이 실제로 사용하는 기능에 초점을 맞춰서 도구를 선택해야 한다.
--- 찬성 글(http://kldp.org/node/81558)
cvs vs. subversion 새 글 Submitted by 익명 사용자 (미확인) on 수, 2007/06/20 - 11:34am. 제가 있는 회사에서 옛날에는 CVS를 이용해서 개발을 하다가 2년쯤 전부터 subversion으로 바꿔서 개발하고 있습니다. 도끼로 나무하다가 전기톱 들고 하는 기분입니다. 정말 강력하다, 아니 그보다는, 그냥 version control system이라면 기본적으로 제공해야 하는 기능이 이런 건데 우리가 그동안 모르고 있었구나, 그런 기분입니다. 특별히 버그가 문제가 된 적은 없습니다. (솔직히 버그가 있다고 전기톱 버리고 도끼 쓰시겠습니까?) CVS는 이력을 파일 단위로 관리하고, subversion은 repository 전체 단위로 관리합니다. 그래서 "언제부터 언제 사이에 무슨 일이 있었나" 같은 걸 subversion은 아주 쉽게 알아볼 수 있지만 CVS는 어렵습니다. Branch를 나눠서 작업하는 것도 CVS에서는 눈물나는 일이지만 subversion은 큰 문제없이 가능합니다. (사실 요즘 나오는 다른 툴만큼 branch를 멋지게 지원하지는 않습니다. 이런 기능은 arch, git, bazaar 등등에선 때깔나게 지원한다고 하는데 써본 적이 없어서...) CVS는 atomic commit을 지원 안하기 때문에 빌드를 자동화하는 게 곤란합니다. "다른 사람이 커밋을 반쯤 하는 도중에 빌드를 하려고 소스를 받아서 빌드가 깨지는 상황"이 이론적으로 언제든지 발생할 수 있습니다. 기타 등등 subversion의 장점이 한두 가지가 아닙니다. » svn에 대한 의견이 새 글 Submitted by 김성진 on 수, 2007/06/20 - 10:47am. svn에 대한 의견이 이렇다니 의외입니다. 저의 경우 회사에서 CVS를 약 5년간 쓰다가 작년에 SVN으로 바꿨습니다. code commit, revision 관리, 추적, simple한 개념 등등에 있어서 cvs보다 낫다고 저는 평가를 했습니다. 버그의 경우도 심각한 경우를 발견하지 못했는데, 사용 domain에 차이가 있어서 그런 것도 있겠네요. svn이 cvs보다 나은 결정적인 부분은 branch관리나 tag 만들 때 입니다. 단지 revision을 복사하면 되는 것이지, cvs처럼 모든 소스코드에 대해서 tag를 달기위해 몇십분동안 repository를 뒤지는 경우는 없거든요. 소스코드의 양이 몇백메가가 되다 보니..이런 문제가 cvs에선 쉽게 해결이 안되더군요. 환경의 차이라고 생각됩니다. 혹시나 윗 들을 읽고, svn에 대해서 선입견을 가지시는 분들이 계실까 올리는 글입니다. 그리고, 저흰 별도의 툴은 거의 사용하지 않고, 대부분 command line에서 작업합니다.
