티스토리 뷰



형상 관리 시스템 하에서 본격적으로 코드 작성이나 문서 수정 등의 작업을 하려면 저장소에서 작업 사본을 받는 것으로 시작합니다. 개발이나 작업이 여러날에 걸쳐 이루어 지고 있다면 그 사이에 다른 사람들이 작업한 내용이 저장소에 등록 되었을 수도 있는데 이를 내가 작업하고 있는 작업 사본에 반영하는 작업이 업데이트입니다. 자주 업데이트 할 수록 작업의 혼선을 예방할 수 있습니다. 내가 수행하는 작업이 일정한 단계를 지나거나 완료되었다면 저장소에 커밋하는 것으로 작업을 완료 합니다.


■ 작업 사본 받기와(Checking out) 



작업 사본 만들기는 CLI로는 "svn checkout 서브버전URL 내려받을경로" 명령으로 수행할 수 있습니다. 윈도우에서는 토터스 SVN 컨텍스트 메뉴 >SVN Checkout으로 위의 그림과 같이 서브버전 URL과 내려받을 폴더를 지정하여 받을 수 있습니다.



최신 버전을 받으려면 "Revision" 영역에서 HEAD 리비전을 선택하면 되고 과거의 특정 리비전을 지정할 수도 있는데, 특정 리비전 선택은 명령어 옵션에서는 "-r 리비전 번호" 형태로 지정 합니다. 일단 작업 사본이 받아지면 해당 내용들은 원본 저장소 기준으로 변경 여부가 관리되고 윈도우 탐색기에서는 아이콘으로 변경 여부를 판단 할 수도 있습니다. 위의 그림을 보면 변경 사항이 없는 것은 녹색의 체크 아이콘으로 변경 사항이 있는 것은 적색의 느낌표 아이콘, 버전 관리 대상이 아닌 파일들은 청색의 물음표로 표시 됩니다.


■ 업데이트(Update)


작업 사본을 받아 작업중인 도중에도 저장소 내용은 다른 사람에 의하여 언제든지 수정될 수 있습니다. 이렇게 여러 사람이 협업을 진행하는 경우 동일한 파일을 수정하게 되면 상호간에 혼선이 발생할 수 있습니다. 이런 문제로 인한 혼란을 최소화하는 방법은 자주 서브버전 업데이트 작업을 수행하는 것입니다.

 

서브버전 업데이트는 최신 상태의 저장소와 현재 작업 사본의 리비전을 비교하여 저장소 기준으로 작업 사본 내용을 갱신하는 작업 입니다. CLI로는 "svn update"로 현재 경로를 업데이트 하거나 "svn update 작업 경로"로 지정 경로를 업데이트 할 수 있습니다. 윈도우에서는 작업사본 폴더의 팝업 메뉴>SVN Update를 선택하면 됩니다.

 

문제는 업데이트 과정에서 작업중인 파일이 저장소에서도 수정되어 충돌이 발생하는 경우 입니다. 동일한 파일을 수정하더라도 대부분은 업데이트가 가능 합니다. 소스 코드의 경우 내가 수정하고 있는 부분이 10~100라인이고 다른 개발자가 다른 부분을 수정했다면 이런 경우는 충돌 없이 현재 수정하고 있는 소스 코드에 다른 사람이 수정한 부분이 자연 스럽게 업데이트 됩니다. 그러나 서브버전이 자동적으로 업데이트 할 수 없다고 판단한 경우는 충돌이 발생한 것을 알리기 위해서 주황색 느낌표로 아이콘을 표시하고 파일에는 해당 부분을 구분해서 표시해 놓습니다. 충돌의 해결은 작업 사본의 작업 내용을 취소(Revert)하는 방법과 작업사본의 작업 내용을 보존하면서 저장소의 내용을 반영하는 방법(Resolved)이 있습니다.



■ 파일 충돌(File Conflict) 


저장소와 작업 사본이 동일한 파일을 수정하더라도 서로 다른 라인을 수정하면 저장소 내용을 작업 사본에 반영(Merge)하는 방식으로 정상적으로 업데이트되지만 동일한 라인을 수정한 경우에는 무엇을 최종으로 삼아야 할지 프로그램 입장에서는 알 수 없으므로 업데이트 프로그램은 해당 파일에 아래의 형식과 같이 마킹을 포함하여 작업 사본과 저장소의 내용을 모두 담아 작업자가 직접 판단할 수 있도록 합니다(코드 내용속에 직접 들어가므로 이상태로 컴파일하면 당연히 오류가 발생하므로 반드시 수정해야 합니다). 또한 작업중 파일을 *.mine으로, 업데이트 이전 리비전 기준의 저장소 파일을 *.rNNN로, 업데이트 이후 저장소 파일을 *.rNNN으로 따로 저장해주어 충돌 해소를 위한 자료로 제공 합니다.


