반응형

http://www.heartcomplex.net


게임 개발자를 위한 SVN -2-

SVN을 이용한 업무 프로세스

SVN의 기본 구성

SVN은 기본적으로 서버-클라이언트Sever-Client 구조를 기반으로 작동이 이루어진다. 당신이 SVN을 사용중인 개발팀에 배정되어 첫 출근을하게 되면 개발팀 전용 개발 서버가 있는 것을 볼 수 있을 것이다(아닐 수도 있다). 그리고 보통 개발 서버가 SVN 서버 역할을 하게 되며, 각 개인의 작업 컴퓨터가 SVN 클라이언트 역할을 한다. SVN 서버에는 저장소Repository라 불리우는 공간이 존재하며, 각 클라이언트는 이 저장소에 저장된 데이터를 검색하여 최신 작업물을 다운로드 받는다. 물론 각 클라이언트에서 작업된 작업물을 전송 받아 정리하고 보관하는 역할 역시 서버가 맡게 된다. 필요에 따라서는 서버-클라이언트 구조의 구분 없이 하나의 컴퓨터 안에 저장소를 배정하고 이를 다운로드하여 업무를 진행 할 수도 있다. 개별 컴퓨터에 SVN을 설치하고 별도의 폴더 내에 저장소를 생성하면 바로 사용이 가능하게 된다(이 문서에서는 SVN의 설치 및 관리 방법에 대해서는 설명하지 않으며, 추가 정보는 참고 문헌 항목을 참조 바란다).

SVN은 서버-클라이언트 구조로 동작한다

SVN의 물리적인 구성이 서버-클라이언트라고 한다면, 소프트웨어적인 구성은 저장소와 작업 복사본Working Copies으로 이루어진다. 저장소는 말 그대로 SVN과 작업물에 관련한 모든 기록을 저장하고 있는 공간이다. 저장소는 별도 형식으로 데이터가 저장되기 때문에 작업자가 직접 저장소가 저장된 폴더를 검색하여 내용물을 확인 할 수는 없다.

작업 복사본은 저장소에 있는 데이터를 작업자에게 복사한 별도의 작업 공간이다. SVN의 명령을 통하여 저장소의 데이터를 원하는 폴더에 내려받으면 작업 복사본이 생성된다. 작업 복사본은 하나의 컴퓨터에 다수로 생성이 가능하다. 작업 복사본은 일반적인 윈도우즈의 폴더 구성과 동일한 형태를 가지고 있다(폴더-파일이 존재한다). 때문에 파일이나 폴더의 기본적인 이용 방법은 일반적인 윈도우즈의 파일, 폴더 사용법과 동일하다. 작업 복사본의 모든 폴더에는 숨겨진 폴더 형태로 .svn이란 폴더가 존재하는데, 이 폴더는 SVN에서 관리하는 파일에 대한 명세 데이터Index Data가 존재한다(이 .svn 폴더를 전체 삭제해버리면 .svn 폴더가 존재했던 폴더 내의 모든 파일/폴더가 SVN의 관리에서 벗어난다 작업 복사물에서 그냥 일반적인 파일/폴더가 되어버린다).

SVN 작업 복사본의 폴더 구조

작업 복사본은 통째로 다른 장소로 복사하거나, 옮기는 것이 가능하다-그냥 폴더 통째로 다른 곳으로 복사/이동 하면 된다. 작업 복사본 내의 명세 데이터(.svn)만 손상되지 않는다면, 옮겨진 작업 복사본은 별 다른 이상 없이 정상적으로 작동한다.

기본 업무 프로세스

