Software Configuration Management란 무엇인가?

SCM은 가장 중요한 툴 중 하나로서, 학교에서는 배우지 않은 것이다. 소프트웨어(또는 소스) 컨트롤은, 이름에서 시사하듯, 소스 코드와 그 진화를 관리하는데 사용되는 툴과 프로세스이다. SCM의 주요 기능은 다음과 같다.

• 리파지토리에서 파일들을 관리한다.
• 리파지토리에서 파일의 개정판을 관리한다.
• 소스 변경 충돌을 탐지하고, 멀티-개발자 환경에 합병을 제공한다.
• 변경의 근원지를 추적한다.
• 일관성 있고 반복 가능한 빌드를 위해 (개정판과 관련하여) 파일의 설정 관리를 제공한다.

따라서, SCM은 리파지토리에 있는 파일을 관리하고, 그러한 파일들의 개정판을 추적한다. 다양한 개발자에 의해서 리파지토리에 있는 파일에 변경 사항이 생기면, SCM은 여러분이 변경한 것에서 충돌을 구분해 내고, 이들을 자동으로 합병하거나 충돌에 대해 공지한다. 여러 개발자들이 같은 파일 세트를 수정할 수 있기 때문에 이것은 중요한 기능이다. 또한, SCM은 누가 무엇을 수정했는지를 추적할 수 있도록 해준다. SCM은 소프트웨어 이미지나 실행 파일을 구성하는 소스 파일들처럼, 파일들을 관련된 것들을 논리적으로 그룹핑한다.

SCM 언어

SCM의 아키텍처 유형에 대해 자세히 연구하기 전에, 용어에 대해 알아야 한다. 먼저, 리파지토리(repository)가 있다. 리파지토리는 파일이 저장되고 관리되는 중심부이다. (가끔 트리(tree)라고도 한다.) 이 리파지토리에서 로컬 시스템의 실행 폴더로 파일을 가져가는 것을 체크아웃(check-out)이라고 한다. 로컬 파일을 수정하고, 리파지토리에서 변경 사항들을 연동하려면, 업데이트(update)를 해야 한다. 수정된 파일들이 리파지토리로 갔는지를 확인하려면, 커미트(commit)를 수행한다. 수정된 파일이 다른 사람에 의해서 이전에 변경 및 커미트 되었다면, 합병(merge)이 발생하고, 두 개의 changeset들이 하나로 합쳐진다. 변경 사항들의 충돌 때문에 합병이 이루어지지 않는다면, 충돌(conflict)이 발생한다. 이 상황에서, 커미트는 거절되고, 개발자는 직접 변경 사항들을 합병해야 한다. 변경이 커미트 되면, 파일이 개정판(revision) 된다.

한 명 이상의 개발자가 메인 트리(리파지토리의 현재 헤드) 또는 메인 트리의 측면에 있는 개인 브랜치(branch)에서 작업하는 것이 가능하다. 메인 트리에 영향을 주지 않고 브랜치에서 작업을 할 수 있다. 안정적이라면, 브랜치들을 메인 트리로 합병할 수 있다.

소스 트리를 향상시키기 위해, 태그를 적용할 수 있다. 이것으로 파일 세트를 유용한 컬렉션으로 그룹핑 할 수 있다. (가끔, 독자적인 빌드용 파일 릴리스로서 사용된다.)

위로

아키텍처

SCM은 다양하지만, 특히 아키텍처에는 두 가지 근본적인 차이가 있다.

• 중앙화 된 리파지토리 대 분산 리파지토리
• Changeset 대 스냅샷 모델(snapshot models)

중앙화 된 리파지토리 대 분산 리파지토리