<<<<<<< 파일명

    작업 사본 내용

=======

    저장소 내용

>>>>>>> 리비전 번호


마킹을 제거하고 적절하게 수정하는 방법으로 충돌을 해소시킨 다음에는 CLI에서는 "svn resolved 충돌경로" 명령으로, 윈도우 탐색기에서는 충돌 경로의 컨텍스트 메뉴>TortoiseSVN>Resolved를 수행합니다. 단, 이 작업은 자동으로 문제를 해소시켜주는 것이 아니라 충돌시 자동 생성된 *.mine과 *.rNNN파일을 삭제해주는 것이므로 반드시 수작업으로 충돌 부분을 수정해야만 합니다.


한가지 주의할 점은 프로그램 소스 코드나 기타 텍스트 파일들은 원본에 마킹을 하면서 *.mine과 업데이트 전후 리비전 *.rNNN파일 총 3개의 파일을 자동 생성하지만 *.exe, *.dll, *.doc, *.ppt등의 바이너리 파일은 어떤 부분이 수정되었는지 표시할 수 없는 바이너리 파일로 원본 파일에의 마킹도 없고 *.mine도 생성하지 않습니다. 바이너리 파일은 파일의 한군데만 수정되어도 충돌이 발생되므로 *.obj같은 임시적 성격의 바이너리 파일들은 버전 관리에서 제외하는 것도 방법이지만 *.doc, *.ppt, *.xls 같은  문서 파일들을 버전 관리하다가 충돌이 발생하면, 즉 누군가가 먼저 수정한 파일을 업데이트 하지 않은 상태에서 수정하고 있다가 충돌이 발생하면 내용을 반영(Merged)할 방법이 없고 어떤 파일을 최종 파일로 선택할지만 남기 때문에 바이너리 문서에 수정한 내용이 많은 경우에는 직접 리비전간 차이를 찾아서 적절하게 반영해야 합니다. 바이너리 파일의 충돌에 대해서 Resolved 처리하면 작업사본을 기준으로 계속 작업하겠다는 것이고, 충돌 경로 팝업 메뉴>TortoiseSVN>Revert 또는 CLI로 "svn revert 충돌경로" 명령을 수행하면 작업 사본의 수정 내용을 취소하고 저장소의 최종 내용을 반영할 수 있습니다.(Revert 처리도 충돌로 인한 임시 파일들을 삭제 합니다)



■ 속성 충돌(Property Conflict) 



많이 발생하지 않는 사례이긴 하지만 파일의 내용이 아닌 서브버전이 관리하는 속성 정보에서 충돌이 발생한 경우 입니다. 위의 그림은 서브버전에서 설정하는 속성의 예제로 탐색기 팝업 메뉴>TortoiseSVN>Properties에서 설정하거나 CLI에서는 "svn propset 속성 속성값 대상경로" 명령으로 설정할 수 있습니다. 


속성의 경우에도 파일 내용 중에 동일한 라인으로 수정 내용이 겹치지만 않으면 충돌없이 반영되는(Merged) 것처럼 동일한 속성이 아니면 업데이트 시점에 충돌없이 속성을 반영 합니다. 그렇지만 동일 속성에 대해 수정인 상태에서 저장소의 내용을 업데이트 하면 속성 충돌이 발생 합니다. 속성 충돌이 발생하면 *.prej라는 파일이 아래와 같은 형태로 생성되어 어떤 충돌이 있는지 안내해 줍니다.


<<<<<<< (local property value)

Id Revision

=======

Author Id

>>>>>>> (incoming property value)


충돌을 해소하는 방법은 저장소 속성과 작업 사본의 속성을 비교하여 충돌 파일의 팝업 메뉴>TortoiseSVN>Edit Conflicts에서 [Resolve using local property]로 작업 사본 내용을 기준으로 충돌을 해소하거나 직접 수정해서 해소할 수 있습니다.



