• Ubuntu Oneiric Ocelot 11.10에서 Test 완료 (2012-01-05)

“Nautilus에서 Source Code를 Subversion으로 관리하자 : RabbitVCS”의 마지막 Post로 이전 Part 1, Part 2에 이어서 Branch/Tag, Merge에 대해서 설명하도록 하겠습니다. 예제를 가지고 설명하기 때문에 이전 Post를 간단하게 읽어보기를 권합니다.

14. Branch/Tag

Project를 진행하다가 새로운 기능을 추가하기 위해서 Test를 위한 Project를 만들어야 할 때가 있습니다. Pilot Project로 Test하는 경우도 있지만 현재 Project Source를 가지고 Test하면서 그 Code를 Subversion으로 관리하는 경우가 대부분일 것입니다.

이럴 때 사용하는 것이 Branch라는 기능입니다. Branch는 사실 기능이 아니라 개념으로써, 설명한 것과 같이 Project의 새 기능 추가 Test 등의 이유로 현재 Project 저장소에 있는 Code를 그대로 복제하여 새로운 곁가지 Project를 만드는 것을 의미합니다.

Branch Project를 통해서 새 기능을 추가하거나 Test한다고 하더라도 Trunk에 존재하는 최신 Source에 대해서는 영향이 미치지 않으며 나중에 Branch에 있는 Code를 Trunk에 통합할 수도 있습니다.

Hello Project의 Branch를 만들어 보면서 그 기능을 간단히 알아봅시다.

RabbitVCS - Branch

Hello Project Folder 내의 Branches Folder에서 Mouse 오른쪽 Button Popup을 띄운 후, RabbitVCS -> Branch/Tag를 Click합니다.

Branch/Tag Dialog

Branch/Tag Dialog에서는 다음과 같은 내용을 설정할 수 있습니다. (위의 그림은 Hello Project의 trunk를 branches/hello-dev로 Branch 하는 경우를 나타냄)

• Repository : From – Source를 가져올 Project 저장소를 나타냅니다. To – 가져온 Source를 저장할 Directory를 설정합니다.
• Create copy from : Source를 Project 저장소에서 가져올 때 어느 Source를 가져올 지를 결정하는 것으로 HEAD를 선택하면 최신을, Number를 선택하면 원하는 Revision을 가져올 수 있습니다.
• Add message : Branch에 대한 Log Message를 입력합니다.

Completed branch

Branch/Tag Dialog에서 설정한 후 확인을 누르면, 위의 그림과 같이 Hello Project의 Branch인 hello-dev가 생성됩니다.

Branched hello

Hello Project의 branches/hello-dev Folder안에 현재 trunk의 최신 Source인 test.c가 존재하는 것을 확인할 수 있습니다. 이제 Branch가 완료되었으니 hello-dev에서 새 기능을 위한 Code를 작성하면 됩니다.

RabbitVCS - Tag

이번에는 Tag에 대해서 알아보도록 하겠습니다. Project가 어느 정도 안정화 되어 Version Up을 할 경우 이것을 배포하거나 따로 Source를 관리할 필요가 생기게 됩니다. 이럴 때 사용하는 것이 Tag 기능으로 간단하게 현재 trunk의 Source를 복제하여 Project의 Tag Folder 안에 관리하는 것을 의미합니다.

Tag를 사용하기 위해서는 Branch와 동일하게 Project의 tags Folder 안에서 Mouse 오른쪽 Button Popup을 띄운 후, RabbitVCS -> Branch/Tag를 Click합니다.

Branch/Tag Dialog

Branch/Tag Dialog에서 Tag를 위해서는 Repository의 To에 대한 경로를 Project tags Folder내에 경로로 지정해 주면 됩니다. (위의 그림은 trunk의 현재 최신 Source를 tags/hello-1.0으로 복제하는 경우를 나타냄)

Completed tag

Tag가 완료되면 hello-1.0이 tags Folder 안에 생성됩니다.

Tagged hello

Tag 완료 후, tags/hello-1.0의 모습입니다.

Commit branch and tag

Branch와 Tag가 완료되었지만 여기서 끝난 것은 아닙니다. Project 저장소에는 Branch/Tag를 한 Source가 아직 등록되지 않았기 때문에 생성된 Folder를 Project 저장소에 등록하기 위해 반드시 Commit을 해야 합니다.

위의 그림은 Commit Dialog의 예로 Branch를 통해 hello-dev가, Tag를 통해 hello-1.0이 생성된 것을 Commit하는 모습입니다. Commit이 완료되면 Branch와 Tag로 생성된 Directory가 Project 저장소에 적용됩니다.

15. Merge

위에서 알아봤던 Branch 기능으로 새 Branch를 만들어 새 기능의 개발을 끝내게 되었다면, 이제 원래 Source Tree에 합쳐서 새 기능이 적용되도록 만들어야 할 것입니다. 이 경우에 사용하는 것이 바로 Merge 기능입니다.

이전에 Branch로 만들었던 hello-dev를 가지고 Merge 기능에 대해서 알아봅시다.

branches/hello-dev/test.c를 다음과 같이 Postfix 연산을 Function으로 따로 만들어 저장합시다.

RabbitVCS - Commit branched source

Commit Dialog

이제 저장된 branches/hello-dev/test.c를 Commit하여 Project 저장소에 적용시킵니다.

RabbitVCS - Merge

이제 hello-dev와 trunk의 현재 Source를 합쳐보도록 하겠습니다. trunk Folder를 선택한 다음, Mouse 오른쪽 Button Popup에서 RabbitVCS -> Merge를 Click합니다.

Merge Type

Merge 과정을 위한 Dialog가 표시됩니다. Step1 에서는 Merge Type을 선택할 수 있는데 각 Type은 다음과 같습니다.

• Merge a range of revisions : 대상 Folder에 하나의 Source Tree를 병합합니다. 1개의 branch에서 원하는 revision의 변경부분만 대상 Folder에 통합할 수도 있습니다.
• Merge two differenct trees : 대상 Folder에 2개의 다른 Source Tree를 병합합니다. 2개의 branch의 내용을 병합하기 위해서 사용합니다.

여기에서는 1개의 branch를 병합하는 것이므로 Merge a range of revisions를 선택하고 앞으로를 누릅니다.

Merge a range of revisions

Step 2에서는 합칠 branch의 정보를 입력합니다. 각 Field에는 다음을 입력합니다.

