[펌] Eclipse에서 SVN 충돌시 해결 방법

------------------------------------------------------------------------------------------------

                                              출처: http://blog.naver.com/seogi1004/110095966260

------------------------------------------------------------------------------------------------

 

1. Override and Update

 

-  자동 병합과 비 자동 병합의 경우에 사용하는 메뉴로써 다이얼로그창에 자동으로 병할할지 아니면

    덮어쓰기 할지의 여부를 묻는다. 자동으로 병합을 선택하면 소스가 자동으로 병합되어 로컬 소스가

    변경되고, 덮어쓰기를 선택하면 로컬 소스가 모두 서버의 소스로 대체된다. 덮어쓰기를 할 경우

    주의한다.

 

- 다른 작업자가 checkout 한 뒤에 소스를 변경한 후 commit 하였다면 이 변경된 소스를 업데이트

   해주어야 한다.

 

이클립스에서는 업데이트 하는 방법이 두가지 있다.

Team > Update 와 Syncronize 뷰를 이용하는것이다.

이 두가지의 차이점은 CVS에서 소스를 다른 방식으로 가져오는것이다.

CVS에서 소스를 가져오는 방식은 다음과 같은 상황에 따라 달라지진다.

1. 소스 충돌이 없을 때 : 로컬에 있는 소스가 변경되지 않은 상황으로 파일이 자동으로 CVS 서버의

                                  내용으로 변경된다.

 

2. 자동 병합(merge)이 발생할 때 : 동시에 같은 리버전(revision)의 ASCII 파일을 commit 하려 할 때

                                                서로 변경내용이 다른 줄의 것을 고친경우 자동으로 병합된다.

3. 비 병합 충돌이 발생할 때 : 자동 병합과 같이 동시에 같은 리버전의 ASCII파일을 commit 하려 할 때

                                        같은 줄의 내용을 고친 경우 자동으로 병합되지 않고 충돌이 일어난다.

                                        바이너리(Binary) 파일 이라면 이 경우 항상 충돌로 간주된다.

이클립스에서 Team > Update 메뉴를 선택하면 이 세가지 충돌이 모두 발생가능하다는걸 유념해 두자.

위의 1,2번의 경우 추가적인 처리 없이 바로 Update작업이 완료된다.

3번의 경우 ASCII파일의 경우 로컬 리소스가 CVS마크업 텍스트를 사용하여 병합되고,

바이너리 파일의 경우 로컬 리소스가 .#파일로 변경되면서 서버로 부터 파일을 다운로드 한다.

이와 같은 경우 로컬 리소스를 update 하기 전에 어떤 부분이 변경되었는지 알고 있어야 충돌에 대비할 수 있다.

 
이클립스에서 update하는 다른 한방법인 Synchronize뷰 에서는 다음 순서대로 수행하면 된다.

1. Navigator혹은 Package뷰 에서 Update하고자 하는 소스 선택

2. 오른족 버튼 > Team > Synchronize with Repository 선택, Synchronize뷰 가 열린다.

3. Update할 소스 파악하기 위해 Synchronize View > Tool Bar > Incomming Model 선택

    이 때 Update에 두가지 방법이 있는데 소스를 선택한 후 오른쪽 버튼 Team > Update from Repository

    혹은 Override and Update가 있다.

1. Update from Repository : 비 충돌 상황의 소스인 경우 update가 수행된다.

                                       즉, 자동병합 소스와 비 병합 충돌 소스의 경우는 update되지 않고

                                       남아있게 된다.

2. Override and Update : 이 메뉴는 자동 병합 혹은 비병합의 경우에 사용하는 메뉴로 다이얼로그 창에

                                   자동으로 병합할지 아니면 덮어쓰기할지의 여부를 선택하는 것이다.

                                   자동병합을 선택하면 소스가 자동으로 병합되어 로컬소스가 변경되고 (Update),

                                   덮어쓰기를 선택하면 로컬 소스가 모두 서버의 소스로 대체된다.

                                   그러므로 덮어쓰기를 할 경우 주의하여야 한다.

 

이제 이클립스로 소스 commit을 해보자

이것 역시 소스 선택후 오른쪽 버튼을 클릭후 Team > Commit 메뉴 혹은 Synchronize뷰에서 할 수 있다.

소스 선택후 오른쪽 버튼 클릭 Team > Commit 메뉴 선택인 경우 예를 들겠다. 

 

아래의 다이얼 로그는 commit할때 코멘트를 입력하는 다이얼 로그다.

 

여기선 충돌이 일어나면 commit이 실패하게 된다.

이 때는 update나 Synchronize뷰에서 충돌된 상황을 위에서 처럼 해결해 주어야 한다.

이러한 상황을 피하려면 소스를 commit 하기 전에 미리 update를 받아서 최신의 소스를 로컬에

받아둔 다음에 commit 절차로 작업을 수행하는 것이 바람직하다.

