Merge Tool(머지툴) 비교 - (3way merge 기능) - 수정

소프트웨어를 개발하다 보면 소스코드의 브랜치가 일어나고 이를 Merge(머지)하는 일은 피하기가 어렵습니다.

이 Merge(머지)과정을 자동화 툴을 이용하면 상당히 많은 시간을 절약할 수 있습니다.

특히 Merge의 자동화를 위해서는 3way-Merge가 필수적인데, 시중에서 3way머지가 지원된다고 하는 툴 4가지와 SVN에서 지원하는 Unified diff, 이렇게 총 5가지를 비교해봤습니다.

그 결과는 아래와 같이 평가를 하였습니다. KDiff3, P4Merge와 Araxis Merge가 우수하게 나왔습니다.

2way merge툴은 같은 레벨에서 비교 대상이 되지 않기 때문에 비교하지 않았습니다. 2way merge툴보다는 꼭 3way merge툴을 쓰기를 권장합니다.

3way merge툴은 실무에 있어서 2way merge툴보다 10배에서 100배까지 더 효율적입니다. 직접 이해를 하고 써보기 전까지는 짐작하기 어려울 정도입니다.

제 책(소프트웨어 개발의 모든 것)에서 3way merge에 대해서 자세히 설명하고 있으니 참조하기시 바랍니다.

총점

비교 데이터

비교 방법은 일부러 Conflict가 일어나는 상황을 만들어서 각 Merge툴이 얼마나 손쉽게 Conflict를 해결하는지 비교하였습니다.

제가 분석을 위해서 사용한 파일은 다음과 같습니다.

위에서 자동으로 Merge가 가능한 부분은 노란색으로 칠했고, Conflict가 나는 부분은 보라색으로 칠했습니다.

이렇게 Conflict를 일으켜서 SVN에서 자동 Merge를 실패하게 한 후에 각각의 Merge툴로 비교를 해 봤습니다.

실행

KDiff3와 Araxis Merge는 Conflict가 났을 때 SVN에 떨궈주는 파일 3개를 선택해서 쉽게 해당 툴을 실행할 수 있습니다. 그래서 Merge하는 시간을 절약할 수 있습니다.

KDiff3

Araxis Merge

비교 화면

비교는 Orginal File(Base)과 Trunk File(Working)과 Branch File 3개를 비교했습니다.

그 화면은 다음과 같습니다. 이미지를 클릭하면 큰 이미지를 볼 수 있습니다.

언뜻 보기에는 각각의 화면이 크게 차이가 나지 않는 것처럼 보입니다. 각 툴마다 다른 부분, Conflict가 나는 부분을 다른 방법으로 표시를 하고 있습니다. KDiff3는 한글이 깔끔하게 나오는 것이 눈에 좀 거슬리지만, 기능에는 문제가 없습니다.

비교 화면에서는 Araxis Merge가 가장 직관적이고 깔끔한 화면을 보여줍니다.

KDiff3

P4Merge

Araxis Merge

Beyond Compare

Ultra Compare

Merge시 Conflict를 알려주는 다이얼로그

KDiff3와 Araxis Merge는 의미있는 Conflict 정보를 Merge시 알려줍니다. 둘다 자동 Merge를 하면서 Conflict가 난 2건을 표시해 줍니다.

P4Merge는 가장 직관적인 화면을 보여주며 마찬가지로 Conflict 2건을 표시합니다.

KDiff3

 

P4Merge

Araxis Merge

 

Merge 화면

Merge를 실행하게 되면 KDiff3, P4Merge와 Beyond Compare는 원래 파일 3개는 그대로 두고 새로운 Merge파일 창이 새로 생깁니다. 하지만, Araxis Merge와 Ultra Compare는 기존의 파일을 수정하도록 되어 있네요.

P4Merge가 가장 직관적입니다.

KDiff3

P4Merge

Araxis Merge

 

Beyond Compare

 

Ultra Compare

 

Conflict 해결

Conflict는 각각 어떻게 해결을 할 수 이나 비교를 해 봤습니다.

KDiff3 - Merge화면에서 Conflict가 난 줄은 <Merge Conflict>라고 표시가 됩니다. 원래 비교 대상인 3개의 파일 중에서 하나를 마우스나 키보드를 이용해서 선택할 수 있습니다.

 

P4Merge - Merge창에서 Conflict가 난 부분은 붉은 표시가 되어 있습니다. 오른쪽에 있는 버튼을 클릭해서 원하는 부분은 클릭하면 쉽게 Conflict가 해결됩니다.