현대적 SCM의 가장 중요한 아키텍처 차이는 중앙 리파지토리와 분산 리파지토리이다. 가장 일반적인 아키텍처는 중앙(centralized) 리파지토리이다. 별 모양(star) 아키텍처는 중앙 소스 리파지토리를 중심으로 여러 개발자들이 이 주변에서 작업하고 있다. (그림 1) 개발자들은 소스 코드를 중앙 리파지토리에서 로컬 샌드박스로 체크아웃하고, 변경을 완료하면, 이를 다시 중앙 리파지토리로 커미트 한다. 다른 개발자들도 변경 사항에 액세스 할 수 있다.

브랜치들은 중앙 리파지토리에서 만들어 질 수 있으며, 여러 개발자들은 메인라인 (팁) 밖이 아닌, 그 리파지토리에서 소스 변경을 함께 수행할 수 있다.

분산 아키텍처는 개발자들이 자신들의 로컬 리파지토리를 만들 수 있도록 허용한다. 로컬 개발자 리파지토리는 (분산되었던) 원래 소스 리파지토리와 비슷하다. 주요한 차이점은, 중앙화 방식으로 변경 사항이 이루어지는 샌드박스 대신, 분산 접근 방식은 개발자들이 연결되어 있지 않은 상태에서도 자신의 리파지토리에서 작업할 수 있다. 수정을 하고, 로컬 리파지토리에 커미트 하고, 메인 브랜치에 영향을 주지 않고 다른 곳의 변경 사항을 합병한다. 개발자들은 다른 개발자들도 사용할 수 있는 changeset를 만들 수 있다. (그림 2)

분산 아키텍처는 독립적인 개발자들이 peer-to-peer 네트워크에서 비동기식으로 작업할 수 있기 때문에 흥미롭다. 작업이 준비가 되고(안정화 되면), changeset(또는 patch)를 분산하여 그 기능을 다른 사람들도 사용할 수 있도록 한다. 이것이 바로 리눅스® 커널을 포함한 오늘날의 오픈 소스 시스템 모델이다.

스냅샷(Snapshot) 대 changeset 모델

신구 SCM들간 또 다른 차이는 델타 변경이 저장되는 방식이다. 이론적으로는 비슷하고, 결과 또한 같다. 하지만 개정판이 저장되는 방식은 차이가 있다.

스냅샷 모델에서, 완전한 파일들은 각 개정판 마다 전체 리파지토리에 저장된다. (트리의 크기를 줄이는 최적화를 활용함.) changeset 모델에서, 델타만이 개정판들 사이에 저장되면서, 컴팩트 리파지토리를 만든다. (그림 3)

그림 3에서 보는 것처럼, 이 모델은 다르지만 같은 결과를 갖고 있다. 스냅샷 모델에서, 개정판을 빠르게 할 수 있지만, 이들을 저장하기 위해서는 더 많은 공간이 필요하다. changeset 모델은 공간은 덜 필요하지만, 델타가 베이스 개정판에 적용되어야 하기 때문에 특별한 개정판을 만드는 데는 시간이 더 걸린다. 나중에 알게 되겠지만, 적용되어야 하는 델타의 수를 최소화 할 수 있다.

위로

SCM 예제

아키텍처 별로 나뉜 많은 SCM들을 보자. (중앙 대 분산) 어떤 SCM들은 두 모델 모두를 지원하기도 한다.

CVS

Concurrent Versions System (CVS)은 요즘 가장 일반적인 SCM들 중 하나이다. 개발자들이 중앙 리파지토리에서 소프트웨어 개발 시 협업할 수 있는 changeset 모델을 사용하는 중앙화된 솔루션이다. CVS는 유비쿼터스(ubiquitous)이고, 리눅스 배포판에서는 표준이다. 단순하고 익숙한 신택스 때문에 멀티 또는 싱글 개발자 SCM으로서 선택된다.

Listing 1은 CVS 명령어 샘플과 설명이다. CVS에 대한 자세한 내용은 참고자료를 참조하라.

				
# Create a new repository
cvs -d /home/user/new_repository init