만약 commit 하려던 소스가 CVS저장소에 존재하지 않는다면, commit 하기전에 Add할지를 묻는

다이얼로그 창이 나오고 add를 먼저 수행해 주면 된다.

 

 

 

2. Mark as Merged

 

- Synchronize 뷰에서 해당소스를 선택하고 팝업 메뉴에서 Mark as Merged를 선택한다. 
   이 방법은 로컬의 소스를 병합된 소스로 만들고 충돌을 없애준다. 주의 할 것은 서버 소스와 비교를

   통해서 로컬 소스를 서버에 반영할지를 확인한 후 이 방법을 취하도록 한다. 

 

 

서버 소스를 로컬 소스로 대체하는 방법이다.

 

- mark as merged 본인 로컬 소스 버전을 최신으로 올립니다.
   즉 ~ 서버에 소스가 잘못되어있거나 내가 로컬로 받을 필요 없고 로컬 소스를 엎어쳐야 할 때

   사용합니다. 무작정 mark as merged 사용하셨다면 다른 분들 소스가 반영 안된다고 소리치면서

   누가 엎어쳤는지 범인 수색합니다.

- 수작업으로 서버쪽 소스와 내소스와 충돌나지 않게 라인별로 잘 병합한 다음에 최종적으로

   mark as merged로 커밋 가능하게 해놓은 뒤 올려야됩니다. 무작정 올리면 범인 수색 들어갑니다.
   서버쪽 소스가 어떻든 내 것을 막무가내로 올리겠단 뜻입니다.

아! 물론 내 소스와 서버 소스 일치화 시키고, mark as merged 를 해야하는건 알죠.^^;
문득 궁금했던건 일치화 안시키고 mark as merged 를 수행하게 되면 서버와 로컬의 정보가 다른데도
무조건 로컬의 파일이 commite이 되는건가요??

 

소스를 일치화 안시키고 mark as merged 를 수행하면 레파지토리 소스가 변경되지는 않으나 로컬과

레파티조리 소스의 충돌난 부분(다른 코드로 인해)를 같은 코드로 인식하게 되네요.

 

 

 

3. Mark Resoleved

 

같은 기능을 동시에 다른 작업자가 구현하였기 때문에 둘 중 하나는 나중에 필요없어질 수도 있다.

만약 늦게 commit 하는 사람이 고참 작업자일 경우 앞사람이 작성해 놓은 부분을 깡그리 지워버리고

충돌 해결을 눌러도 될 것이다. 하지만 먼저 작업한 사람의 내용을 함부로 지워버린다면 그 사람은 기분이 상당히 나쁠 것이므로 일단 앞 사람의 내용을 그대로 보존하고 commit 하도록 한다.

 

 

충돌이 발생한 소스파일에 우클릭 한 다음 Mark resolved를 선택한다.

이것은 임시방편의 해결책으로 근본적인 해결책은 두 개발자가 서로 소통하여 중복 구현된 부분을

제거하도록 해야 한다.

 

충돌 해결 유형을 선택한다.

 

- 첫번째 메뉴는 파일 자체를 완전히 수정하여 충돌을 해결했다는 뜻인데 이 예제에서는 앞 사람의

  작업내용을 그대로 보존하면서 내 작업내용을 올렸으므로 설명에 부합한다.

 

- 두번째 메뉴는 내 작업물을 이용해 충돌을 해결한다는 뜻인데 이것을 선택할 경우 앞 사람이 작업한 내용

   중 충돌을 일으키는 부분들은 모두 사라지게 된다. 두 개발자가 서로 Code review를 수행하고

   변경 내용에 대한 동의가 충분히 이루어진 이후라면 이 메뉴를 선택해도 무방하지만 만약 이 메뉴를

   함부로 선택하였다가 앞 사람의 작업물을 함부로 지울 경우 서로간의 화합에 상당한 악영향을 끼칠 수

   있으므로 신중하게 선택하는 것이 좋다. (내 작업물 이외의 다른 파일 무시)

 

- 세번째 메뉴는 이번에 충돌을 일으킨 파일로 충돌을 해결한다는 것으로 앞 사람의 작업물을 전적으로

   신뢰하여 내 작업물의 가치가 없다고 판단한 경우에 선택한다. (다른 사람의 작업물만을 신뢰)

 

- 네번째 메뉴는 충돌이 발생하기 이전 리비전의 파일로 충돌을 해결한다는 것으로 모든 변경사항을

  포기할 경우에 선택한다. 되도록 이 메뉴는 선택하지 않는 것이 좋다. (모든 변경사항을 포기하고

  저장소의 원본만을 신뢰)

 

 

충돌을 해결하고 나면 참고용으로 생성된 이상한 파일들이 모두 삭제된다.

 

충돌 해결 내역을 상세히 기록한 다음 다시 Commit 을 시도한다.

 

Commit 을 성공했다.