• URL to merge from : 대상 Folder에 통합할 Branch의 Project 저장소 URL을 입력합니다.
• Revision Range : 통합할 Branch에서 선택한 Revision만을 대상 Folder에 적용할 수 있습니다. comma(,)로 여러개를 입력할 수 있고, dash(-)는 범위를 나타냅니다. 옆의 돋보기 Icon을 Click하면 Commit Log를 통해서 원하는 Revision을 선택할 수 있도록 도와줍니다.
  

  Revision Log

대부분의 경우 Branch가 된 시점에서 부터 최신 Revision까지를 적용하게 됩니다. Commit Log를 보니 Revision 6에서 branch가 되었기 때문에 Revision Range에 6-HEAD(Revision 6에서 최신 Revision까지)를 입력해서 병합해 봅시다. 모두 입력했다면 앞으로를 누릅니다.

Final Options

Step3에서는 Option을 설정할 수 있습니다. Recursive(하위 Folder까지 병합)는 반드시 선택합니다. Test Merge를 눌러서 Merge 설정이 제대로 되었는지 그리고 병합시 문제가 없는지를 Test해 봅시다.

Merge Dry Test

Test Merge가 제대로 수행이 되었다면 위와 같이 merge_completed Message가 표시될 것입니다. 이상이 없다면 확인을 누른 후, Merge Dialog에서 적용을 누릅니다.

Merge Complete

Test Merge가 성공적으로 끝났기 때문에 Merge도 위와 같이 정상적으로 이루어질 것입니다.

Nautilus - Merged trunk folder

Nautilus에서 병합된 trunk Folder를 확인해봤습니다. 저의 경우는 branch된 이후로 trunk의 Source가 변경되었기 때문에 Conflict가 발생했네요. 생성된 각 File은 다음과 같은 의미를 갖고 있습니다.

• test.c.merge-left.r6 : Merge Dialog에서 입력했던 Revision Range의 시작 Revision의 Source입니다.
• test.c.merge-right.r15 : Merge Dialog에서 입력했던 Revision Range의 끝 Revision의 Source입니다.
• test.c.working : 병합되기 전 대상 Folder에 존재한 Source입니다.

Merge로 일어난 Conflict는 Update로 발생한 Conflict와 마찬가지로 해당 Source(여기서는 test.c)를 수정한 다음, Resolve 기능을 사용하면 문제가 해결됩니다.

Commit Dialog

Merge가 완료되었다면 Project 저장소에 적용하기 위해 Commit을 실행합니다. Commit까지 정상적으로 완료되었다면 Merge에 대한 모든 과정이 끝나게 됩니다.

16. GEdit – RabbitVCS Plugin

Gedit - RabbitVCS Plugin

마지막으로 Gedit를 위한 RabbitVCS Plugin을 소개합니다. RabbitVCS Plugin을 설치하면 Subversion으로 관리되는 Source를 Gedit로 편집할 경우 Gedit 상에서 RabbitVCS의 기능을 편리하게 사용할 수 있습니다.

설치를 위해서 Terminal에서 다음과 같이 입력합니다.

Gedit - Preferences

설치된 RabbitVCS Plugin을 사용하기 위해서는 Gedit를 실행한 다음, 편집 -> 기본 설정 -> 플러그인 Tab에서 RabbitVCS를 Check한 후 닫기를 누르면 됩니다.

17. 마치면서…

이상으로 RabbitVCS를 설치하는 방법과 각 기능에 대해서 간단하게 알아보았습니다.

Source Code를 Subversion으로 관리할 때 IDE에서 제공하는 기능을 주로 사용함과 동시에 Nautilus에서 편하게 관리할 수 있는 RabbitVCS를 사용한다면 좀 더 편리하게 Source를 관리할 수 있을 것이라 생각합니다.

그럼 즐거운 Programming 생활(?)이 되시길..

• Ubuntu Oneiric Ocelot 11.10에서 Test 완료 (2012-01-05)

이번 Post에서는 Part 1에 이어서 RabbitVCS를 통해서 Nautilus에서 Source Code를 Subversion으로 관리하는 방법을 알아보도록 하겠습니다. 예제를 가지고 기능을 설명하기 때문에 이전 Post를 간단하게 읽어보는 것이 이해하기 쉬울 것입니다.

8. Diff

Project의 Source를 고친 후에 고치기 전과 어느 부분이 변경되었는지 궁금할 때가 있습니다. 특히 Project의 Source가 방대할 경우 Commit Log를 작성할 때 어떤 부분을 변경했는지 제대로 기억나지 않거나, Source를 잘못 수정한 경우에 이전 Source와 차이점을 확인해야 할 필요가 생깁니다. 이럴 경우 Diff 기능을 사용하여 차이점을 확인할 수 있습니다.

이전 Post에서 Update 받았던 trunk/hello.c (Console에 Hello, World!를 출력하는 Code)를 다음과 같이 Function 호출을 사용하도록 고쳐봅시다.

RabbitVCS - Diff

그 다음, 변경한 hello.c에 대한 차이점을 보기 위해서 hello.c를 선택한 다음, Mouse 오른쪽 Button Popup에서 RabbitVCS -> Diff를 선택하면 다음과 같은 5가지 Menu가 표시됩니다. (수정되지 않았을 경우에는 3가지)

• View diff against base : 작업하고 있는 Source의 현재 Revision의 수정되기 전 Code와 수정된 Code를 diff 명령을 통해 비교한 결과를 Gedit로 표시합니다. (수정되지 않은 경우에는 표시되지 않음)
• View diff against previous revision : 현재 작업하고 있는 Source의 바로 이전 Revision의 Code와 수정된 Code를 diff 명령을 통해 비교한 결과를 Gedit로 표시합니다.
• Compare with base : 작업하고 있는 Source의 현재 Revision의 수정되기 전 Code와 수정된 Code를 Meld 차이 보기 Program을 통해 차이를 비교하고 수정할 수 있습니다. (수정되지 않은 경우에는 표시되지 않음)
• Compare with previous revision : 현재 작업하고 있는 Source의 바로 이전 Revision의 Code와 수정된 Code를 Meld 차이 보기 Program을 통해 차이를 비교하고 수정할 수 있습니다.
• Show Changes : 선택한 Source를 각 Revision끼리 비교할 수 있습니다.

Gedit - View Diff against base

RabbitVCS -> Diff -> View diff against base를 Click하면 위와 같이 diff 명령으로 작업하고 있는 Source의 현재 Revision의 수정되기 전 Code와 수정된 Code를 비교한 결과를 Gedit로 표시합니다. Console에서 사용하는 diff 명령에 익숙한 분이라면 내용에 대해서 이해할 수 있을 것 입니다.

