개요 ¶
VCS는 주로 공동으로 진행하는 프로젝트에서 파일의 버전 관리를 위해 사용됨.
다수가 진행하는 프로젝트의 각종소스, 파일등의 문서를 효율적(?)으로 관리해줌
다수가 진행하는 프로젝트의 각종소스, 파일등의 문서를 효율적(?)으로 관리해줌
OpenSource 프로젝트에서는 ![[http]](/ns/imgs/http.png)
CVS(ConcurrentVersionsSystem)를 많이 사용한다.
KLDP의 사람들 중 선도적인 몇몇은 subversion을 사용하려고 한다.
CVS(ConcurrentVersionsSystem)를 많이 사용한다.KLDP의 사람들 중 선도적인 몇몇은 subversion을 사용하려고 한다.Borland Team Source ¶
델파이로 작업을 하면서 2~3명이 함께 작업을 진행할 때 사용한 경험이 있음. 관리자(PM)와 유저 개념으로 권한을 설정했던 것으로 기억하며, 특정 파일에 대한 LOCK을 걸어서 해당 LOCK을 풀어주기 전엔 해당 파일에 대한 업데이트가 불가함. 파일의 버전 관리기능 이전버전과의 차이점 등을 보여주는 기능등이 있음.
VCS 유감 ¶
실제로 사용해본 VCS는 Team Source 밖에는 없지만 VCS라는 프로그램의 한계를 많이 느낀다. VCS가 프로젝트의 버전관리를 해준다고는 하지만 이것 역시 지대한 관심을 가지고 Source 업데이트에 주의하지 않으면 문제는 생기더라... -.-;; 프로그램 짜면서 클라이언트들이 "자동으로 어떻게 잘 되는 방법 없나요?"라고 물어볼 때 답답함을 느끼지만... 개발자 입장에선 VCS가 버전관리를 알아서 잘 해주면 참 좋겠단 생각이 절실하다. VCS를 쓰면 버전관리는 되지만... 결국 VCS 를 사용함으로 인한 부담이 생기는게 사실.... --happycoat
구체적으로 어떤 점이 불편하신가요? CVS의 경우 불편한 점이 있긴 하지만 - 디렉토리 삭제가 안되고, atomic operation 지원도 잘 안되고.., 심볼릭 링크 지원도 안되지만 - 버전 관리 측면에서는 큰 불편함이 없었거든요. --지원
Team 소스 만의 문제인지는 모르지만 신경써서 체크인 하고 업데이트를 하지 않으면 결국에는 히스토리만 가지고는 헷갈릴 수 밖에는 없는 문제가 생기던데요... 특히 두 사람이 같은 코드를 수정하면서 양쪽 모두 코드의 삭제와 추가가 발생한 경우에는 어떤 것이 적합한 코드인지 결정하는 것은 사람일 수 밖에는 없게되져... 그럴 수 밖에 없는 거지만... 단순하게 한 사람이 개인의 코드를 수정하면서 그 버전만 관리한다면 그다지 큰 의미가 없는 것 같아요...
제가 VCS에 대해서 자세한 지식을 가지고 있지 못한 부분도 있으니.. VCS를 이용해서 편리했던 점 같은 것이있으면... 얘기해 보는 것도 좋겠네여...'' --happycoat
Team 소스 만의 문제인지는 모르지만 신경써서 체크인 하고 업데이트를 하지 않으면 결국에는 히스토리만 가지고는 헷갈릴 수 밖에는 없는 문제가 생기던데요... 특히 두 사람이 같은 코드를 수정하면서 양쪽 모두 코드의 삭제와 추가가 발생한 경우에는 어떤 것이 적합한 코드인지 결정하는 것은 사람일 수 밖에는 없게되져... 그럴 수 밖에 없는 거지만... 단순하게 한 사람이 개인의 코드를 수정하면서 그 버전만 관리한다면 그다지 큰 의미가 없는 것 같아요...
제가 VCS에 대해서 자세한 지식을 가지고 있지 못한 부분도 있으니.. VCS를 이용해서 편리했던 점 같은 것이있으면... 얘기해 보는 것도 좋겠네여...'' --happycoat두사람 이상이 동시에 같은 코드를 수정하는 경우라면 어떤 VCS라도 헷갈릴 수 밖에 없습니다. 그런 충돌이 발생할 수 있는 상황을 최소화 하면서 암묵적으로 팀원간의 분업과 합의가 있어야 합니다. 대부분의 대규모 프로젝트가 그렇기도 하고요. 그리고, 이러한 단점을 충분히 커버하고도 모자람이 없기에 버전 컨트롤 시스템을 사용하는것이겠죠. --고무신
see also DontAutomateEverything