SVN을 이용하여 업무를 진행 하는 경우 보통 다음과 같은 프로세스를 거친다.

  • 작업물의 체크 아웃Check-out
    처음 작업을 시작 할 때, 저장소에서 작업물을 다운로드 하는 과정이다. 자신이 작업하게 될 컴퓨터에 최신 작업물들을 가져오는 것이다-원한다면 이전 시점의 작업물을 선택하여 받아 올 수도 있다. 이렇게 생성된 작업 복사본은 저장소에 있는 내용과 100% 동일한 새로운 복사본이기 때문에 어떠한 수정을 가하더라도 작업 복사본을 커밋Commit 하지 않으면 수정 사항은 저장소의 내용에 영향을 미치지 않는다. 체크 아웃은 보통 최초로 저장소의 내용을 다운로드 받기 위해 이용하며, 이후 작업 복사본의 내용을 갱신하기 위해서는 업데이트Update 명령을 이용한다.

  • 작업 복사본에서의 작업 수행
    체크 아웃 한 작업물을 이용하여 자신이 원하는 작업을 실시한다. 작업 복사본은 완전히 별개의 복사본이기 때문에 어떠한 수정을 가하더라도 언제든 저장소에 저장되어 있는 어떠한 시점으로 되돌릴 수 있다. 평소에 하던대로 문서 파일이나 그래픽 파일을 마음껏 수정하고 해당 파일을 저장한다.

  • 작업 복사본 업데이트Update
    자신이 작업 복사본을 가지고 열심히 일을 하고 있는 동안 당신의 팀원들 또한 자신들의 작업 복사본을 가지고 계속 새로운 내용을 SVN의 저장소에 갱신 할 것이다. 업데이트는 자신의 작업 복사본을 현재의 저장소의 최신 버전과 비교하여, 새로 갱신 된 파일이 있을 경우 해당 파일을 최신의 상태로 변경하여 준다. 최초의 체크 아웃 작업 저장소를 삭제하지 않았다면 업데이트로 자신의 작업 복사본을 항상 최신 상태로 갱신 할 수 있다.

  • 작업물을 저장소로 전송-커밋Commit
    작업 복사본에서 업무를 완료 하였으면, 자신의 작업물을 저장소에 전송 함으로써, 다른 작업자들이 해당 내용을 업데이트 받을 수 있도록 해야 한다. 작업물을 커밋 함으로써 SVN을 이용한 작업 사이클이 종료된다.

업무 프로세스의 변형

위에서 언급한 프로세스가 불변의 방식은 아니다-SVN을 이용한 업무 프로세스는 개인 혹은 집단에 따라서 다양하게 정립되어 있다. 때문에 팀원 간 SVN을 이용하는데 필요한 업무 약속Work Protocol을 공유하고 작업을 진행하여야 한다-팀의 작업 프로세스에 대해서는 팀 관리자나 SVN 관리자의 지침을 받으면 된다.

참고: 두 가지 관리 모델

리소스를 관리하고 업무 프로세스를 진행하는 데 있어 두 가지의 대표적인 모델이 존재한다. 이는 각각 잠금 중심 버전 관리, 통합 중심 버전 관리 불리우며, 각각의 관리 모델은 장단점을 가지고 있다. SVN에서는 기능상 두 모델의 적용이 모두 가능하나 기본적으로는 통합 중심 버전 관리 모델을 지원한다.

  • Lock-Modify-Unlock 모델 - 잠금 중심 버전 관리
    잠금 중심 버전 관리 기법은, 한 명의 사용자가 어떠한 파일을 열어 작업을 하고 있다면, 다른 사용자들은 해당 파일을 수정/저장 할 수 없게 함으로써, 하나의 작업물을 동시에 둘 이상의 사용자가 수정-커밋하여 작업물을 엉망으로 만드는 것을 미연에 방지하기 위해 고안된 관리 기법이다. SVN에서는 Lock 및 Unlock 명령을 이용하여 파일 혹은 폴더를 잠금/해제 상태로 만들 수 있는데, 잠금 상태로 지정 된 파일은 그것을 잠가 놓은 사용자 본인만 커밋이 가능하게 된다.

    Lock-Modify-Unlock Model

    작업물의 중복 및 이로 인한 손상을 미연에 방지할 수 있지만, 관리가 상당히 번거롭다는 것이 단점이다-어떤 사용자가 잠금 상태를 풀지 않으면 다른 사용자는 해당 파일을 이용한 작업이 불가능하게 되므로 작업 혼선이 올 수도 있다. SVN을 이용하여 잠금 중심 버전 관리를 하기 위해서는 잘 짜여지고 체계화된 업무 프로세스 확립이 필요하다.

  • Copy-Modify-Merge 모델 - 통합 중심 버전 관리
    통합 중심 버전 관리 기법은 잠금 중심 버전 관리와 다르게 모든 사용자가 하나의 작업물을 동시에 편집이 가능하다. 해당 작업물을 저장소에 커밋하게 될 경우 SVN에서는 각 사용자의 커밋 내용을 분석하여 자동으로 통합하게 된다. 다만, 자동 통합 과정은 텍스트Text 파일에 한해서만 가능하며, 동일한 지점에 대한 변경이 일어나게 될 경우 통합되지 않고 충돌Conflict을 일으킴으로써 누군가가 이를 수정을 해줘야 하는 문제가 발생한다.

    Copy-Modify-Merge Model

    바이너리 파일 등의 경우에는 작업물이 덮어씌워 질 수 있기 때문에, 만약 팀이 충분한 커뮤니케이션이 이루어지지 않은 경우 예기치 않게 작업물을 엉망이 되어버리는 위험도 존재한다. 통합 중심 버전 관리는 업무 프로세스 관리라는 측면에서는 잠금 중심 버전 관리 보다는 좀 더 현실적이지만, 작업물의 충돌에 많은 주의를 기울여야 한다.