# Connect to the central repository
export CVSROOT=:pserver:user@example.com:/cvs_root

# Check out a sandbox for module project from the central repository
cvs checkout project

# Update a local sandbox from the central repository
cvs update

# Check in changes from the local sandbox to the central repository
cvs commit

# Add new files to the local sandbox (need to be committed)
cvs add <file/subdirectory>

# Show changes made in the local sandbox
cvs diff

CVS는 WinCVS와 TortoiseCVS (Microsoft® Windows Explorer와 통합됨)를 비롯하여, 많은 오픈 소스 그래픽 프론트-엔드를 갖고 있다.

CVS가 많이 채택되기는 하지만, 결점도 있다. 파일 이름을 수정할 수 없으며, symlinks 같은 특별한 파일과는 맞지 않는다. 변경 사항은 변경 사항으로서가 아닌 파일에 의해 추적된다. 성가신 부분이다. 합병 또한 가끔씩 문제가 된다. (CVS는 내부적으로 diff3을 사용한다.)

하지만, CVS는 유용하고, 필수적인 작업을 수행하며, 모든 주요 플랫폼에서 사용할 수 있다. 이러한 문제로 CVS 사용이 꺼려진다면 Subversion을 생각해볼 수 있다.

Subversion

Subversion (SVN)은 CVS의 대체로 디자인 되었지만, 앞서 거론된 문제들은 없다. CVS와 마찬가지로, Subversion은 중앙화 된 솔루션이고 스냅샷 모델을 사용한다. 명령어는 CVS의 명령어를 모방하지만, 파일 제거, 리네이밍, 원래 파일로의 전환 등을 다루기 위해 몇 가지가 추가되었다

Subversion은 Hypertext Transfer Protocol (HTTP), secure HTTP, Secure Shell (SSH)을 통해 터널링을 지원하는 커스텀 SVN 프로토콜 같은 많은 프로토콜들을 통한 원격 액세스를 허용한다.

Listing 2는 Subversion에서 지원되는 몇 가지 명령어들이다. CVS에서는 사용할 수 없는 것들도 추가했다. Subversion에 대한 자세한 내용은 참고자료 섹션을 참조하라. 알다시피, Subversion의 명령어 세트는 CVS와 비슷하기 때문에, CVS 사용자들에게는 훌륭한 대안이다.

				
# Create a new repository
svnadmin create /home/user/new_repository

# Check out a sandbox from the central repository
svn checkout file:///server/svn/existing_repository new_repository

# Update a local sandbox from the central repository
svn update

# Check in changes from the local sandbox to the central repository
svn commit

# Add new files to the local sandbox (need to be committed)
svn add <file/subdirectory>

# Show changes made in the local sandbox
svn diff

# Rename a file in the local sandbox (requires commit to the repository)
svn rename <old_file> <new_file>

# Remove files (also removed from repository, requires commit)
svn delete <file/subdirectory>

CVS에 뒤이어, Subversion은 ViewCVS와 TortoiseSVN 같은 그래픽 프론트-엔드로 통합된다. CVS 리파지토리를 Subversion(cvs2svn.py)으로 변환하는 툴도 있지만, 복잡한 리파지토리들의 모든 브랜칭과 태깅 케이스들은 다루지 못한다. 모든 오픈 소스 프로젝트와 마찬가지로, 시간이 필요하다. Subversion은 또한 다른 뷰어와 패치 프로그램으로서 TortoiseMerge를 사용한다.

Subversion은 특정 파일들의 버저닝, 자동 커미트, 체크아웃 같이, CVS 사용자들이 고생했던 많은 문제들을 수정했다. CVS를 선호하고, 중앙 리파지토리 방식을 사용한다면, Subversion은 훌륭한 대안이 된다.

이제, 중앙 방식에서 벗어나서 SCM의 진정한 미래라고 할 수 있는 분야를 보자. 협업 분산 리파지토리(collaborative decentralized repositories)이다.

