Code sharing using svn:externals property

서브버전으로 각종 프로젝트를 진행하다보면 여러가지의 오픈소스들을 활용해야 할 때가 있는데 그럴때 외부 저장소에 있는 오픈소스 프로젝트를 현재 작업하고 있는 저장소에 포함시키면 상당히 효율적으로 외부라이브러리를 관리할 수 있다.

다시말해 진행하려는 프로젝트 저장소를 생성하고 그 저장소에 Papervision 이라든지 Away3D 와 같은 외부 저장소의 소스를 연결할 수 있다는 의미이다. 이렇게 되면 현재 저장소에 외부 오픈소스가 귀속되어 실제 버전관리가 이루어지지 않는 맹점을 해결할 수 있다.

서브버전 디렉토리 속성중에 svn:externals 이라는 것이 있는데 이것을 이용하면 현재 저장소에 다른 저장소의 내용을 포함시킬 수가 있다.
svn_repository
위와 같이 외부저장소에서 가져온 라이브러리는 독립적인 버전관리가 이루어지며 한 저장소 안에서 여러개의 서로다른 저장소의 라이브러리를 가져와 연결할 수 있다.

아래 설명은 eclipse 기반의 서브버전 플러그인인 Subclipse 를 작업기준으로 한다.
우선 SVN 프로젝트를 생성하고 속성을 설정하고자 하는 폴더에서 마우스 우클릭을 하여
아래와 같이 Team –> Set Property… 메뉴를 클릭한다.

svn_property1

그러면 다음과 같은 svn 속성 설정창이 뜨는데  Property name 으로 svn:externals 을 선택하고  Property content (value)값을 다음과 같은 정의로 입력해준다.

svn:externals [저장할 디렉토리](-r 리비전번호)[외부저장소의 URL]

lib/pv -r 873 http://papervision3d.googlecode.com/svn/trunk/as3/turnk/src

Property content (value) 정의는 크게 두부분으로 구성되는데 처음부분은 외부저장소 파일이 저장될 프로젝트의 디렉토리 이름이고 두번째는 외부저장소의 URL 로 이루어진다. 그리고 외부저장소에서 원하는 리비전번호의 파일을 제한적으로 연결할 수 있는데 이는 외부저장소의 뜻하지 않은 변경사항에 현재 적용하고 있는 프로젝트와의 충돌이나 오류를 막아준다. 이는 옵션사항이니 항상 최신버전을 가져오려면 생략하면 된다. 또한 여러개의 저장소를 가져올 경우 위와 같은 형식으로 각각의 다른 라인으로 작성하면 현재 프로젝트에서 여러개의 서로다른 외부저장소를 연결하여 사용할 수 있다.

입력이 끝났으면 업데이트를 실행해보자. 그러면 외부저장소의 파일들을 프로젝트내로 가져올것이다. 그리고 변경사항에 대해 커밋을 한다.
여기서 중요한 사실은, 커밋한다고 해서 현재 프로젝트에서 업데이트 되었던 외부저장소의 파일들이 저장소에 모두 커밋되는것이 아니다. 저장소를 확인해보면 알 수 있듯이 서버상에는 svn 속성값만 변경되었을 뿐 어떠한 외부저장소의 폴더가 반영된 것을 볼 수 없을 것이다.

또한, 현재 프로젝트에서 외부저장소를 포함한 모든 작업파일에 대한 변경사항을 커밋할 때 만약 외부 저장소의 파일을 직접 변경했다고 하더라도 자동으로 외부저장소의 파일을 커밋하지 않는다는 것이다. 외부저장소의 변경을 커밋하고 싶으면 해당 외부디렉토리로 직접가서 커밋을 직접해줘야한다.

2 Responses to “Code sharing using svn:externals property”


  • 오~~ 매우 오랜만에 포스팅 하신 것 같네요!
    저도 최근 프로젝트 관리를 SVN 으로 하고 있는데 저런 외부 프로젝트 관리가 문제시 되더군요. 제가 사용하는 클라이언트인 TortoiseSVN의 경우 외부등록된 SVN 폴더를 그대로 가져와도 기본적으로 같이 관리가 되지는 않더군요.
    헌데 이렇게 사용 할 경우 혹여나 외부라이브러리를 수정하게 되면 관리가 모호해지는 경향이 있는 것 같습니다. 그래서 전 그냥 외부라이브러리는 export 시켜서 프로젝트에 넣어 관리하고 있습니다.
    같은 이유로 공용라이브러리도 사용 안 하구요.

    한 프로젝트의 소스는 한 폴더에~~ 주의입니다만 이게 효율적인 것인지는 아직 모르겠네요.

  • 네…오랜만에 포스팅하네요 ^^
    말씀하신데로 물론 외부 라이브러리를 수정했을시에 관리가 좀 애매해지는 경우가 있습니다. 그래서 되도록이면 외부저장소의 파일들은 항상 읽기 전용으로 취급해서 관리하는 편이 바람직하다고 합니다. 예를들어 MyProject 라는 프로젝트에서 연결한 외부라이브러리에서 수정사항이 발생했을경우 직접 수정하지 말고 해당 외부저장소 작업본에서 버그를 수정한 후에 다시 MyProject에 돌아와 갱신하는 방식을 권장하는 편입니다. 물론 대부분의 오픈소스는 변경을 해도 권한이 없기 때문에 커밋을 한다해도 반영이 안되겠죠.
    프로젝트의 성격이나 종류에 따라 약간씩 차이가 있어 어느것이 정답이라고는 말씀드릴 수가 없겠네요…^^ 단지 작업자가 편하다고 생각하고 효율적이다고 여기면 그것이 정답인것 같습니다.

Leave a Reply

Spam Protection by WP-SpamFree