SVN 기본 개념

사용자, 그룹 그리고 권한

SVN은 기본적으로 여러 사용자가 이용하기 때문에 각 이용자는 접근 권한을 가진다. SVN은 각 사용자에 대한 접근 권한을 지정 할 수 있으며, 비슷한 그룹의 사용자들을 그룹(예: 프로그램 그룹, 그래픽 그룹, 기획 그룹)으로 묶어 각 폴더에 접근 권한을 별도로 지정 할 수 있다. 개별 사용자들은 팀 내의 SVN 관리자로 부터 자신의 사용자 이름과 접근 패스워드를 부여 받게 되고, 해당 SVN 저장소에 접근을 할 때 부여받은 사용자 이름을 이용하게 된다.

SVN 저장소에 대한 권한은 읽기(저장소에서 작업 복사본 내려받기 권한), 쓰기(저장소에 작업 복사본을 커밋 하는 권한), 혹은 모두(읽기 및 쓰기)로 구분되어진다.

용어 설명

SVN 을 할 때 자주 접하게 될 주요 용어에 대해서 설명 한다.
  • 저장소Repository
    저장소는 작업물을 보관하고 있는 장소를 가리킨다. 이러한 장소는 별도의 네트워크 서버Server의 하드 디스크가 될 수도 있고, 개인 컴퓨터의 하드 디스크 내의 어떠한 폴더가 될 수도 있다.

    저장소는 각 사용자들이 보내온 작업 복사본과 비교를 하여 가장 최신의 버전을 유지한다. 또한 각 작업물에 대한 변경 이력을 기록하여 해당 파일이 어떤한 수정 과정을 거쳤는지에 대한 정보를 제공하는 역할을 한다. 이러한 저장소에 접근하기 위해서는 저장소에 대한 접근 권한을 가진 사용자 이름을 등록해야 하며, 사용자 이름 등록은 팀 내 SVN 관리자를 통하여 받을 수 있다.

  • 작업 복사본Working Copies
    작업 복사본은 저장소에서 내려받은 '복사본'을 의미한다. 해당 자료는 저장소에 보관되어 있는 최신 버전과 내용이 동일하며, 내용을 어떤식으로 변경을 하더라도, 저장소의 내용과는 무관하기 때문에 안전하게 작업을 진행 할 수 있다. 작업 복사본을 커밋하게 되면 작업 복사본에서 변경 된 내용이 저장소로 전송되며, 저장소는 해당 변경 사항을 반영하여 저장한다.

    자신 이외의 다수의 사용자가 SVN을 이용하고 있을 경우, 경우에 따라서는 나의 작업 복사본은 저장소에 저장된 내용과 비교하여 최신의 내용이 아닐 수 있다-이 때는 업데이트Update 명령을 이용하여 자신의 작업 복사본을 갱신해야 한다. 물론, 자신의 작업물을 다른 사용자들도 공유 할 수 있도록 자신의 작업 결과물을 저장소에 커밋을 하는 것도 잊지 말아야 한다.

  • 리비전Revision
    리비전은 작업물에 대한 일종의 버전Version으로 작업물에 대한 고유 번호이다. SVN은 작업물을 저장소에 등록 할 때 마다 등록 시점에 대한 고유 번호를 지정한다. 사용자가 작업물을 등록하면 해당 등록물 전체에 대하여 동일한 리비전이 붙게 된다.

    리비전이 붙는 방식은 단순하다. 누군가가 작업물을 커밋 하면 현재 리비전 번호에 +1 이 더해진다. SVN에서는 이러한 리비전을 검색하여 변경 이력 등을 확인 할 수 있다.

  • 기록Log
    SVN 은 각각의 리비전에 대해 기록을 남겨둔다. 여기에 작업 결과물을 등록 할 때 사용자는 적당한 메시지를 입력 하여 해당 기록에 첨부 할 수 있는 기능이 존재한다. 이러한 기록 메시지는 다른 팀원들이 해당 작업물의 변경 사항을 확인하는데 많은 도움을 준다. 기록 메시지은 사용자의 편의에 의해서 사용 할 수 있기 때문에 몇몇 작업자들은 해당 기능을 귀찮아하고 메시지을 남기는 것을 등한시 하는 경우가 있는데, 원할한 프로젝트 커뮤니케이션을 위해서는 기록 메시지 기능을 적절하게 사용하여 주는 것이 좋다.

  • 충돌Conflict
    동시에 같은 파일을 두 명 이상의 사용자가 수정 하고 이를 각각 커밋 할 경우, 해당 파일은 충돌을 일으키게 된다. 충돌이 일어날 경우 해당 파일의 수정 내용을 병합Merge 하거나, 혹은 두 파일 중 하나를 최신으로 지정하여 충돌 상태를 해결해야 한다. 충돌이 일어난 파일을 제때 처리하지 않게 되면, 최신 작업물을 제대로 확인하지 못하는 문제가 발생 할 수 있으므로, 충돌이 일어난 작업물은 즉시 충돌 상태를 정리해야 한다.

  • 병합Merge
    작업 복사본과 저장소에 있는 파일의 내용이 다를 경우, 병합 작업을 통하여 두 파일의 내용을 합치게 된다. 병합 과정은 주로 Text 파일 형식의 작업물에서 동작을 하게 되며 어플리케이션 데이터Application Data-그래픽 저장 파일(JPG, GIF 등)이나 문서 파일(DOC, PPT 등) 같이 전용 프로그램을 이용하여 만들어지고 저장된 데이터-나 바이러니 파일Binary Files의 경우 이러한 병합 기능이 별도로 지원되지는 않는다.