Meld - Compare with base

RabbitVCS -> Diff -> Compare with base를 Click하면 위와 같이 Meld 차이 보기 Program을 통해서 작업하고 있는 Source의 현재 Revision의 수정되기 전 Code와 수정된 Code를 비교한 결과를 Visual하게 보여줍니다.

왼쪽에는 수정되기 전 Source를, 오른쪽은 수정된 Source를 나타내며 화살표는 어느 방향으로 변경된 부분을 적용할 지를 선택하는 기능을 합니다. Eclipse나 Winmerge, Windiff를 사용해 봤다면 사용법이 유사하기 때문에 쉽게 사용할 수 있을 것입니다.

9. Add

Import 시에 Project 저장소에 추가된 File 외에 새로운 File을 추가하려면 어떻게 해야 할까요? Add 기능을 사용하면 새로운 File을 Subversion으로 관리할 수 있도록 저장소에 추가할 수 있습니다.

다음과 같은 내용을 가진 test.c라는 file을 trunk Folder에 새로 작성해 봅시다.

RabbitVCS - Add

새로 만들어진 File은 Subversion으로 관리되는 Source Directory 안에 존재하지만, 실제 관리되고 있지는 않습니다.

이것을 저장소에 등록시켜 관리하기 위해서는 이 File이 포함된 Folder에서 Mouse 오른쪽 Button Popup을 띄운 후, RabbitVCS -> Add를 Click합니다.

Add Dialog

Add Dialog가 표시되면 저장소에서 관리되지 않는 File을 자동으로 검색해서 List로 위와 같이 보여 줍니다. 추가할 test.c를 선택한 다음, 확인을 누릅니다.

Completed add

확인을 누르면 위와 같이 추가가 완료되었다는 Dialog가 표시됩니다.

Commit a added file

추가가 완료되었지만 아직은 Project 저장소에 등록된 상태는 아니기 때문에 새 File을 Project 저장소에 Commit하는 과정이 필요합니다. Project Folder에서 Mouse 오른쪽 Popup에서 Commit을 선택하여 Commit을 수행합니다.

Commit Dialog를 보면 위와 같이 새로 추가된 File이 List에 표시되고 Commit이 완료되면 새로운 File을 추가하는 과정이 모두 완료됩니다.

10. Delete

Project를 계속 수행하다 보면 이전에는 필요했지만 필요가 없어져서 삭제해야 할 File이 존재할 것입니다. 하지만 Subversion을 통해 관리되고 있기 때문에 그냥 File System에서 삭제한다고 해서 Project 저장소에 적용이 되는 것은 아닙니다.

필요가 없어진 File을 Project 저장소에서도 삭제하기 위해서 Delete 기능을 사용합니다. Hello Project에서 trunk/hello.c를 삭제하는 경우를 통해서 Delete 기능에 대해 살펴보도록 하겠습니다.

RabbitVCS - Delete

먼저 삭제하고자 하는 File은 hello.c를 선택한 다음 Mouse 오른쪽 Button Popup에서 RabbitVCS -> Delete를 선택합니다.

Nautilus - Deleted

따로 Dialog가 표시되지 않고 바로 File이 삭제된 것을 확인할 수 있습니다.

Commit a deleted file

하지만 아직 Project 저장소에 적용이 된 것은 아니기 때문에 삭제 완료를 위해서 Commit을 수행해야 합니다. 삭제한 File이 들어있던 Folder를 선택한 다음 Mouse 오른쪽 Button Popup을 띄운 후, Commit을 Click합니다.

Commit Dialog에서는 위의 그림과 같이 아래쪽에 hello.c가 삭제된 상태인 것을 확인할 수 있습니다. 확인을 눌러 Commit이 성공적으로 수행되면 hello.c는 최종적으로 Project 저장소에서 삭제됩니다.

11. Revert

만약에 실수로 필요한 File을 Delete 기능을 통해 삭제하면 어떻게 해야 될까요? 이런 경우를 위해 Revert라는 기능이 존재합니다. Delete를 실행한 상태이지만, 아직 Commit을 하지 않아 Project 저장소에 적용이 되지 않았다면 Revert 기능을 사용해서 다시 원래대로 복구할 수 있습니다.

Delete 후, Commit을 실행했다면 Revert로 복구되지 않습니다. 삭제되기 이전 Revision의 Source를 새로 Checkout 받아 삭제된 File을 작업하고 있는 Source에 다시 Add 기능을 통해 추가하여 Commit하는 방법밖에 없습니다.

RabbitVCS - Revert

hello Project에서 실수로 trunk/test.c를 Delete 기능으로 삭제한 경우에 대해서 알아봅시다. Project Folder를 선택한 후, Mouse 오른쪽 Button Popup을 띄운 다음 RabbitVCS -> Revert를 Click합니다.

Revert Dialog

Revert Dialog가 표시되면서 Delete 기능으로 삭제되었지만 아직 Commit되지 않은 File의 목록을 보여줍니다. 이 중에서 복구할 File을 선택하고 확인을 누릅니다.

Completed revert

Revert가 완료되면서 삭제된 trunk/test.c가 복구되어 Folder에 존재하는 것을 확인할 수 있습니다.

12. Cleanup

Update - Locked Directory

RabbitVCS를 사용하다보면 위와 같은 Message가 표시되면서 Update나 Commit이 제대로 동작하지 않는 경우가 있습니다.

“~은/는 잠겨 있습니다” Message는 Subversion 저장소와 관련된 동작 중에 문제가 발생하여 제대로 처리되지 않은 경우에 발생합니다.

RabbitVCS - Cleanup

이 문제를 해결하기 위해서는 Cleanup이라는 기능을 사용합니다. 위와 같이 문제가 발생한 Folder를 선택한 다음, Mouse 오른쪽 Button Popup에서 RabbitVCS -> Cleanup을 Click합니다.

Completed cleanup

Cleanup Dialog가 표시되면서 문제가 해결됩니다. 물론 Cleanup으로도 해결되지 않는 경우가 있습니다. 그런 경우에는 새로 Project를 Checkout 받은 다음, 문제가 되는 Source만 작업하는 Project Folder에 복사하거나, 문제가 생긴 Folder의 숨김 Folder인 .svn을 강제로 삭제한 후 Update하는 방법을 사용하면 됩니다.

13. 마치면서…