Araxis Merge - Conflict가 난 줄들은 줄 앞에 빨간 동그라미가 나옵니다. 해당 줄에서 >>, << 버튼을 이용해서 선택을 하면 됩니다.

 

Beyond Compare - Conflict가 일어난 줄은 붉은 바탕으로 표시가 됩니다. 이 줄에서 마우스 버튼을 이용해서 원하는 파일을 선택하면 적용이 됩니다. 테스트 시 라인 단위로 정교하게 선택이 안되고 뭉쳐서 선택이 되는 바람에 원하는대로 Merge를 하는데 시간이 좀 걸렸습니다.

 

Ultra Compare - Conflict는 표시가 안됩니다. 그냥 서로 다른 줄을 찾아서 ->, <-버튼을 이용해서 선택하면 됩니다. 자동 Merge가 안되서 수동으로 일일이 선택을 해줘야 합니다.

Unicode 지원

KDiff3 - Unicode를 지원하나 Auto detect가 잘 안되네요.

P4Merge - Unicode를 완벽하게 지원합니다.

Araxis Merge - 지원한다고 하는데, View에서 깨져 보임,  Merge는 됨 

Beyond Compare - View, Merge 모두 지원

Ultra Compare - View, Merge 모두 지원

총평

기능면에서는 약간 부족함은 있으나, 기본적인 Merge기능에 충실하고 가격이 무료인 KDiff3와 모든 기능이 우수하지만 가격이 좀 부담스러운 Araxis Merge에 높은 점수를 주었습니다.

그리고 P4Merge는 Merge 기능이 가장 직관적인고 편리합니다. 

실제로 Merge결과 원하는 결과대로 바로 Merge가 되면서 Conflict를 몇 초만에 해결할 수 있었던 것은 KDiff3, P4Merge와 Araxis Merge밖에 없었습니다.

Branch와 Merge가 빈번하고 회사에 경제적인 여유가 된다면 Araxis Merge가 적당할 것 같고, 그렇지 않은 경우라면 다른 유료 툴보다도 KDiff3와 P4Merge가 좋을 것으로 생각합니다.

Build Script를 C언어로 작성하기

Build Script를 Script언어가 아닌 C언어로 작성하시거나 그런 경험이 있으십니까?

저는 Build Script를 C언어로 작성하는 것을 본 적이 있습니다. 이 경우에 Build Script라고 하기에 좀 그렇군요. Build Program이라고 해야 할까요? 

누구나가 Build Script라고 부르는 이유는 Script언어로 작성하기 때문이기도 합니다.

물론 IDE에서 공식 빌드를 하는 것이 아니고 Build Script를 작성한 것은 긍정적으로 볼 수 있지만 Build Script를 사용하기 위해서 다시 Build를 해야 한다면 우습네요.

Build Script를 C언어와 같이 Build가 필요한 언어로 작성하는 경우는 이러한 경우가 있을 수 있습니다.

• C언어는 기가 막히게 잘 아는 Script언어는 잘 모른다.
• Build Logic이 복잡하여 Script언어로는 작성하기 어려울 것 같다.
• Build 과정에서 다른 시스템과 연동하는 등 인터페이스가 많다.

Script언어를 하나도 모른다면 어쩔 수 없겠지만, Script언어로도 빌드에 필요한 정도의 모든 기능은 쉽게 구현할 수 있습니다. 오히려 Build를 위해서 만들어진 Ant같은 경우는 더 효율적입니다. Script언어에 아직 익숙하지 않다면 간단하게 Batch 파일로 작성할 수도 있습니다. 그리고 C언어와 유사한 Python을 이용하면 Python을 아주 잘하지 않더라도 간단한 Build Script 정도는 만들어 낼 수 있습니다.

Build Script는 처음부터 모든 원하는 기능을 다 자동화 할 필요는 없습니다. 우선 기본적인 빌드 기능부터 구현을 한 다음에 사용을 해보면서 자동화가 필요한 부분을 차례차례 추가해 넣으면 무난히 효율적인 Build Script를 만들 수 있습니다.

소스코드 관리 방법 조사 결과

그동안 제 블로그에서 약 20일간 기업의 소스코드 관리 방법 투표를 진행했습니다.

현재 각 기업들의 소프트웨어 개발 환경 및 현황을 파악하고 공유하기 위해서 소프트웨어 개발에 대한 다양한 설문 조사를 시행하고 있습니다.

이번 소스코드관리 설문의 질문은 다음과 같습니다.

소스코드는 어디에 보관하세요?  (최신 소스코드의 기준이 되는 저장 장소를 선택해주세요. 다중 선택 가능)

약 3주간의 설문 결과 아래와 같은 분포가 나왔습니다.