반응형
반응형






[원문게임 개발자를 위한 SVN -1- 들어가기에 앞서

게임 개발자를 위한 SVN -1-

들어가기에 앞서

십 수년 전, 혈기왕성하고 의욕만 앞선 친구들과 모여 게임 개발을 위한 팀을 조직하고, 게임 개발의 열정을 소모하고 있었을 때만 하더라도, 게임 개발은 젊은날의 열정과 패기만 가지고도 충분히 매력적이었고 재미있는 일이었다. 하지만 상업적인 목적의 게임 시장이 발전하기 시작하고 산업으로 그 규모가 커지기 시작하면서 부터 게임 개발은 점차 열정과 패기만으로 도전 가능한 일이 아니게 되었다. 모든 산업이 그러했듯 가내 수공업 형태에서 산업화가 이루어지기 시작하면 그에 수반하는 여러가지 새로운 장치들과 기법들을 필요로하기 시작한다. 게임 개발 역시 몇몇 사람이 누군가의 공부방이나, 창고에 삼삼오오 모여 꿈을 펼칠 때는 필요하지 않았던 프로젝트 관리 기법이나 커뮤니케이션 방법론, 프로세스 관리 기법 등이 점차 필요하게 되었다.

대한민국의 게임 산업은 지난 수십년간 다른 기성 산업들에 비하여 급격하게 성장을 하였지만, 게임을 개발하는 조직은 그 성장의 속도에 발빠르게 대처하질 못하고 있다. 대다수의 회사들은 여전히 오래전 아마추어 취미 활동 때의 추억을 가지고 무리하게 개발 팀을 운영하려는 과오를 저지르고, 세상에 알려지지도 못한 수 많은 개발 팀, 회사들이 생성되었다 사라지기를 반복하고 있다. 팀이 유지되지 못하고 사라지는 이유에는 여러 가지가 있을 수 있지만, 방만한 개발 프로세스 관리는 그 중 가장 심각한 원인이라 할 수 있다.

SVN은 보통 버전 관리 시스템Software Version Control System:SVCS이라 불리우는 개발 관리 도구이지만, 게임 개발 프로젝트에 동원되는 모든 데이터 리소스-프로그램 소스 코드, 기획 문서, 그래픽 리소스 등-를 관리하는 용도로 많이 쓰인다. 프로젝트의 작업 결과물에 대한 변경 관리, 변경 추적 등이 가능하며, 리소스 데이터의 공유 및 배포 역시 SVN을 통하여 사용이 가능하다.

아직까지는 대다수 의 게임 제작 프로젝트에서 프로그래머 그룹을 중심으로 SVN을 이용하는 경우가 늘고 있으나, 기획, 그래픽, 사운드 등 여타 파트의 경우에는 사용 방법의 난해함 등을 이유로 업무 자료의 관리에 공유 폴더나 메일 등을 이용하고 있는 경우가 대부분이다. 하지만, 점차적으로 SVN 등의 버전관리 시스템을 이용하여 데이터 리소스를 관리하는 프로젝트가 늘어나고 있기 때문에, 이러한 버전관리 프로그램의 개념과 사용법을 익히는 것은 파트를 막론하고 게임 개발자로서 기본적으로 익혀야 할 업무 기술이 되어가고 있다.

국내에서는 여러 블로그나 몇몇 프로그래밍 전문 서적 등을 통하여 SVN 혹은 기타 다양한 버전관리 소프트웨어의 사용법 등이 소개되고 있지만, 프로그래밍을 제외한 다른 파트의 게임 개발자들을 위한 가이드는 아직까지 존재하지 않은 것으로 알고 있다. 시스템의 도입 여부는 전적으로 팀의 의사결정에 따른 일이지만, 이를 도입한다 하더라도 처음 시스템을 접하게 되는 기성 개발자나 혹은 업계에 첫 발을 내딛는 신입 개발자들을 위한 가이드가 없다는 것은 커다란 불편사항 중 하나이다.

이 문서는 SVN을 개발 프로세스에 적용시키는 팀에서 SVN을 처음 접하게 되는 개별 팀원들을 위한 가이드를 목적으로 작성되었다. 전문적인 프로그래머나 오랫동안 버전 관리 시스템을 구축하여 운영하는 사람, 혹은 버전 관리 시스템의 운영에 대해서 배우고자 하는 사람들을 대상으로 한 것이 아니기 때문에 내용은 단순하고 어떤 부분은 편협한 정보만을 제공 할 수 있다. 문서 후반부에, 좀 더 세부적인 개념이나 사용 방법, 관리 운영 방법을 알고 싶은 분들을 위하여 참고 문헌에 서적 및 외부 자료 링크를 수록하였으니 참고하길 바란다.


버전관리 시스템-SVN 소개

프로그래머인 철수와 영희가 있었다. 둘은 얼마 안가 사랑에 빠졌고, 둘만의 사랑의 결실을 확인하기 위해 프로그램을 만들기로 결심한다. 주변 싱글 부대 소속 동료들의 질투 어린 시선에도 불구하고 둘만의 사랑의 프로젝트는 점차 결실을 맺는 것 같았다.

한창 개발이 진행되는 어느날, 두 사람은 서로의 작업물이 얼마만큼의 성과를 내고 있는지 궁금해졌다. 그래서 공유 폴더에 소스 코드를 한번에 몰아 넣고 빌드Build를 진행 해 보기로 결정했다. 모든 프로그래밍 업무가 그렇듯 한번에 되는 일은 그다지 없기 때문에, 둘의 코드는 빌더 안에서 각종 에러와 경고를 내뱉고 있었다. 둘은 이 정도 고난은 사내에서 펼쳐지는 싱글 부대원들의 중상 모략에 비하면 아무것도 아니라 생각하면서 버그를 정리하기 시작했다.

그렇게 빠르게 소스를 정리하기 시작하는 어느날, 철수는 main.cpp에 포함 된 Hero 클래스에 문제-속성 값에 바람둥이가 추가되어 있어 항상 다른 코드와 바람을 피웠다-가 있다는 사실을 발견하고 버그를 슥슥삭삭 잡기 시작했다. 같은 시각 자신의 집에서 코드를 검토하던 영희 역시 main.cpp에 포함 된 Heroine 클래스의 질투 속성이 프로그램의 전체 조화를 망치고 제 기능을 못하고 있다 판단하고 이를 뜯어고치기 시작했다. 둘은 비슷한 시각에 각자 자신의 작업물을 정리하고 이를 작업용 공유 폴더에 덮어씌웠다.

몇 일이 더 지나고 철수와 영희는 코드를 다시 한번 빌드 하기로 했다. 무슨 일이 벌어졌을까? 수정한 코드는 다른 누군가에 의해서 다시 원상 복구되어 이전과 동일한 버그를 발생시켰고, 둘은 서로 상대가 버그를 복구하고 있는 것이 아닌가 의심하기 시작했다. 예민해진 두 사람은 격한 말들이 오가기 시작했고, 결국 큰 소리로 서로를 비난하다 각자 서로의 사랑을 찾기로 했다. 그들의 사랑의 결실이었던 프로젝트는 그렇게 와해되어 버렸다.

위와 같은 경우(물론 농담이지만)는 보통의 상업/비상업적인 소프트웨어 개발 프로젝트에서는 여러 사람들이 모여 작업을 하기 때문에 위와 같은 상황이 자주 발생하곤 했다. 심각한 경우 프로젝트를 좌초시키기도 하는 문제로까지 발전하기 까지 하자, 사람들은 이러한 상황이 발생하는 것을 미연에 방지하고자 소프트웨어 버전 관리Software Version Management 또는 Software Version Control 기법을 탄생시켰다.

소프트웨어 버전 관리 기법을 지원하기 위한 프로그램 및 제반 요소를 버전 관리 시스템Version Control System이라 한다-시스템에 대한 명칭은 다양하게 존재하는데 RCSRevision Control System, SCMSource Code Managemet , SCSSource Control System 모두 동일한 의미로 사용된다. 소프트웨어 버전 관리 기법이 점차 발전하고 확장해가면서 버전관리 시스템 역시 다양하게 개발되었으며. CVSConcurrent Versions System, SVNSubversion, 소스세이프Source Safe 등, 이들 프로그램은 소프트웨어 버전 관리라는 동일한 목적으로 태어났다.

공유 폴더는 안되나요?-왜 버전 관리 시스템인가

위의 이야기에서 철수와 영희는 서로의 작업물을 하나로 합치면서 공유 폴더를 이용하였다. 만약 완벽하고 빈틈없는 업무 절차가 존재했다면 철수와 영희는 공유 폴더를 이용하여 충분히 프로젝트를 완료 할 수 있었을지도 모른다. 그러나 대부분의 사람들이 그러하듯, 철수와 영희 역시 실수를 저지르는 평범한 인간에 불과하다.

공유 폴더를 이용할 때 발생하는 가장 큰 문제는 변경된 작업물에 대한 기록이나 백업 등의 안전 장치가 전혀 존재하지 않는다는 점이다. 이를 막기 위해서 공유 폴더를 이용하여 작업을 할 때 파일명에 일일이 갱신 날짜나 시간, 버전 등을 삽입하는 경우가 종종 있으나, 이는 근본적인 해결책이 안 될 뿐더러, 자칫 잘못할 경우 리소스 관리 자체가 힘들게 된다.

버전 관리 시스템은 작업물에 대한 백업을 제공한다. 때문에 실수로 작업물을 날려버리거나, 잘못 정리된 작업물을 원하는 시점으로 되돌리는 작업을 손쉽게 진행 할 수 있다. 또한, 각 갱신 시점 별로 데이터를 누적하고 있기 때문에, 필요한 시점의 데이터를 거슬러 복구 할 수 있다.

최신 작업물의 유지와 배포에 대한 문제도 버전 관리 시스템을 이용하게 될 경우 깔끔하게 처리 할 수 있다. 버전 관리 시스템의 저장소와 각 클라이언트Client 가 연결되어있다면, 언제나 어디서든 모든 팀 구성원들은 서로 동일한 최신의(그리고 안전한)작업물을 가지고 작업을 진행 할 수 있다.

작업물에 대한 간단한 기록 및 검색 역시 버전 관리 시스템을 이용하면 관리가 가능하다. 변경 이력Change Log의 입력, 검색 기능을 이용하여 해당 작업물에 대한 변경내역을 파악하기 쉬워진다. 이 역시 공유 폴더에서는 사용할 수 없는 기능이다. 또한, 각 작업자 간 중복되는 작업물이나 동시에 작업한 작업물에 대한 병합Merge 기능을 제공함으로써, 위의 철수와 영희의 사례와 같은 일을 막아주기도 한다. 버전 관리 시스템은 각 작업자 간의 작업물을 하나로 취합할 때 발생할 수 있는 문제점들을 최소화 할 수 있다.

SVNSubversion 이란?



SVN은 오픈 소스 프로젝트Open Source Project로 제작된 버전 관리 시스템 구축 프로그램이다. 버전 관리 시스템의 운영에 필요한 모든 기능들을 갖추고 있으며, 대부분의 OS에서 구동이 가능하다. 다수의 프로젝트에 쓰이고 있기 때문에 다양한 통합 개발 환경IDE: Integrated Development Environment에 플러그 인을 지원하고 있다. 국내의 경우, IT 업계를 중심으로 프로젝트에 SVN을 도입하는 사례가 급증하고 있으며, 각종 게임 제작 프로젝트에서 전방위적으로 쓰이는 경우가 점차 증가하고 있다.


반응형

+ Recent posts