Arch

Arch는 많은 다양한 구현들을 제공하는 분산 SCM용 스팩이다. ArX, Bazaar, GNU arch, Larch 등이 이에 속한다. Arch는 분산 SCM을 사용할 뿐만 아니라(그림 2), changeset 모델 역시 사용한다. (그림 3) Arch SCM은 대중적인 오픈 소스 개발 방식이다. 개발자들은 완벽한 소스 컨트롤을 갖고 개별 리파지토리에서 개발할 수 있기 때문이다. 분산 리파지토리는 개정 컨트롤을 가진 실제 리파지토리이기 때문이다. 상위 개발자가 사용할 수 있도록, 로컬 리파지토리에 있는 변경 사항들로부터 패치를 만들 수 있다. 이것은 분산 모델의 정수이다.

Subversion과 마찬가지로, Arch는 CVS에서 발견된 많은 문제들을 수정했다. 파일 권한 개정, 파일 삭제와 리네이밍 처리, 자동 체크인(개별 파일이 아닌 체크인들을 함께 그룹핑 한다.) 같은 메타 데이터 변경 문제들을 해결했다.

Listing 3은 Arch SCM에서 볼 수 있는 명령어이다. Arch 아키텍트인 Tom Lord가 개발한 GNU Arch이다. GNU Arch는 SCM의 기본 기능과 더불어 Subversion에서 제공하는 새로운 기능도 추가했다.

				
# Register a public archive
tla register-archive http://www.mtjones.com/arch

# Check out a local repository from the upstream repository
tla get project@mtjones.com--dev/project--stable myproject

# Update from the local repository
tla update

# Check in changes to the local repository
tla commit

# Add new files to the local repository (need to be committed)
tla add <file>

# Show changes made in the local repository (patch format)
tla what-changed

# Rename a file in the local repository (requires commit to the repository)
tla mv <old_file> <new_file>

# Remove files (also removed from repository, requires commit)
tla rm <file>

Arch는 또한 상위 리파지토리에서 온 변경 사항들을 star-merge와 합병할 수 있도록 해준다. 기본 개정판(changeset 모델 당)에 적용되어야 하는 패치의 수를 줄이기 위해, cacherev 명령어는 리파지토리에 기본 개정판의 새로운 스냅샷을 만든다.

Arch의 장점은, 이것이 분산화된 작업을 위해 디자인 되었지만, 중앙 리파지토리 패러다임에도 사용될 수 있다는 점이다.

tla의 새로운 사용자가 가장 많이 불평하는 것은 약간 복잡하다는 것이다. baz 등, 다른 Arch 구현들은 더 간단하다. tla가 자신과 잘 맞지 않는다면 이들을 검토해 보는 것도 좋다.

리눅스 커널의 관리자, Linus Torvalds가 작성한 분산 SCM에 대해 알아보자.

Git

Git SCM은 Linus Torvalds가 Bitkeeper SCM(참고자료)의 대체로서 개발했다. 매우 단순하지만, 분산 changeset 기반 SCM 작업을 수행하고, 리눅스 커널용 SCM으로서 사용된다. 싱글 파일들을 트래킹 하는 대신 파일-그룹 모델을 사용한다. changeset는 SHA1으로 압축 및 해시(hash)되어 무결성을 검사한다. (Listing 4)

				
# Get a Git repository (first time)
git clone \
  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

# Update a Git repository from the defined upstream Git repository
git pull

# Checkout from the Git repository into the local working repository
git checkout

# Commit changes to the local Git repository
git commit

# Push changes to upstream (requires SSH access to upstream
git push

# Add new files to the local repository (requires commit)
git add <file>

# Show changes made to the local working directory
git diff

# Remove files (requires commit)
git rm <file>