0%	27%		54%	COUNT	PERCENT
						COUNTRY	OVERALL
Subversion					302	54.41%	54.41%
CVS					38	6.85%	6.85%
Visual SourceSafe					28	5.05%	5.05%
Team Foundation Server					16	2.88%	2.88%
IBM Rational ClearCase					16	2.88%	2.88%
RCS					2	0.36%	0.36%
Git					38	6.85%	6.85%
Mercurial					13	2.34%	2.34%
SVK					0	0%	0%
Bazaar					1	0.18%	0.18%
BitKeeper					0	0%	0%
FileServer에 보관					14	2.52%	2.52%
개인 PC에 보관					41	7.39%	7.39%
공용개발서버에 보관					26	4.68%	4.68%
실운영서버에 보관					6	1.08%	1.08%
Other:

일단, 예산대로 소스코드관리시스템중에서는 Subversion이 압도적인 1위를 차지했습니다.

그리고 CVS가 2위, VSS가 3위입니다.

하지만 소스코드관리시스템을 사용하지 않고, 일반 서버나 개인PC에 보관한다는 응답도 꽤(25%) 많았습니다.

아래 수치는 내가 컨설팅을 하면서 보아온 비율과 크게 다르지 않습니다. 하지만, 소스코드관리시스템을 사용하는 방법에 있어서는 많은 차이들이 있기 때문에 소스코드관리시스템을 얼마나 잘 활용하고 있는지에 대해서는 또다시 조사를 하는 것도 의미가 있다고 생각합니다.

그중에서도 특히 개인 PC에 많이 소스코드를 보관하고 있는 것으로 조사가 되었습니다. 다음은 소스코드관리시스템이 아닌 장소에 소스코드를 보관하는 방법중에서의 비율입니다.

위와 같이 소스코드관리시스템을 사용하지 않고 개발을 하는 방법은 대단히 불편하며, 쓸데 없는데 시간과 노력을 빼앗기는 정말 비효율적인 방법이 아닐 수 없습니다. 설령 소스코드관리시스템을 사용하고 있다고 하더라도, 소스코드의 기준이 개인 PC나 서버에 보관된 소스코드라면 소스코드관리시스템을 사용하고 있는 것과 크게 다르지 않습니다.

소스코드관리시스템을 사용하지 않으면 당장 겪는 어려움은 다음과 같습니다.

• 최신 소스코드를 쉽게 파악하기 어렵고 이게 정말 최신 소스인지 확인이 어렵다.
• 소스코드 공유가 불편하다.
• 소스코드를 동시에 수정하는 등의 협업이 불편하다.
• 소스코드를 안정적으로 백업 받을 수가 없다.
• 소스코드의 변경에 대한 히스토리를 파악하기 어렵다.
• 소스코드에 베이스라인 설정이 불편하다.
• 소스코드의 변경과 버그의 연관성을 파악하기 어렵다.

이정도는 아주 기본적인 불편함에 속합니다. 좀더 나아가면 엄청나게 복잡해집니다. 왠만한 규모의 회사도 소스코드의 관리는 꽤 복잡하며 이률 효율적으로 관리하지 않으면 생산성을 높이기가 어렵습니다. 다음과 같은 일들이 벌어지는 상황에서는 더욱더 소스코드관리시스템이 필요합니다.

• 동일 제품이 신규 개발과 유지보수가 동시에 진행되고 있다.
• 여러 개발팀이 동일한 소스코드를 동시에 수정한다.
• 서로 릴리즈 시기가 다른 기능들을 동시에 서로 다른 팀에서 구현하고 있다.
• 특정 회사의 긴급한 요구에 의해서 소스코드 브랜치가 일어났고, 곧 머지(Merge)할 계획이다.
• 미국과 중국에 있는 개발자와 동시에 개발을 진행하고 있다.

소스코드관리시스템없이 소프트웨어 개발을 하고 있다면 이는 한마디로 "기적"이며 정말로 쓸데없는 낭비를 하고 있는 겁니다. 소스코드관리시스템없이 소프트웨어를 개발한다는 것은 상상할 수도 없으며, 이미 소스코드관리시스템을 사용하고 있는 화사는 과거로 돌아가서 소스코드관리시스템 없이 개발하라고 하면 그런 상황은 상상하기도 싫을 겁니다.

소스코드관리시스템은 일단 설치해서 사용하는 것은 쉽게 할 수 있지만, 제대로 사용해서 생산성을 극대화하는 것은 상당히 어렵습니다. 앞으로 이에 대한 설문도 진행해 볼 계획이고, 블로그 글도 작성을 해보려고 합니다.