RabbitVCS을 사용하는데 필요한 기능들을 설명하다 보니 Post가 계속 길어지네요. 다음 Post에서는 마지막으로 Branch/Tag, Merge 기능에 대해서 살펴보도록 하겠습니다.

• Ubuntu Oneiric Ocelot 11.10에서 Test 완료 (2012-01-05)

RabbitVCS는 Version Control System인 Subversion을 위한 GUI Tool로 GNOME Desktop의 탐색기인 Nautilus와 연동하여 동작합니다.

Windows에서 Windows 탐색기와 통합되어 동작하는 TortoiseSVN과 같은 Application을 사용해 본 사람이라면 쉽게 RabbitVCS를 사용할 수 있습니다.

RabbitVCS라는 이름은 아마도 거북이를 뜻하는 TortoiseSVN의 Tortoise를 빗대어 토끼와 거북이 우화를 생각해서 지었는지도 모르겠네요.

이번 Post에서는 Nautilus에서 Source Code를 Subversion으로 간편하게 관리할 수 있도록 도와주는 RabbitVCS의 설치 및 사용방법에 대해서 알아보도록 하겠습니다.

1. RabbitVCS 설치

RabitVCS를 설치해서 사용하기 이전에 Subversion Server가 구성되어 있어야 합니다. 기존에 설치된 Server가 없다면 Ubuntu Natty Narwhal 11.04에서 Subversion Server 구성하기를 참고하여 먼저 Subversion Server를 구성하기 바랍니다.

Server가 구성되었다면, 다음과 같이 Terminal에서 입력하여 RabbitVCS를 설치합니다. (Ubuntu Natty Narwhal 11.04의 경우)

Ubuntu Oneiric Ocelot 11.10에서는 설치 Package가 변경되었습니다. Terminal에서 다음과 같이 입력합니다.

설치가 된 후, Nautilus를 재시작할 필요가 있습니다. 다음과 같이 입력합니다.

2. Import

설치가 완료되었으니 지금부터 하나씩 하나씩 필요한 기능들을 예제와 함께 설명해 보도록 하겠습니다.

hello Source Tree

예를 들어, 위와 같은 Source Tree가 있다고 가정해 봅시다. 위의 그림은 Hello라는 Project Folder 안에 branches, tags, trunk Folder가 존재하고 현재 작업하고 있는 Source인 hello.c가 trunk Folder안에 존재하는 구조를 나타냅니다.

Source Code를 Subversion으로 관리하기 위해서는 먼저 Source Code를 Import(Source Code를 Subversion의 Project 저장소에 처음으로 등록)해야 합니다. 그러기 위해서는 Subversion Server내에 Project 저장소를 생성해야 하는데 생성 방법은 Server가 어떻게 구성되어 있는지에 따라 다릅니다. 이에 대한 자세한 내용은 Ubuntu Natty Narwhal 11.04에서 Subversion Server 구성하기를 참고하기 바랍니다.

RabbitVCS - Import

Subversion Server내에 Hello Project를 위한 저장소가 만들어졌다면, 이제 Source Code를 Import 해 봅시다.

Nautilus에서 위의 그림과 같이 Import할 Folder를 Mouse 오른쪽 Button으로 선택한 후, RabbitVCS -> Import를 Click합니다.

Import Dialog

Hello Project Folder를 Import하기 위한 Dialog가 표시됩니다. Repository에는 방금 전에 만든 Project 저장소의 URL을 입력합니다.