Git SCM은 본연의 Git 리파지토리에서 호스팅된다. 로컬 머신에 설치하기 위해 Git를 부트스트래핑 해야 한다. Git용 명령어 세트는 지금까지 본 것들과 비슷하지만, 비교적 기본적이다.

기존 SCM을 사용해도 되는지를 묻는 사람들도 있다. 좋은 질문이다. Git는 매력적이고 리눅스 커널 해커들에게 대형 사용자 기반을 제공하기 때문에, 대형 SCM이라고 할 수 있다. Linus는 Git가 매우 빠른 디렉토리 콘텐트 매니저로서, 많은 것을 수행하지 않지만 효율적으로 수행한다고 설명하고 있다.

위로

장점

어떤 유형의 SCM을 사용하든지 간에, 각각 고유의 장점이 있다. SCM을 사용하면, 파일 변경 사항들을 추적하여 소프트웨어가 어떻게 진화했는지를 알 수 있다. 잘못된 변경 사항이 이루어지면, 이들을 찾아 원래 소스로 변환할 수 있다. 파일 개정판 세트를 그룹핑 하여, 여기에 태그를 달아서 언제라도 체크아웃 될 수 있는 릴리스를 만들 수 있다.

중앙 리파지토리나 분산 리파지토리, 스냅샷 또는 changeset 모델을 사용하든, 장점은 같다. 현대적인 소프트웨어 개발 프로젝트라면 SCM 없이는 불가능하며, 이들을 초기에, 종종 사용한다.

위로

맺음말

이 글에서는 오늘날 사용되는 SCM의 표면만 다루었다. Aegis, Bazaar-NG, DARCS, Monotone 등, 많은 오픈 소스 SCM들이 존재한다. 에디터와 언어들과 마찬가지로, SCM도 논란의 대상이 된다. 툴을 사용하고 싶다면 사용해도 좋다. SCM은 독립적으로 사용되지 않기 때문에 개인 보다는 팀에서 선택하게 된다. 따라서, 가능성을 타진하고, 다양한 스타일에 익숙해 질 필요가 있다. SCM은 소프트웨어 개발의 필수적인 툴이고, 엔지니어링 툴박스에 필수 요소이다.

기사의 원문보기

• Version control for Linux

참고자료

교육

• SCMs
  
  
• interesting paper
  
  
• Revision Control with Arch: Introduction to Arch (Linux Journal, November 2004).
  
  
• StatCVS offers a view into CVS repository activity (developerWorks, February 2005).
  
  
• Torvalds Gives Inside Skinny on Git (eWeek, April 2005).
  
  
• Kernel Hackers' Guide
  
  
• Version Control System Comparison
  
  
• GNU/Linux Application Programming (Charles River Media, January 2005)
  
  
• CVS for the developer or amateur (developerWorks, March2001).
  
  
• 디벨로퍼웍스 리눅스 존 (한글)
  
  
• developerWorks technical events and Webcasts
  
  

제품 및 기술 얻기

• CVS
  
  
• Subversion
  
  
• GNU arch
  
  
• Aegis
  
  
• Rational change and configuration management
  
  
• Order the SEK for Linux, a two-DVD set containing the latest IBM trial software for Linux from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  
• IBM trial software 다운로드 (한글)
  
  

토론

• developerWorks blogs developerWorks community (한글)
  
  

필자소개

M. Tim Jones는 임베디드 소프트웨어 아키텍트이자 GNU/Linux Application Programming, AI Application Programming, BSD Sockets Programming from a Multilanguage Perspective의 저자이다. 정지 위성용 커널 개발부터 임베디드 시스템 아키텍처와 네트워킹 프로토콜 개발까지 다양한 경험을 쌓았다. 현재, Emulex Corp의 컨설턴트로 일하고 있다.

아티클 순위

의견

위로

목차

• Software Configuration Management란 무엇인가?
• SCM 언어
• 아키텍처
• SCM 예제
• 장점
• 맺음말
• 참고자료
• 필자소개
• 의견