충돌 해소이후에는 파일 충돌처럼 Resolved 처리를 꼭 수행 합니다.(속성 충돌을 Resolved 처리하면 *.prej 파일을 자동 삭제 합니다.



■ 트리 충돌(Tree Conflict) 



누군가 파일이나 폴더를 이동 또는 이름변경 및 삭제 해서 저장소에 커밋했는데 다른 쪽 작업 사본에서 동일한 파일 및 폴더를 수정하고 있거나 이동 또는 이름변경 및 삭제한 상태에서 서브버전 업데이트를 수행하면 업데이트 프로그램은 어느 쪽이 최종 작업인지 알지못하는 트리 충돌이 발생 합니다. 트리 충돌이 발생하면 파일 충돌이나 속성 충돌 때와는 다르게 임시 파일을 생성하지 않고 경우의 수도  다양하므로 신중한 판단과 작업이 필요 합니다. 윈도우에서는 충돌 파일의 팝업 메뉴>TortoiseSVN>Edit Conflicts를 수행하면 위의 그림과 같이 트리충돌 해소를 쉽게 할 수 있도록 기능을 제공하고 있습니다.


위의 예제에서 Resolved 처리는 [Keep the local file]을 클릭하는 것으로 일단 저장소 내용 처럼 파일 삭제 처리후 작업 사본의 작업중 파일을 추가한 상태가 되고, Revert 처리는 작업 사본의 내용을 무시하고 저장소 처럼 파일을 삭제하는 [Remove the file]과 동일 합니다.



■ 작업 완료하기(Commit)


버전 관리 기반으로 작업하려면 저장소에서 최종 코드를(HEAD 리비전) 내려받아 작업 사본을 준비하고 작업 사본에 대한 수정 작업을 진행하면서 저장소의 최신 내용을 자주 업데이트 해야 한다고 앞서 언급했는데 자주 업데이트 할 수록 충돌을 미연에 방지하거나 충돌로 인한 오버헤드를 최소화 시킬 수 있습니다.

 

작업 사본에 있는 파일을 수정하는 작업과 달리 새로운 파일 생성하거나 삭제 및 이동하는 작업은 일반 파일의 생성과 삭제 및 이동과 차이가 있습니다. 예를 들어 작업 사본에 있는 파일 하나를 삭제해도 실제 버전 관리에는 영향이 없다. 서브버전 업데이트를 수행하면 삭제된 파일을 저장소에서 다시 가져오기 때문 입니다. 파일 이름을 변경하는 경우도 마찬가지 입니다. 작업 사본에 있는 파일 이름을 변경한 상태에서 서브버전 업데이트를 수행하면 버전 관리 입장에서는 관리 대상 파일이 하나 없어진 것으로만 인식하기 때문에 이름이 변경된 파일에 관계없이 원래 파일을 저장소로부터 새로 가져 옵니다. 파일 생성도 마찬가지로 작업 사본 폴더에 새로운 파일을 생성해도 버전 관리에서는 아무런 관리도 하지 않고 저장소를 통해서 다른 이와 공유할 수도 없습니다.


 

버전 관리 대상으로의 추가는 CLI에서는 "svn add 신규경로" 명령을 수행하고 윈도우 탐색기에서는 새로운 폴더나 파일의 팝업 메뉴>TortoiseSVN>Add로 수행할 수 있습니다. 위의 그림은 특정 폴더를 추가한 경우로 하위 폴더까지 자동 추가되는데 "Enable Auto-Properties"를 체크하면 바이너리 파일등 특정 파일 형태에 대하여 자동으로 속성을 설정해 줍니다. 한가지 주의할 점은 폴더 단위로 추가하면서 버전 관리에 불필요한 임시 파일등이 포함되지 않도록 추가 대상 리스트를 점검해보아야 힙니다. 예를 들어 프로젝트 빌드 과정에 임시로 생성하는 오브젝트 파일등을 형상 관리 대상으로 추가하는 작업은 피해야만 합니다.


위의 버전 관리 대상 추가 화면의 "Enable Auto-Properties"는 추가하려는 폴더에 자동 속성 설정 기능을 부여할것인지를 묻는 것으로 *.c, *.java, *.txt 같은 텍스트 파일 형태의 소스 코드나 문서에 작업 완료 시점에 자동으로 작성자, 최종수정일, 리비전등의 정보를 삽입할 수 있도록 하는 것입니다. 자동 속성 설정 기능을 사용하기 위해서는 우선 환경 설정이 필요한데 서브버전의 설정 파일은 리눅스등의 경우에는 ~/.subversion/config 또는 /etc/subversion/config를 수정하면 되고 윈도우의 경우에는 %APPDATA%\Subversion\config를 수정하거나 탐색기 팝업메뉴>TortoiseSVN>Settings창에서 General>Subversion 영역에 있는 Subversion configuration file 옆에 있는 [Edit]버튼을 클릭해서 설정 파일을 수정할 수 있습니다.



설정 파일을 수정한 다음에는 저장해야 적용되므로 저장에 주의하고 수정할 내용은 아래의 예와 같이 [auto-props] 섹션에 파일 종류별로 어떤 속성을 자동 설정할 것인지를 지정하는 것과 enable-auto-props = yes로 설정하는 것입니다. 설정 파일 각 라인 별로 맨앞에 #이 붙은 줄은 주석이므로 enable-auto-props = yes 앞의 #을 지워야 자동 속성 설정이 가동 됩니다. 


enable-auto-props = yes
### Set interactive-conflicts to 'no' to disable interactive
### conflict resolution prompting.  It defaults to 'yes'.
# interactive-conflicts = no
### Set memory-cache-size to define the size of the memory cache
### used by the client when accessing a FSFS repository via
### ra_local (the file:// scheme). The value represents the number
### of MB used by the cache.
# memory-cache-size = 16

### Section for configuring automatic properties.
[auto-props]
### The format of the entries is:
###   file-name-pattern = propname[=value][;propname[=value]...]
### The file-name-pattern can contain wildcards (such as '*' and
### '?').  All entries which match (case-insensitively) will be
### applied to the file.  Note that auto-props functionality
### must be enabled, which is typically done by setting the
### 'enable-auto-props' option.
# *.c = svn:eol-style=native
# *.cpp = svn:eol-style=native
# *.h = svn:keywords=Author Date Id Rev URL;svn:eol-style=native
# *.dsp = svn:eol-style=CRLF
# *.dsw = svn:eol-style=CRLF
# *.sh = svn:eol-style=native;svn:executable
# *.txt = svn:eol-style=native;svn:keywords=Author Date Id Rev URL;
# *.png = svn:mime-type=image/png
# *.jpg = svn:mime-type=image/jpeg
# Makefile = svn:eol-style=native
*.txt=svn:keywords=Author Date Revision HeadURL


위의 설정 파일에서 맨 아래에 있는 설정의 의미는  *.txt 확장자를 가진 파일들에 대해서 작성자, 수정일시, 리비전, URL 정보를 파일 속에 자동 입력하라는 설정입니다. 개발자가 입력하지 않아도 커밋 시점에 지정한 내용들을 서브버전이 자동 입력하는 것입니다. 서브버전 설정이 준비되었으면 다음으로 필요한 것은 개별 파일에 대한 템플릿 작성과 서브버전 속성 설정 작업 입니다.


통상 소스 코드에 주석문의 형태로 템플릿을 작성해 두면 관련 정보가 삽입되더라도 코드에 영향이 없으므로 상당히 유용한 방법 입니다. 아래는 단순 텍스트 파일의 앞부분에 삽입한 템플릿 예제로 키워드가 일치하는 곳에 해당하는 최신 정보가 삽입 됩니다.


/*

$Author: $

$Date: $

$Revision: $

$HeadURL: $

*/



코드에 템플릿이 준비되어 있다면 끝으로 서브버전 속성을 설정하면 자동 속성 설정을 위한 준비는 모두 끝이 납니다. 속성 설정은 탐색기 팝업 메뉴>TortoiseSVN>Properties에서 설정하거나 CLI에서는 "svn propset 속성 속성값 대상경로" 명령으로 설정할 수 있습니다. 속성은 New>Keyword로 추가할 수 있는데 에제에서는  Author, Date, Revision, URL를 선택하여 서브버전 환경 설정에서 *.txt의 자동속성 설정을 위한 속성들과 일치 시켰습니다.


서브버전 환경 설정, 개별 파일의 템플릿 준비 및 속성 설정까지 끝낸 상태에서 커밋(작업 완료, Commit)처리하면 파일은 아래와 같이 템플릿에 지정한 형식으로 자동 작성되어 저장소로 보내어 집니다.


/*

$Author: futuretech $

$Date: 2013-07-03 17:25:22 +0900 (수, 03 7 2013) $

$Revision: 19 $

$HeadURL: file:///D:/tmp/testsvn/trunk/test1.txt $

*/



버전 관리 대상에 추가하면 윈도우에서는 청색 + 아이콘으로 표시하고, 수정한 것은 적색의 느낌표 아이콘으로 표시하지만 삭제한 경우는 실제 작업 사본에서도 삭제하기 때문에 파일 탐색기에서는 삭제 여부를 인지하기 어렵 습니다. 작업 사본에서 삭제하는 방법은 CLI로는 "svn delete 삭제경로"명령으로 수행하고 윈도우 탐색기에서는 삭제 폴더나 파일의 팝업 메뉴>TortoiseSVN>Delete를 수행하면 됩니다. 단, 작업 사본에는 추가했지만 아직 저장소에 저장하기 이전인 파일들은 CLI "svn revert 파일명" 명령이나 팝업 메뉴>TortoiseSVN>Undo Add로 삭제를 취소 할 수 있습니다.




추가, 변경, 삭제를 비롯해서 작업 사본에 대한 작업 상황을 파악하는 방법은 CLI로는 "svn status" 또는 "svn status 경로" 명령으로 수행하고 탐색기 팝업 메뉴>TortoiseSVN>Check for modifications을 통해서 위와 같이 확인할 수 있습니다.



Check for modifications는 작업 사본의 작업 내용 뿐만아니라 [Check repository]버튼으로 저장소에서의 변경 내역 즉, 체크아웃이나 업데이트 이후 타인의 변경이 있었으나 아직 작업 사본에 반영하지 않은 항목들도 확인할 수 있어서 업데이트 내용과 반영 규모에 따라 이후 실제 업데이트 여부를 결정할 수 있습니다. 또한 리스팅 항목을 클릭하고 팝업 메뉴>Compare with base를 선택하면 작업사본과 저장소의 "Working Base"(작업사본이 변경된 경우) 또는 작업 사본과 저장소의 remote file간의(저장소가 변경된 경우) 비교를 위와 같이 확인할 수 있습니다.



파일 및 폴더의 복사와 이동은 윈도우에서는 두가지 방법으로 수행할 수 있습니다. 첫번째 방법은 우측 마우스 Drag & Drop으로, 이동 및 복사할 대상을 우측 마우스로 드래그(Drag)하여 목적지에 드롭(Drop)하면 아래와 같은 메뉴가 나오는데 이때 "SVN Move..." 또는 "SVN Copy..."을 선택하여 이동 및 복사하는 방법 입니다. 이 때 주의할 점은 평소에 많이 사용하는 왼쪽 마우스 Drag & Drop이 아니라 탐색기에서 우측 마우스 Drag & Drop을 사용해야 하는 것과 목적지가 반드시 버전 관리 대상 폴더여야 한다는 것입니다. 버전 관리 대상이 아닌 폴더를 목적지로 하면 "SVN..." 메뉴가 나오지 않습니다.



두번째 방법은 탐색기에서 이동 및 복사할 대상을 팝업메뉴로 복사 또는 잘라내기하고 버전 관리 대상인 폴더의 팝업 메뉴>TortoiseSVN>Paste로 이동 또는 복사를 수행하는 것입니다.


내부적으로 이동은 복사후 삭제로 구성되는데 이동으로 CLI 명령으로는 "svn move 원본 대상", "svn mv 원본 대상", "svn rename 원본 대상", "svn ren 원본 대상"이 모두 같은 의미로 동작할 수 있다. 복사 및 삭제 명령으로 바꾸어 보면 "svn copy 원본 대상", "svn delete 원본"으로 이루어 질 수 있습니다.



수정이든 삭제, 추가, 이동, 복사, 이름 변경이든 작업 사본에 대한 로컬 작업은 작업 완료 처리를 하지 않으면 저장소에 반영되지 않고 타인들과 내용을 공유할 수도 없습니다. 작업을 완료했으면  작업 사항을 위에서 언급한 "svn status" 명령이나 탐색기팝업 메뉴>TortoiseSVN>Check for modifications를 통해서 확인하고 최종적으로 "svn commit -m 로그메시지 완료 경로"명령이나 완료 경로 탐색기 팝업 메뉴>SVN Commit으로 로그 메시지와 함께 커밋하면 됩니다. 


커밋 시점에서 주의할 사항은 커밋과 동시에 리비전이 올라가는데 이미 타 개발자에 의해 커밋된 것이 있는지 최신 버전으로 업데이트 한 다음 커밋을 수행하는 것과 로그 메시지를 정확히 입력해서 연관되는 이슈 트래커 번호나 기타 정보가 충분히 로그 메시지에 남도록 해야 하는 것입니다.





댓글
댓글쓰기 폼