URL은 Subversion Server의 Protocol이 어떻게 되어 있느냐에 따라 다른데 보통 다음과 같이 되어 있습니다. (위의 그림의 URL은 svn+ssh:// Protocol의 예)

• svn:// Protocol :

  1	svn://<passwd에 설정한 ID>@<Server Name 또는 Address>/<생성한 Project 저장소 이름>

• svn+ssh:// Protocol :

  1	svn+ssh://<Server에 Login 가능한 ID>@<Server Name 또는 Address>/<Subversion 저장소 Directory>/<생성한 Project 저장소 이름>

Import Message에는 Import 시에 Log에 기록될 Message를 적습니다. 그리고 확인을 눌러 Import를 시작합니다.

Import - Finished

URL이 제대로 입력되었다면 Password를 묻습니다. Password를 입력하면 위와 같이 Import가 성공적으로 완료될 것입니다.

3. Checkout

Import한 hello Project는 아직 Subversion으로 관리되어 있지 않습니다. Server에 올려진 작업본을 다시 내려받아야(Checkout) Subversion으로 Project를 관리할 수 있습니다.

RabbitVCS - Checkout

새로운 Project Folder에 Subversion Server에 등록된 Hello Project를 Checkout 받아 봅시다. 위의 그림과 같이 Mouse 오른쪽 Popup에서 Checkout을 Click합니다.

Checkout Dialog

Checkout Dialog에서 위의 그림과 같이 URL에 Import 시에 입력한 URL을 입력하고 확인을 눌러 Hello Project의 최신 Source Code를 Checkout 받아봅시다.

Checkout Dialog에서는 다음과 같은 것을 설정할 수 있습니다.

• Repository :
  URL – Subversion Project 저장소의 URL입니다. Import 시에 사용했던 URL과 동일합니다. URL 입력창 옆에 돋보기 Icon을 Click하면 다음과 같이 Repository Browser가 표시되면서 실제로 접속하여 URL의 유효여부를 확인할 수 있습니다.
  

  Repository Browser

  Destination – Checkout 받은 Source가 위치할 Folder를 지정합니다. Project명과 동일하지 않아도 상관없습니다.

• Options :
  Recursive – Check할 경우 Project 저장소 URL에 포함된 모든 Source Code를 가져옵니다.
  Omit Externals – Check할 경우 Project 저장소에 연계된 외부 저장소의 Source Code를 가져오지 않습니다.
• Revision : Revision은 Project 저장소에 Source Code가 변경되는 것을 Count합니다. File마다 Revision이 적용되는 CVS와는 달리 Subversion에서는 Project 전체에 적용되며, Commit할 때 마다 증가합니다.
  HEAD – Project 저장소의 최신 Revision을 Checkout합니다.
  Number – Checkout 받기 원하는 Revision을 입력할 수 있습니다.

Checkout - Finished

설정한 암호를 제대로 입력하면 위의 그림과 같이 Checkout이 완료됩니다.

Checkout Directory

Checkout이 완료된 후, Nautilus로 Checkout된 Folder를 확인하면 위의 그림과 같이 Check Icon이 Folder 옆에 붙어 있을 것입니다. 이 Icon은 Source Code가 변경되지 않은 상태라는 것을 의미합니다. (TortoiseSVN을 사용해 본 적이 있다면 쉽게 이해할 수 있을 것 같네요.)

hello.c Properties

trunk/hello.c의 속성을 보면 위의 그림과 같이 RabbitVCS에 대한 Tab이 추가되어 표시되어 있는 것을 알 수 있습니다. Subversion으로 관리되는 Source는 위와 같이 Nautilus의 속성 Dialog에서 세부 정보를 확인할 수 있습니다.

4. Commit

Commit은 Checkout 받은 Source Code를 변경한 후에 Project 저장소에 변경사항을 저장하는 기능입니다. Commit을 통해 Project 저장소에 접근하는 다른 개발자들은 Update 기능을 통해 변경사항이 적용되게 됩니다.

Commit을 할 때는 반드시 Update를 먼저 실행해서 Commit하기 전에 Project 저장소에 등록된 변경사항이 현재 작업하고 있는 Source Code에 적용되도록 해야 합니다. 여기서는 예를 들기 위해 Commit에 대해서 먼저 설명하겠습니다.

Checkout 받은 trunk/hello.c가 위와 같은 간단한 Code로 되어 있다고 가정합시다. 그런데 굳이 return을 해 줄 필요가 있을까 싶어서 return 구문을 뺀다면 다음과 같을 것입니다.

Nautilus - modified hello.c

Source Code를 변경하고 저장했다면 위의 그림과 같이 Nautilus에서 느낌표로 표시될 것입니다. (Subversion으로 관리되는 Source Folder에서 느낌표가 표시된다는 것은 변경된 Source Code가 존재한다는 의미입니다.)

RabbitVCS - Commit

이제 변경한 내용을 Project 저장소에 등록하기 위해서 Commit을 실행해 봅시다. Source Code의 최상위 Folder인 Hello folder위에서 Mouse 오른쪽 Button으로 Popup을 띄운 후, Commit을 Click합니다.

Commit을 실행할 때는 여러 Source Code를 수정하는 것이 대부분이므로 가급적 Checkout 받은 최상위 Folder에서 Commit을 실행하는 것이 좋습니다.

Commit Dialog

Commit Dialog가 표시되면 Add Message에서 Commit하는 내용에 대한 Message를 작성합니다. 가급적이면 변경사항에 대해서 다른 개발자들도 알 수 있도록 Message를 적어두는 것이 좋습니다.

Changed Files에는 변경된 Source Code가 표시됩니다. Check를 통해서 Commit하고자 하는 File을 선택할 수도 있습니다. 확인을 눌러 Commit을 진행합니다.

Commit - Finished

Commit을 위해 암호를 입력하면 위의 그림과 같이 Commit이 완료됩니다.

5. Update

Update는 현재 작업하고 있는 Source Code에 다른 개발자가 Project 저장소에 올린 변경사항을 적용하는 기능입니다. 다른 사용자가 Commit한 내용을 Update를 통해서 적용한다고 생각하면 됩니다.

Checkout Revision 1

Update를 Test하기 위해서 Checkout을 새로 받아 봅시다. URL에는 Import시에 작성한 Hello Project 저장소의 URL을, Destination에는 이전에 Checkout 받았던 hello Folder과 구분하기 위해서 hello2를 입력합니다.

그리고 방근 전의 Commit으로 Revision이 2가 되었으므로 최초의 Source Code를 얻기 위해서 Revision에 Number를 선택하고 1을 입력하고 확인을 누릅니다.

Revision Number를 잘 모르겠다면 Revision Number 입력창 옆에 돋보기를 누르면 아래와 같이 Log Dialog에서 Revision Table에서 원하는 Revision을 선택할 수 있습니다.

Log Dialog

hello.c Revision 1

hello2/trunk/hello.c를 열어보면 맨 처음 Version(return을 없애지 않은 Code)의 hello.c의 내용인 것을 확인할 수 있습니다.

RabbitVCS - Update

hello2를 최신 Revision인 Revision 2로 Update 해 봅시다. hello2 Folder에서 Mouse 오른쪽 Popup을 연 뒤, Update를 Click합니다.

Update - Finished

암호를 입력하면 위의 그림과 같이 Update가 완료됩니다.

hello.c Revision 2

Commit된 내용이 Source Code에 적용되었는 지 확인하기 위해서 hello2/trunk/hello.c를 확인하면 return 구문이 빠져있는 것을 확인할 수 있습니다.

6. Resolve

가끔씩 Source Code를 편집하다가 Update를 하게 되면 Source code 내용이 뒤엉켜(Conflicted) 문제가 발생하는 경우가 있습니다. 이번에는 이 경우를 어떻게 처리하는지에 대해서 알아보도록 하겠습니다.

Checkout Revision 1

Test를 위해서 먼저 위의 그림과 같이 Revision 1을 hello3 Folder에 Checkout 받습니다.

Checkout 받은 hello3/trunk/hello.c의 내용은 위와 같을 것입니다. 여기서 Revision 2로 Commit된 내용을 모르는 다른 개발자가 Return 구문이 필요하지 않다고 똑같이 생각해서 Revision 2로 Update하기 전에 다음과 같이 고쳤다고 생각해 봅시다.

내용은 Revision 2와 같은 내용이지만 마지막 Return구문이 추가된 부분이 다르다는 것을 알 수 있습니다.

Update - Finished (Conflicted)

이제 이 hello3를 Update해 봅시다. Update를 할 경우 위와 같이 아무 문제가 없는 듯이 Update가 되네요. (TortoiseSVN의 경우 Conflicted가 발생하면 경고해주는 것에 비해서 불편한 부분입니다.)

Conflicted after update

하지만, Nautilus로 확인해 보면 위의 그림과 같이 hello.c에 Conflicted가 발생했다는 Icon이 표시됩니다. 그리고 못 보던 File인 hello.c.mine, hello.c.r1, hello.c.r2가 생겼습니다. 각 File은 다음과 같은 내용을 담고 있습니다.

• hello.c.mine : .mine이 확장자로 붙는 File은 Conflicted가 일어난 File이 Update 하기 전의 내용입니다.
• hello.c.r1 : 현재 작업하는 Source의 Revision에서 해당 File의 내용입니다.
• hello.c.r2 : Project 저장소의 최신 Revision에서 해당 File의 내용입니다.

Conflicted hello.c

Conlicted가 발생한 hello.c를 편집기로 열어보면 위와 같이 내용이 변경되어 있을 것입니다.

<<<<<<에서 =======까지는 Update 받기 전의 Source에서 충돌이 발생한 변경된 부분을 의미하고, =======에서 >>>>>>>까지는 Project 저장소의 최신 Revision에서 해당 부분의 내용을 나타냅니다.

이제 Conflicted를 해결하려면 어떻게 하면 될까요? 먼저 hello.c의 충돌이 발생한 부분을 보고 개발자가 판단하여 Code를 먼저 수정해야 합니다. 위의 같은 상황에서 그냥 Return 구문을 쓰는 것이 좋겠다고 판단하여 다음과 같이 고쳤다고 가정해 보겠습니다.

RabbitVCS - Resolve

Source Code 내용을 고쳤다면 그 다음에는 Conflicted 상태를 해제해야 합니다. 이것을 위해서 Resolve라는 기능을 사용합니다. Conflicted가 발생한 hello.c에서 Mouse 오른쪽 Popup을 띄운 후, RabbitVCS -> Resolve를 Click합니다.

Resolve Dialog

Resolve Dialog에서는 Conflicted 상태인 File을 표시해줍니다. 여기서 Conflicted 상태를 해제할 hello.c를 선택한 다음, 확인을 누릅니다.

Resolve - Finished

위와 같이 Resolve로 Conflicted 상태가 해제됩니다. Resolve 기능은 Subversion으로 Project를 관리하는 System 내에서의 문제를 해결해 주는 것이지 실제 Source Code의 문제는 해결해주지 못한다는 것을 유의하기 바랍니다.

(예를 들어 위에서 Conflicted 상태인 hello.c에 >>>>>>와 =======가 포함된 상태이더라도 Resolve를 실행하면 Conflicted가 아닌 상태로 만들 수 있습니다. 만약 그 File을 그대로 Commit한다면 다른 개발자들이 Update 받을 경우 피해를 입겠지요. )

Nautilus - Resolved hello.c

Resolve가 완료되면 Nautilus에서도 Conflicted 표시대신 수정되었다는 느낌표가 표시됩니다. 그리고 .mine, .r1, .r2는 자동으로 제거된 것을 알 수 있습니다.

Commit Dialog

이제 변경된 Source를 Commit 해 봅시다. Commit을 실행하고 Message를 적은 다음 확인을 눌러 Commit을 완료하면 Resolve를 통해서 Conflicted를 해결하는 과정이 끝나게 됩니다.

7. 마치면서…

지금까지 RabbitVCS를 설치하는 방법과 Subversion으로 Source Code를 관리하기 위한 기본적인 기능에 대해서 알아보았습니다. 다음 Post에서는 나머지 기능인 Add, Delete, Cleanup 등에 대해서 알아보도록 하겠습니다.

Ubuntu 11.10 Oneiric Ocelot에서 Test 완료 (2011-12-05)

Subversion은 CVS를 대체하기 위해 만들어진 형상관리 Tool(Version Control System)로 지금은 Apache Foundation에서 Project를 관리하고 있습니다.

간단하게 말하면, Subversion은 다수의 Programmer가 하나의 Project를 개발할 때 서로가 개발하는 부분에 대한 충돌이 없도록 Source를 관리하고 공유할 수 있게 도와주는 Software입니다.

물론 개인이 혼자 개발한다 하더라도, 현재 Source를 이전 Version으로 변경하고 싶을 때나 Backup을 위해서도 유용하게 사용됩니다.

이번 Post에서는 Ubuntu Natty Narwhal 11.04에서 Subversion Server를 구성하는 방법과 간단한 사용방법을 알아보도록 하겠습니다.

1. Subversion 설치

Ubuntu에서 Subversion을 설치하는 방법은 간단합니다. 아래와 같이 Terminal에서 입력합니다.

Subversion Server를 구성하기 위해서는 Subversion을 사용할 계정을 위한 Group을 생성하고, Group의 Default 계정을 설정해야 합니다. 다음과 같이 Terminal에서 입력합니다.

www-data는 기본적으로 System에 생성되어 있는 Login을 할 수 없는 User로 원래 Apache HTTP Server와 같은 Web Service를 위해 사용되는 계정입니다. 이 계정을 Default로 사용해서 Subversion 저장소를 생성하게 됩니다.

이제 Subversion 저장소(각 Project의 저장소가 저장될 최상위 Directory)를 아래와 같이 입력하여 생성합니다.

Subversion 저장소의 위치는 취향에 따라 다른 곳에 설정해도 됩니다. 보통 /srv/svn, /usr/local/svn 등을 사용하는데 /home/svn을 대부분 많이 사용하는 것 같습니다.

이제 저장소의 위치도 지정했다면 Subversion을 사용해 봅시다. Subversion 저장소에 접근하는 Protocol에 따라 설정방법이 조금씩 차이가 있는데, 여기에서는 여러 Protocol 중 Subversion 고유 Protocol인 svn://와 SSH Tunneling을 이용하는 svn+ssh://일 경우에 대해서 알아보겠습니다.

2. svn:// Protocol을 사용할 경우

svn:// Protocol은 Subversion의 고유 Protocol로 이것을 사용하면 각 Project의 저장소에 Login하기 위해서 System의 계정이 아닌 따로 설정한 ID와 Password를 사용할 수 있습니다. 저장소에 접근하기 위해서 System 계정을 만들어 주지 않아도 되기 때문에 보안상 유리할 수 있습니다.

그리고 각 Project 저장소마다 따로 ID와 Password를 설정할 수 있기 때문에 각기 다른 사용자가 Subversion Server에 접근한다면 해당 사용자에게 원하는 Project 저장소에만 접근하도록 설정할 수 있습니다.

다만 svn:// Protocol을 사용하기 위해서는 Subversion의 Service Daemon인 svnserve가 항상 실행되어 있어야만 합니다.

2.1 Init Script 생성

앞서 언급한 대로 Subversion의 Service Daemon을 실행하기 위해서 Init Script를 만들어야 합니다. Init Script를 만들게 되면 나중에 Service를 실행하기 편리하며 System 시작 시에 자동으로 실행되도록 만들 수 있습니다.

Init Script를 따로 제공하지는 않으나 다른 Ubuntu User가 만들어 놓은 Script를 활용해서 설정해 봅시다. 아래와 같이 Terminal에서 입력합니다.

Download한 Script는 Subversion 저장소가 다르게 되어 있으니 현재 설정에 맞춰 봅시다. 아래와 같이 되어 있는 것을,

다음과 같이 바꾼 후 저장하면 됩니다.

이제 Subversion Server를 실행해 봅시다. 아래와 같이 입력합니다.

작성한 Subversion Init Script를 시작 시에 자동으로 실행하려면 다음과 같이 입력합니다.

2.2 방화벽 설정

System에 UFW 방화벽이 동작하고 있다면 방화벽 설정을 해 주어야 외부에서 Server로 접속할 수가 있습니다. 방화벽을 사용하지 않는다면 이 부분은 넘겨도 됩니다.

Gufw를 사용하여 UFW 방화벽을 설정해 봅시다. 설치되어 있지 않다면 다음과 같이 입력합니다.

Gufw in Dash

Dash에서 시스템을 선택하고 방화벽 설정을 Click합니다.

Gufw

Gufw가 실행되면 새로운 Rule을 추가하기 위해서 추가 Button을 누릅니다.

Gufw - Add Rule (Subversion)

간단하게 Tab에서 Allow, In, Both를 선택하고 Subversion의 Service Port인 3690을 입력한 후, 추가를 누르면 외부에서 Server로 svn://을 사용해서 접근할 수 있게 됩니다.

2.3 Project 저장소 생성

이제 Project Source를 Import (저장소에 Source Code를 등록)하기 위해서 Project 저장소를 생성해 봅시다.

예를 들어, hello라는 Project에 대한 저장소를 만들기 원한다면 아래와 같이 Terminal에서 입력합니다.

위의 명령을 통해서 hello Project에 대한 저장소를 생성하고 적당한 권한을 부여했습니다. 그 다음, 저장소에 접근할 수 있는 ID와 Password를 설정하기 위해서 저장소의 설정을 변경해야 합니다. 아래와 같이 입력하여 수정합시다.

svnserve.conf의 중간쯤에 아래와 같이 되어 있는 부분을,

#을 제거하여 다음과 같이 변경하고 저장합니다.

마지막으로 ID와 Password를 설정할 차례입니다. 아래와 같이 입력하여 설정합시다. (ID가 foo이고 Password가 bar인 경우의 예)

2.4 Import

Project 저장소를 생성했으니 Source Code를 Import해 봅시다.

예를 들기 위해서 hello라는 Project를 만들어 봅시다. Subversion Project 저장소에 Import하기 위한 Directory 구조인 branches, tags, trunk를 생성하고 trunk에 hello.c를 간단하게 작성합시다. 아래와 같이 입력합니다.

Source가 완성되었으니 Import를 해봅시다. import를 하기 위해서는 다음과 같이 입력해야 합니다.

hello Project를 이전에 생성한 hello Project 저장소로 Import하는 경우를 예로 들면 다음과 같습니다.

위와 같이 입력하면 vi가 표시되면서 Import에 대한 Log Message를 입력할 수 있습니다. Log Message를 적고 저장한 후 vi를 종료하면 ID에 대한 암호를 묻고, 제대로 입력했다면 저장소에 Source Code가 Import 됩니다.

2.5 Checkout

제대로 Project 저장소에 Import가 되었는지 확인하기 위해서 Checkout(저장소에 존재하는 최신의 Source를 Download)을 받아봅시다.

Checkout을 위한 명령어 구문은 다음과 같습니다.

위에서 예를 든 hello Project를 Checkout 받는 경우라면 다음과 같이 입력해야 합니다.

제대로 Checkout 받았다면 hello Directory가 생기면서 그 안에 branches, tags, trunk Directory와 trunk/hello.c가 존재할 것입니다.

3. svn+ssh:// Protocol을 사용할 경우

svn+ssh:// Protocol은 Subversion Service Daemon을 실행하지 않고도 SSH protocol을 사용하여 Tunneling을 통해 Subversion Project 저장소에 접근할 수 있습니다.

보통의 경우 SSH Server를 구성하여 System을 관리하는 경우가 많기 때문에 특별한 설정없이 간단하게 Subversion Server를 구성할 수 있습니다. 또한 SSH의 Tunneling을 사용하기 때문에 암호화되어 Data가 전송되므로 안전합니다.

다만 각 Project 저장소마다 ID와 Password를 따로 만들어 줄 수 있는 svn:// Protocol과는 달리 System에 생성된 계정으로 접근하기 때문에 계정만 있다면 모든 Project 저장소에 접근할 수 있는 단점이 존재합니다. (굳이 구분하려 한다면 Project 저장소 Directory에 권한 설정으로 가능할 것 같네요.)

3.1 OpenSSH Server 설치

svn+ssh:// Protocol을 사용하기 위해서 OpenSSH Server를 설치합시다. 설치방법은 간단합니다. 다음과 같이 Terminal에서 입력합니다.

설치된 SSH Server가 System 시작 시에 자동으로 실행되게 하려면 다음과 같이 입력합니다.

3.2 방화벽 설정

UFW 방화벽이 활성화 되어 있다면 SSH Server를 위해서 방화벽 설정을 해 주어야 합니다. 방화벽을 사용하지 않을 경우에는 이 부분을 건너뛰어도 좋습니다.

Gufw를 사용하여 UFW 방화벽을 설정해 봅시다. 설치되어 있지 않다면 다음과 같이 입력합니다.

Gufw in Dash

Dash에서 시스템을 선택하고 방화벽 설정을 누릅니다.

Gufw

Gufw를 실행되면, Unlock을 눌러 Superuser 권한을 얻은 후, 추가 Button을 누릅니다.

Gufw - Add Rule (SSH)

편리하게 Tab에서 Allow, In, Service, SSH를 선택하고 추가 Button을 누르면 외부에서도 Server의 SSH Service에 접근할 수 있게 됩니다.

3.3 Project 저장소 생성

이제 Project 저장소를 생성해 봅시다. 위에서 만든 hello Project를 위한 저장소를 만들기 위해서는 다음과 같이 입력하면 됩니다.

Project 저장소를 만든 다음에 접근할 수 있는 계정을 생성해야 합니다. 예를 들어 foo라는 계정을 Subversion Project 저장소에 접근할 수 있도록 하려면 다음과 같이 입력합니다.

또는 기존에 System에 존재하는 계정을 Subversion Project 저장소에 접근하게 하려면 아래와 같이 입력하면 됩니다.

3.4 Import

svn+ssh:// Protocol을 사용하기 위한 준비가 끝났습니다. 이제 Project Source를 Import해 봅시다. import 시에 명령 구문은 아래와 같습니다.

svn:// Protocol을 사용할 때와 다른 점은 Server Name과 Project 저장소 이름 사이에 Subversion 저장소의 System 경로를 적어야 한다는 것입니다.

예를 들어 위에 설정한 것 처럼 Subversion 저장소가 /home/svn이고, 생성한 Project 저장소 이름이 hello인 경우 다음과 같이 Terminal에서 입력해야 합니다.

위의 명령을 입력하면 처음으로 SSH Server에 접속할 경우 계속 접속할 것인지 여부를 묻는데 yes라고 입력한 후 접속할 계정의 비밀번호를 입력합니다. 이후 나머지 과정은 svn:// Protocol을 사용하여 Import할 때와 동일합니다.

3.5 Checkout

이번에는 Import한 Project Source를 Checkout 해 봅시다. 명령구문은 다음과 같습니다.

Import의 경우와 마찬가지로 여기서도 Server Name과 Project 저장소 이름 사이에 Subversion 저장소 Directory 경로가 포함되어야 합니다. 위에서 예로 Import한 hello Project를 Checkout하려면 아래와 같이 입력합니다.

4. 마치면서…

이상으로 Ubuntu Natty Narwhal 11.04에서 Subversion Server를 구성하는 방법을 알아봤습니다. 마지막으로 Subversion에 대한 자세한 정보를 얻기 원한다면 다음 Link를 방문해 보기 바랍니다.

• Apache Subversion Project : http://subversion.apache.org
• Version Control with Subversion (Free E-Book) : http://svnbook.red-bean.com
• Version Control with Subversion 한국어 번역 : http://wiki.kldp.org/wiki.php/SubversionBook

1. Team Synchronizing Perspective

Team Synchronizing Perspective는 Eclipse IDE를 변경시켜 Subclipse에서 제공하는 CVS, SVN 등의 소스관리 툴과 연동을 위한 동작을 처리하기 위한 작업환경입니다.

Perspective 를 변경하기 위해서는 Package Explorer에서 해당 Project위에서 Mouse 오른쪽 button으로 Popup을 띄운 후, Team->Synchronize with Repository를 클릭합니다.

처음으로 Team Synchronizing Perspective를 실행한 경우 아래와 같은 Message가 표시됩니다. Yes를 클릭합니다.

Team Synchronizing Perspective를 IDE에 설정한 화면입니다. 왼쪽에 Source관리를 위한 Synchronize View와 Task Repositories View가 표시됩니다. Synchronize View에서는 SVN의 각 동작을 처리할 수 있고, Task Repositories에서는 Local 저장소를등록하고 관리할 수 있습니다.

2. Update

Project를 저장소로 부터 Update 받기 위해서는, Package Explorer에서 Update 받을 Project의 Folder위에서 Popup을 띄운 후, Team->Update to HEAD 또는 Update to version을 클릭하면 됩니다.

여기서 Update to HEAD는 저장소에서 현재 최신의 Source를 Update하며, Update to version은 저장소에서 해당 Revision의 Source를 가지고 현재 Source를 Update합니다.

3. Commit

Project를 개발하다가 저장소에 변경된 내용을 저장하기 위해서는 Commit을 해야 합니다. Commit하기 전에는 먼저 저장소에 변경된 내용이 없는 지 확인하기 위해서 먼저 Update를 수행하는 것 좋습니다. 변경된 Source file은 Package Explorer에서 해당 Source의 Icon이 변경되어 있는 것으로 확인할 수 있습니다.

Commit을 하기 위해서는 Package Explorer에서 Commit할 Source가 존재하는 Project의 Folder위에서 Popup을 띄운 후, Team->Commit을 클릭합니다.

클릭하면 위와 같은 Commit Dialog가 화면에 표시됩니다. 위에 Textarea에는 변경사항을 텍스트로 적을 수 있고 아래의 Tree에는 변경된 Source의 목록이 표시됩니다. 여기서 Check된 항목만 Commit되기 때문에 Commit시에 필요한 파일만 Commit할 수도 있습니다. OK를 누르게 되면 Commit이 완료됩니다.

4. History

저장소의 History를 확인할 수 있습니다. 누가 어떤 Source의 무슨 내용을 변경했는지에 대한 정보를 확인할 수 있습니다. 누가 저장소에 Source를 잘못 올려놓아서 Update를 했는데 Compile이 되지 않거나 문제가 생긴다면 추적하는데 사용할 수 있습니다.ㅋㅋ

Package Explorer에서 Project Folder위에서 Popup을 띄운 후, Team->Show History를 클릭하면 아래와 같이 History View가 아래에 표시됩니다.

5. Revert

현재 변경된 Source의 수정된 내용을 무시하고 저장소에 저장된 이전 Source로 돌리고 싶을 때 사용합니다. Package Explorer에서 변경된 Source위에서 Popup을 띄우고 Team->Revert를 클릭하면 아래와 같이 Revert Dialog가 뜹니다.

되돌릴 Source에 체크한 후 OK를 누르면 저장소의 최신버전으로 선택한 Source를 변경합니다.

6. Branch/Tag 생성하기

쉽게 이야기 하면 Branch는 현재 Project에서 다른 가지로 나와서 새로운 기능을 시도하는 등의 변종 Project를 의미하고, Tag는 현재 Project를 Release하는 시점의 Source를 보관하고 Version tag를 붙인 Source를 의미합니다. Branch와 Tag를 생성하기 위해서는, Branch와 Tag를 할 Folder의 상위 Folder를 선택한 후, Mouse 오른쪽 Popup에서 Team->Branch/Tag를 클릭합니다.

Branch/Tag Dialog에서 Copy to URL에는 해당 Branch 또는 Tag가 저장될 저장소의 주소를 입력하고 Next를 클릭합니다.

저장소의 어떤 Revision을 Branch 또는 Tag로 등록할지에 대해서 선택합니다. 위의 그림에서는 최신 Revision에 대하여 Branch/Tag를 등록하는 설정입니다. Next를 클릭합니다.

마 지막으로 Comment를 작성하고 Finish를 클릭하면 저장소의 해당 위치에 Branch/Tag가 등록됩니다. 등록이 최종 완료되면 위와 같은 그림처럼 Package Explorer에서 해당 위치에 등록 된 것을 확인할 수 있습니다.

7. 마치면서

이상으로 Eclipse 3.5 Galileo에 설치된 Subclipse 1.6의 각 기능들을 간단하게 살펴보았습니다. Subclipse로 Eclipse에서 작업하는 모든 Project의 Source를 효율적으로 관리하시길 바랍니다.

– God Bless..