subversion 하나의 working copy에 다중사용자가 사용할 경우..
저희 회사 서버 프로그램을 subversion에 적용하여 개발하고자 합니다.
그런데 subversion은 기본적으로 각 개발자가 working copy를 checkout 받아서 병렬로 작업하여 commit을 하는데는 편리합니다.
그런데 저희 회사 서버 프로그램의 경우에는 개발환경이 구축된 서버에 하나의 working copy를 받아서 여러 사용자가 수정하는 체제입니다.
이렇게 되면 문제가 되는 것이 한 개발자가 소스를 수정하여 commit하기 전인데 다른 개발자가 또 거기에 수정을 가할 수 있다는 것입니다.
각 개발자가 따로 working copy본을 가지고 작업을 한다면야 commit하는 시점에 툴에서 merge하여 각 개발자가 commit을 하면 되는데요,
하나의 working copy에 여러 개발자가 같이 개발한다면 하나의 소스에 동시에 여러명이 수정하는건 바람직스러워 보이지 않습니다.
적어도 한 개발자가 소스를 수정할 때는 그 개발자가 소스를 commit하기 이전에는 배타적인 수정을 보장해줘야지요..
그런데 svn lock은 우리가 원하는 개념이 아니고 working copy간의 lock을 거는 개념이더라구요..
이렇게 하나의 working copy에 다중 사용자가 작업을 해야하는 상황에서는 어떻게 svn을 이용해야할지 고민입니다...
그렇다고 각 개발자들로 하여금 그 큰 서버소스이 working copy를 각자 따로 받아라 하는 것도 좋지 않고... 왜냐하면 컴파일하려면 자기의 working copy받은 것으로 컴파일 환경을 맞추는 작업을 따로 해줘야 하거든요..
소스를 수정할 때 chown명령어로 소유자 권한을 바꾸는 것도 방법이긴 한데 개발자들로 하여금 소스를 수정할 때마다 일일이 chown하라고 하는 것도 너무 번거로울 뿐 아니라 잘 지켜줄지도 알 수 없는 노릇이고...
이럴때 개발자들도 편하게 효율적으로 작업할 수 있는 방안이 있을까요??
Subversion 방식에 맞춰 환경을 맞추는 작업을 자동화시킬 수는 없나요?
Build 환경을 만드는 것이 어렵나요?
Subversion 은 build 환경을 만드는 script를 저장소에서 같이 관리하는 것을 추천합니다.
크기 문제는 Subversion 의 경우 쉽죠. 부분 checkout 과 부분 commit 이 가능하니까요.
Source 배치를 잘 해두면 이부분도 가능하긴 합니다.
하지만 역시 저장소를 너무 크지 않게 관리하는 것도 중요합니다.
그런데 이게 정공법이긴 한데 원하시는 바인지는 잘 모르겠네요.
말씀하신대로 Subversion 을 쓰신다는 것은 차분 backup 이외에 다른 의미가 없는 것 같군요.
Build 환경 문제가 아닙니다.. 소스코드의
Build 환경 문제가 아닙니다..
소스코드의 working copy를 개발서버에 checkout을 받아 놓은 다음 다중 사용자가 함께 작업할 때 각 개발자가 수정하는 소스에 대해서는 배타적인 edit을 보장해주고자 하는 문제입니다..
빌드환경 구축하는 것은 개발서버에 한번 설정만 해주면 되는 것이지요..
서버에 working copy라는 말이 좀 문제가 있다고 보입니다.
제가 생각하는 분산 개발환경(?)
1. SVN Server : 버전 관리만 수행.
2. Deployment Server or CI Server : 개발 및 운용 환경 배포 서버. 말씀하신 Build 환경이라 볼 수도 있겠습니다.
3. 개발자 PC : 개발자 개인이 개발 테스트 수행.
1. 개발자는 SVN에서 모듈을 받고, 본인이 필요한 소스 개발 수정 및 테스트를 수행합니다.
2. 개발자는 로컬에 런타임(Tomcat 등)이 있을 수 있습니다.
3. 여러 개발자가 수정 후 커밋한 내용을 Deployment Server에서는 SVN update를 받아서 빌드 및 개발서버나 운용서버에 Deploy합니다.
'개발환경이 구축된 서버에 하나의 working copy를 받아서 여러 사용자가 수정하는 체제입니다.'
서버에 단지 한 개의 이력관리만 있으면 된다라고 하면, 서버에서 RCS하는 것이?
서버의 working copy를 개발자가 어떻게 작성, 수정, 테스트하는지 시나리오가 잘 이해가 되지 않습니다.
제가 생각하는 환경은 Java 기반이며, 개발자는 Eclipse + JUnit + Tomcat 을 통한 작성, 수정, 테스트하는 환경입니다.
개발자 개개인이 working copy를 각자 소유하게...
소스 크기 때문에 각자 체크아웃해서 소스를 개별화 하는 것이 안된다는게 이해가 안됩니다.
우리 회사 같은 경우 전체 소스를 개발자 개인이 체크아웃해서 각자 사용 합니다.
(지금 검사해보니 빌드 했을때 오브젝트 포함해서 13GB 정도 되네요.)
이에 맞게 빌드환경도 맞춰져 있습니다.
그래도 디스크 1~2 테라로 유지하면 크게 문제가 되진 않더군요.
단순히 소스가 방대해서가 아니라 다른 이유가 있나요?
다른 문제가 없다면,
소스를 개별 소유하게 하는 것이 svn와 함께 자유로운 운영이 가능하다고 봅니다.
모듈하나가? 13GB는 아니겠지요?
SVN으로 개발하더라도, 모듈화는 할텐데, 모듈하나 checkout해서 build하는데, 13GB로 불지는 않겠지요 ?-)
일반적인 Java나 C모듈은 단위 모듈이 나오는데,
애니악 시절에 더미 터미널에 vi + cc로만 개발한다면, 서버에서 코드를 공유하고 개발을 했을 텐데.
소스가 13G는 아닙니다.
패키징에 필요한 각종 라이브러리 및 기타 참고 소스 등등...
모든 것이 다 들어 있으며,
이 디렉토리 하나면 패키징이 완료 됩니다.
저희는 이 모든 것을 트렁크에 유지하고 브랜치도 따고 합니다.
시간이 흐른 뒤에 참조 소스나 필요한 라이브러리가 없어지는 일을 방지하기 위함 입니다.
그야 말로 만말 창고로 사용하죠....
그래서 보안문제가 좀 발생하죠.
이런 문제 때문에 조만가 빌드 체계를 뒤 흔들어야 하는 어려움이...
용량 문제 때문이 아니라면 개발자별로 브랜치를 따고
용량 문제 때문이 아니라면 개발자별로 브랜치를 따고 별도의 디렉토리에 각자 체크아웃을 해서 쓰는 방법은 어떠한가요?
어억.. 이거슨.. 태곳적 sccs/rcs에나 적합한
어억.. 이거슨..
태곳적 sccs/rcs에나 적합한 개발 방식인 것 같은데요.. 하나의 working copy를 여러 개발자가 공유한다는 건..
rcs에서는 checkout할 때 해당 사용자 이름으로 lock을 걸어줌으로써 여러 사용자간 배타적 수정을 보장했죠. ( http://www.gnu.org/software/rcs/manual/html_node/Quick-tour.html )
꼭 하나의 working copy + 배타적 수정 모델을 사용해야 한다면, 차라리 SCM으로는 rcs를 쓰되, 그것들을 백업하는 용도로 subversion을 쓸 수도 있겠네요.
물론 저라면 이런 regression을 선택하기보다는 개발자마다 working copy를 따로 유지하는 방식을 어떻게든 관철하겠습니다.
용량이 문제라면, 개발자들이 하나의 개발서버에
용량이 문제라면,
개발자들이 하나의 개발서버에 접속하여 개발한다는 이점을 살려서
각종 외부 라이브러리 등은 별도의 디렉토리 (e.g. /var/commonlibs) 등에 체크아웃해놓고,
주된 수정 부분만 각자 개발자들이 자기만의 디렉토리에 working copy를 체크아웃하여 작업할 수 있도록 빌드환경을 구성할 수도 있을 것 같습니다.
댓글 달기