Mac Catalina 업그레이드 후 루트 디렉토리를 사용할 수 없다. Read-Only 상태의 파티션으로 나누어져 있어 기존 루트 디렉토리의 사용자 디렉토리는 "/Users/Shared/Relocated Items/" 디렉토리로 모두 옮겨진다. 이는 디스크의 논리 파티션이 운영체제를 위한 ReadOnly 전용 공간과 사용자 데이터의 파티션으로 나뉘어지기 때문이다.

만약 SVN 을 루트 디렉토리로 사용한 경우 문제가 발생하는데, 적당한 디렉토리로 옮긴 후에 다음의 SVN 명령을 통해 URL 주소를 수정해 주어야 한다.

아래와 같이 현재 SVN 저장소의 정보를 보자

cd <svn directory>
svn info

그렇다면 아래와 유사한 결과가 출력된다.

Path: .
Working Copy Root Path: /Users/powerumc/...생략...
URL: file:///Users/powerumc/...생략...
Relative URL: ^/
Repository Root: file:///Users/powerumc/...생략...
Repository UUID: fe1381c0-03a0-ad4a-96c3-71fb4ed8e9fb
Revision: 18046
Node Kind: directory
Schedule: normal
Last Changed Author: SYSTEM
Last Changed Rev: 18046
Last Changed Date: 2018-11-21 15:43:56 +0900 (수, 21 11 2018)

위의 결과에서 URL 정보를 참고하여 변경된 URL 정보를 변경해 주면 된다.

svn relocate file:///Users/powerumc/repo/svn
Posted by 땡초 POWERUMC
TAG Catalina, Mac, svn

댓글을 달아 주세요

팀 파운데이션 서버(Team Foundation Server) 를 쓰지 말아야 하는 진짜 이유 #2

팀 파운데이션 서버(Team Foundation Server) 는 2005년 처음 시장에 공개되었다. 이 시기에 많은 버그와 설치 자체가 매우 난이도가 높아서 많은 사람들의 원망을 샀다.

참고 - TFS를 쓰지 말아야 하는 진짜 이유 #1 (링크)

TFS를 쓰지 말아야 하는 진짜 이유 #1을 정리해 본다.

  • 통합? 모든 것을 만족할 수 있지만, 어느 것도 만족할 수 없다.
  • 특정 제품(Visual Studio)에 완벽하게 통합되어 외부와 완벽하게 격리된 솔루션이다
  • 우리나라에는 전문가가 없다
  • 전문가적인 서비스를 제공하는 업체도 없다
  • 마이크로소프트 제품으로 발라야 한다
  • 예측할 수 없는 잦은 장애, MS 제품에 잔지식이 많아야 한다
  • 제대로 된 기능이 하나도 없다

TFS를 쓰지 말아야 하는 이유 중 기능적인 요소로는 다음과 같다. (차후에 자세히 다루겠다)

  • 데이터베이스에 소스 코드가 저장되다보니 DB 로그 사이즈는 DB 용량(데이터)의 수십 배가 넘어간다
  • 모든 서버 통신은 SOAP 프로토콜을 사용하므로 매우 느리다
  • 작업 항목(WorkItem) 관리, 이슈/버그/개발 등을 관리하기에 매우 비효율적이고 쓰는 것 자체가 스트레스로 발전할 수 있다. (다른 이슈 관리 툴에 비해)
  • 모든 기능에 제한이 너무 많다

1. 팀 파운데이션 서버(Team Foundation Server)[1]

구글 트랜드(Google Trends)는 아래의 그래프와 같이 새로운 버전이 나올 때 조금씩 치고 올라가는 것을 알 수 있다. 하지만, 시간이 지날수록 이탈하는 사용자가 많을 것이고, 현재는 엉망으로 만들었던 TFS 2005 버전보다 더 관심이 줄어든 것으로 보인다.



2. TFS vs SVN

필자도 사실 이걸 보고는 깜짝 놀랬다. SVN(아파치 서브버전)이 알려진 시기는 TFS 2005와 몇 년 차이가 나지 않지만, SVN은 그야말로 LTE처럼 뻥 뚫린 고속도로처럼 고속으로 성장을 했다. 반면에 Team Foundation Server는 바닥에서 지렁이 기듯이 기어다닌다.



3. TFS vs SVN vs GIT

SVN과 GIT이 끼니 더이상 TFS에 대해서 할말을 잃게 만든다. 이쯔음 되면 TFS를 쓰는 사람들은 분명 M빠거나 멋모르고 쓰는 것이 분명하다.



4. TFS vs SVN vs GIT vs Mercurial

따로 TFS는 해설이 없어도 될 것 같다. 아래의 그래프가 여실히 보여주고 있으니 말이다.



결론

99% 중에 1%라면 매우 희소성이 있고 가치가 있어 보일 수도 있다. 필자가 그랬다. 스스로 가치 있다고 판단한다면 분명 그것은 가치가 있는 것이다.

하지만 소스 제어를 비롯한 ALM은 혼자만 가치를 느껴서는 절대로 공존할 수 없는 도구의 집합이다. 통합이 완벽해서 완전히 격리된 ALM 제품은 소프트웨어에 생명을 불어 넣기에 바라보는 안목을 작아지게 만든다. 툴에 종속되어 생각을 제한해서는 안된다.

100명 중 99명이 No 라고 말할 땐 그만한 이유가 있다. TFS는 2005년부터 시작되었고 현재 2013년이다. 횟수로 8년이 되었지만, TFS는 여전히 고질적인 문제를 해결하고자 하는 노력을 하지 않는 것 같다. 현재의 TFS 2012/2013 은 TFS 2005 초기 버전 그 이상을 아직도 뛰어 넘지 못했고, 앞으로도 뛰어 넘지 못할 것이다.

  • 성능
    점점 느려진다. 28GB 넘는 바이너리가 없는 소스코드를 인트라넷 네트워크에서 10시간 넘게 받은 적이 여러번이다.

  • 확장성
    SDK로 깨잘되는 것 말고 할 수 있는 확장 포인트가 거의 없다.

  • 사용성
    애자일보드/칸반(Kanban), 드래그&드롭, 이런거 보여주면서 사용성이 좋다고 하면 오류다. 실무에서 거의 쓸 일도 없고 더 불편하다.

  • 크로스플랫폼
    Team Explorer EveryWhere 가 크로스플랫폼을 지원한다고? 만약 이클립스를 안쓰면 어쩔건데…? 답이 없다. 다양한 개발툴 대부분이 TFS를 지원해 주는 플러그인이 없고, 지원이 된다고 해도 소스 제어 수준에서만 지원을 한다. 그러므로 통합의 의미 자체가 희석되어 버린다.


  1. ‘TFS’ 트랜드 검색 시 merida/matts 등의 통계에 방해되는 데이터가 포함되어 Team Foundation Server 로 탐색을 하였음.  ↩


Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 조경민 2014.05.14 18:36 Address Modify/Delete Reply

    참 안타까운 현실이네요.. 안타까운 마음에 글 남겨봅니다..
    저희 회사에서는 아직도 TFS 2010을 사용하고 있습니다. 물론 제가 서버 구축(MOSS연동까지..)부터 관리까지 다 하고 있는 상태이구요. 용도는 이슈(요구사항, 버그) 및 개발작업(릴리즈, 로드맵, 사이트모듈, 회의록, QA요청) 관리 위주로 사용하고 있습니다. 소스관리는 시도를 했다 결구 SVN으로 갈아탔지요.. 요즘 SVN은 AD와 연동이 되서 그나마 다행이었네요.
    제가 기존 TFS에 매력을 크게 느꼈던 부분은 양식의 커스터마이즈와 한글화 때문이었습니다.
    위에 언급한 이슈(요구사항, 버그) 및 개발작업(릴리즈, 로드맵, 사이트모듈, 회의록, QA요청)모두 양식을 커스터마이즈 해서 사용하고 있습니다. 필드까지 싹 변경 할 수 있기 때문에 저에게는 엄청난 강점으로 느껴졌었습니다. 아주 심플한 혹은 강제화 할 수 있는 양식으로 탈바꿈할 수 있다는 부분은 큰 매력이였네요. 지금도 물론 잘 사용하고는 있지만 근래 JIRA 등의 동향을 보고 싶어 검색하다 여기까지 오게 됬네요.
    지금으로써 제일 불편한점은 간트차트를 사용하지 못한다는 것 외에는 크게 없는데.. JIRA를 데모해보면 또 어떻게 바뀔지 모르겠네요.
    환경적인 내용 외에 위 언급드린 내용 기준으로 비교되는 글이 더 있음 정말 좋을 듯 합니다. ^^

    아 그리고 한글화는 아직도 TFS가 최고라고 생각되네요 ㅋㅋ이넘의 짧은 영어는 언제나 발목이..

    좋은 글 잘 읽었습니다. 앞으로도 좋은 정보 부탁드립니다.
    감사합니다.

  2. 남뉴 2014.07.02 11:21 Address Modify/Delete Reply

    재밌는 글 감사합니다. 전 오히려 개발소스버젼관리시스템 자체에 회의감이 듭니다. 여러 사람이 쉽게 소스를 관리하는건 장점이고 권한에 따른 제한도 있어서 장점일 것 같지만, 오히려 잘못된 버젼 관리로 인한 문제가 더 많아 질때가 있습니다.(이건 직급이 높아도 경험이 많아도 문제가 발생합니다. )
    덕분에 압축과 시스템을 병행하고 있습니다. 마치 종이로 인쇄하고 다시 PDF나 문서파일로 웹에도 올리는
    형상이죠

  3. 지나가는이 2015.04.20 16:06 Address Modify/Delete Reply

    훌륭한 정보 잘보고 갑니다. 감사합니다.

$tf 폴더

팀 파운데이션 서버(Team Foundation Server) 2012 버전부터 로컬 워크스페이스(local workspace) 에 매핑된 폴더 중 $tf 파일이 생긴 것을 알 수 있다. 이 폴더는 숨김(hidden) 속성이 적용되어 있어 안보인다면 숨김 폴더도 보이도록 윈도우 익스플로어(Windows Explorer) 에서 설정을 변경하면 된다.

이 폴더는 여러분이 주로 작업하는 작업 영역(Workspace)일 경우 생각하는 것 보다 훨씬 많은 용량을 차지하고 있다. 이 폴더는 특성상 늘어나면 늘어나지 절대 줄어들 일이 없다. 대부분의 시간이 지날수록 코드의 라인은 늘어나고 변경이 일어나는 부분도 많아진다.

이 폴더가 내심 꺼림직해서 지워도 또 다시 생긴다. 이 폴더는 Team Foundation Server 2012 버전을 쓰고 + 로컬 작업 영역(Local Workspace)로 매핑된 폴더에 생긴다. 이게 의외로 골치 이프기도 하고 문제가 되기도 한다.

$tf 폴더, 왜 생기나…

이 폴더은 네트워크가 오프라인(offline) 상태로 중앙 서버에 연결할 수 없는 경우 스텐바이(standby)하고 있다. 물론 오직 오프라인(offline)을 위한 폴더는 아니다.

팀 파운데이션 서버(Team Foundation Server) 2012 + 로컬 작업 영역(local workspace) 조합이면 백퍼 생기는 폴더다. 일종의 소스 코드의 스냅샷(snapshot) 과 메타데이터(Metadata) 정보를 가지고 있다. [1]

image-1
[이미지 참조 링크]

이 폴더가 생기는 주된 이유 중 하나가 네트워크가 오프라인(offline)이 될 때 서버로 연결할 수 없으므로 이 로컬 작업 영역을 참조하게 된다. 팀 파운데이션 서버(Team Foundation Server)는 변경집합(change set) 단위로 데이터베이스(MSSQL)에 저장하는데, $tf 안에 변경집합(change set) 정보를 데이터베이스 처럼 활용하여 저장하게 된다.

image-2
[이미지] $tf 폴더 내부 구조, 각 파일은 zip 압축이 되어있다.

정체성을 잃은 TFS 소스 제어

이런 오프라인 기능을 지원하는 건 반갑다만 팀 파운데이션 서버(Team Foundation Server) 는 처음부터 오프라인을 고려하고 만들어지지 않았다. 전략적으로 비주얼 스튜디오(Visual Studio) 를 사용하는 기업이나 단체를 대상하기 때문에 오프라인(Offline) 가능성이 매우 낮은 환경을 대상으로 하는 솔루션이다.

필자의 경우 예전부터 작업하던 모든 $tf 폴더의 용량이 1GB를 훨씬 넘었고, 이런 빈번하게 작업하는 폴더를 여럿 가지고 있다. (최근 용량이 많이 차지해서 과감하게 $tf 를 지워버렸다.)

SVN 또한 .svn 이라는 숨김 폴더가 있는데 이를 ‘Administrative Directory’ 라고 부른다. 이 관리 디렉토리는 SVN을 사용하면서 변경되는 파일의 정보를 저장한다. SVN도 마찬가지로 .svn 폴더의 용량이 증가하게 되는데, 이런 경우 작업 중인 디렉토리를 복사할 때 .svn 디렉토리도 함께 복사가 된다. 최근 SVN은 이 폴더가 최상위 루트에 하나만 생기도록 변경되어 작업 디렉토리마다 .svn 폴다를 신경써야 할 필요가 사라졌다.

git 으로 잘 알려진 대표적인 분산 제어 방식의 소스제어(Distributed Version Control) 또한 로컬의 스테이징 저장소(Staging Area)를 이용한다.

사실 팀 파운데이션 서버(Team Foundation Server) 는 애시당초 오프라인에 대한 대안이 없었다. 네트워크가 오프라인이 되고 파일을 체크아웃을 하면 로컬 작업 파일이 읽기 전용(Read Only) 파일 속성이 해제되고 서버와 연결이 끊겨도 수정이 가능하다. 다시 네트워크가 사용이 가능할 때 ’온라인 상태’로 변경할 수 있는데, 이 때 체크이웃된 사실을 서버에 통보하게 되고 서버는 이 때 체크이웃 상태로 변경한다. 오프라인 상태일 때의 변경 집합은 온라인 상태에서 병합하게 되는 시나리오를 가지게 되는데, 로컬에 저장했던 변경 기록은 병합할 때 충돌(conflict)를 줄일 수가 있다.

하지만 좋은 오프라인 정책이 있더라도 경험적으로 알 수 있은 것은 오프라인(서밋이 일어나지 않는)이 오래될 수록 충돌(conflict)은 피할 수 없다. 비교적 간단하게 병합(merge)할 수 있는 어느 정도의 단계를 넘어서면 병합 도구는 변경이 일어난 부분과 일어나지 않은 부분을 제대로 분간하지 못하는 상황까지 온다.

$tf 폴더는 생기는데, 이를 제한할 수 있는 방법이 없어…

어떤 이유던 간에 $tf의 용량은 점점 커진다. 그러나 이 폴더의 용량을 제한할 수 있는 설정은 존재하지 않는다. 그리고 git 을 함께 사용하는 개발자는 소스 코드가 보관된 폴더에서 .gitignore 에 $tf 를 제외할 수 있도록 설정을 하기 바란다.

다만, $tf 폴더가 가지는 몇 가지 장점이 있다. 그러나 오프라인(offline) 일 때 굳이 파일의 버전을 비교할 예외적인 상황도 없었고, 오프라인 일 때 파일 이름을 변경한 경우도 있으나 다시 온라인일 때 무리 없이 파일의 상태가 반영이 되었다. 그러므로 필자는 수 년을 사용하면서 이 장점을 얻기 위한 예외적인 상황을 거의 몇 번밖에 만나보지 못했다.

MSDN 에서 $tf 폴더에 대해 자세하게 기술이 되어 있지 않으나 참고가 필요한 분은 이 링크[2]를 통해 확인하기 바란다.


  1. References - Team Foundation Server - Trying to understand Server versus Local Workspaces
    http://blogs.msdn.com/b/willy-peter_schaub/archive/2011/11/30/team-foundation-server-trying-to-understand-server-versus-local-workspaces.aspx  ↩

  2. References - Team Explorer Everywhere의 새로운 기능
    http://msdn.microsoft.com/ko-kr/library/jj155781.aspx%23local  ↩


Posted by 땡초 POWERUMC

댓글을 달아 주세요


최근 Git이나 Mercurial 과 같은 분산제어 방식의 소스 제어 제품을 무조건 맹신하고 찬양하거나 분산제어 방식보다 중앙집중형 소스제어 방식을 무조건 배척하는 현상이 일부 나타나고 있다.

리누스 토발즈(Linus Tovalds)와 같은 공산주의(Communism) 사상의 이상을 강조하는 철학이 담긴 Git은 GitHub.com을 통해 소스 코드를 공유함으로서 오픈 소스 진영에 매우 발전적인 기여를 하고 있음은 확실하다. 리누스 토발즈(Linus Tovalds)가 만든 것이라 그런지 훨씬 더 주목받고 있는 것 같다.

중앙집중 소스제어와 분산제어 소스제어 방식은 그 원칙과 근본적인 가치에 차이가 있는, 방법론으로 접근해야 할 것이다. 따라서 각 소스 제어의 방식마다 특징과 장단점이 있으며 ‘좋은 게 좋은 것 아닌가~’ 라는 간단한 답을 얻길 바란다.

필자는 중앙집중 소스제어와 분산제어 소스제어 방식의 장단점을 5가지의 관점에서 살펴보자. 중앙집중 소스제어(이하 중앙제어 방식)은 분산제어 소스제어 방식을 사용하는 몇 가지 소프트웨어를 제외한 대부분으로 보면 된다.

  • 중앙통제력
  • 정책주입력
  • 분기용이성
  • 사용편의성
  • 성능

그 외에 도움이 될만한 위키피디아(Wikipedia) 링크를 참고하기 바란다.

내용상 비교하는 대상은 중앙제어 방식은 ‘팀 파운데이션 서버(Team Foundation Server)’와 SVN을 많이 참조하였고, 분산제어 방식은 ‘Git’을 많이 참조하였다.

중립적인 관점에서 글을 작성하였으나 어느 한 쪽으로 편향이 되었다면 미리 그 점에 대해 양해를 구하는 바이다.

중앙통제력

이름에서도 알 수 있는 것 처럼 중앙집중적인 통제력은 기존의 중앙집중 방식이 분산제어 방식보다 유리한 점이 많다. 분산제어 방식은 자신이 서버로의 통제를 받는 동시에 제 3자에게 있어 자기 자신이 서버가 된다. 반면, 중앙집중 방식에서는 서버가 오직 물리적인 한 곳에 위치해 있다.

때문에 중앙집중 방식은 조직에 있어 정책적인 부분을 클라이언트에게 강제로 주입할 수 있는 여지가 많다. (물론 분산제어 방식도 가능하다) 중앙 서버 한 곳의 설정만으로 많은 클라이언트를 통제할 수 있다.


이미지 참조

그리고 모든 히스토리는 중앙 서버의 데이터베이스에 저장이 되기 때문에 클라이언트에게는 단지 소스 밖에 없지만, 분산제어 방식은 그렇지가 않다. Git의 스테이징 스토리지가 바로 클라이언트가 가지고 있는 데이터를 저장하는 (임시?)스토리지다.

조직에서 소스코드가 변경되는 주요 변경 이력은 매우 민감한 부분이고, 영업비밀과 직결되는 요소들이 많다. 응용프로그램이 연결되는 데이터베이스의 컬럼이나 테이블의 사소한 변경에도 응용프로그램은 수정되어야 할 수 있고, 이것이 응용프로그램의 소스코드에 반영이 되면서 소스제어에 이력을 남기게 된다.

정책주입력

정책적인 주입력은 중앙통제력과 유사한 부분이 많다. 중앙통제력이 크면 클수록 정책주임력은 향상된다. 중앙 서버의 정책적인 설정만으로 여러 클라이언트는 중앙 서버에 의해 통제받을 수 있다.

특히 ALM(Application Lifecycle Mamangement) 제품과 개발 IDE 제품간에 얼마나 긴밀하게 잘 통합이 되었느냐에 따라 정책주입력에 영향을 미친다. 통합이란 것이 양날의 검과 같아서 좋게 말하면 ‘All in One’이라 표현할 수 있겠고, 나쁘게 말하면 구성요소간에 강한 응집력으로 인해 제한된 확장이라 말할 수 있겠다.

ALM 통합의 장점

  1. 한 번의 구성으로 모든 것을 사용할 수 있다.
  2. 새로운 업그레이드도 한 번의 구성으로 모든 것을 구성할 수 있다.
  3. 개발툴과 통합되어 사용하기 쉽다.

ALM 통합의 단점

  1. 설치/구성 환경은 벤더에 의해 결정된다.
  2. 기능이 하나 하나가 완성도가 높지 않아 기업 및 도메인 환경에서는 추가 개발이 필요한 경우가 많다. (범용성을 위해…)
  3. 오픈 소스 ALM 도구보다 쓸 수 있는 도구들이 적다. (애드인/플러그인)
  4. 다양한 외부 도구와 연동이 제한된다.

분기용이성

분기(Branch)는 나무에서 여러 가지(Branch)로 뻗어 나가는 것을 일컬어, 하나의 소스 코드에서 여러 가지(Branch)로 소스 코드를 키울 수 있다. 특히 분산 제어 방식에서 분기가 얼마나 유용하고 효율적으로 사용할 수 있는지 잘 알 수 있다.

중앙 제어 방식에서의 분기는 곧 변경 이력으로 반영되어 영구적으로 분기 이력이 남게 된다. 때문에, 분기를 개인적인 용도로 사용하는 것이 힘들다. 소스 제어의 파일 시스템 구조를 복잡하게 만들 수 있고 구성원 개개인이 이를 핸들링 하기에는 전체 제품의 소스 코드에 좋지 않은 영향을 미칠 수 있다.


이미지 참조

반면, 분산 제어 방식의 경우 분기는 반드시 알아야 할 매우 효과적인 기능 중 하나로 볼 수 있다. 위에서 언급 했듯이 서버에게는 클라이언트가 되지만, 제 3자에게는 곧 서버가 된다. 즉, 로컬 서버(클라이언트)에서 자체적으로 분기가 가능해진다. 클라이언트에서 분기와 서버로 Push되는 정보는 다르므로 서버의 정책이나 구조에 영향을 최소한으로 적게 미치게 된다.

하지만, 중앙 제어 방식에서도 이런 단점은 충분히 극복할 수 있다. 분기는 병합(Merge)이라는 조건을 전제로 수행되는데, 만약 병합이라는 전제 조건이 없다는 가정하에 이와 유사하게 문제를 해결할 수 있는 방법이 있다.

중앙 집중 방식의 소스 제어 제품마다 기능적으로 다른 점이 있겠지만, 다중 작업 영역(Workspace) 또는 보류(Shelve) 기능을 이용하여 로컬 분기(Local Branch) 기능을 유사하게 흉내낼 수 있다. (물론 진정한 의미에서의 분기 목적과는 다소 차이가 있다)

사용편의성

사용편의성은 소스 제어를 사용하는 사용자가 얼마나 소스 제어를 편하게 사용함을 의미한다. 이를 언급하기 전에 사용편의성은 개개인의 경험적인 부분에서 다를 수 있다.

먼저, 분산제어 방식의 대표적인 Git을 험오하는 이유 10가지에 대해 쓴 블로그 내용을 참고하자.

Git is the source code version control system that is rapidly becoming the standard for open source projects. It has a powerful distributed model which allows advanced users to do tricky things with branches, and rewriting history. What a pity that it’s so hard to learn, has such an unpleasant command line interface, and treats its users with such utter contempt.
이하 생략…
http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/

대부분의 소스 제어 명령은 GUI(그래픽 인터페이스)와 CMD(명령줄 인터페이스) 방식을 제공한다. 주로 GUI 방식은 개발툴과 연동이 되는 확장 또는 플러그인 방식으로 제공되고, CMD 방식은 소스 제어 제품 자체에서 제공하는 고유의 기능으로 제공이 되는 것이 대부분이다. 그래서 소스 제어를 사용하는 개발자가 어떤 환경에서 개발하느냐에 따라 GUI 또는 CMD 방식으로 갈리는 경우가 많다.

먼저, 이클립스(Eclipse) 또는 비주얼 스튜디오(Visual Studio)와 같이 비주얼을 강조하는 개발툴에서는 GUI 방식의 소스 제어 플러그인을 사용하는 경우가 대부분이다. 이런 환경에서는 키보드와 마우스를 함께 사용하는 경우이고 아이콘(icon)으로 수정된 파일을 바로 확인할 수 있다.

반면, SVN 또는 Git 의 CMD 도구의 사용이 익숙해질 경우 상당히 빠르게 명령을 사용하거나 결과를 확인할 수 있다. 그리고 개인용 컴퓨터의 성능에 거의 영향을 받지 않고 소스 코드를 개발할 수 있고, 손이 마우스와 키보드로 번갈아가며 사용할 필요가 없어 익숙한 사람에게는 더할 나위 없이 편리하다. 더불어, SSH와 같은 단순 Plain Text 환경에서도 제어가 가능하기 때문에 사용에 있어 거의 제한도 없다.

하지만 대체적으로 두 방식 모두 GUI 도구를 제공하거나 GUI 공개 소프트웨어가 많기 때문에 취향에 맞에 사용할 수 있다.

성능

중앙제어 방식은 모든 동작이 서버 측의 허가 없이는 불가능하거나 반드시 서버와 연결이 되어야 한다. 인트라넷이라면 크게 성능의 손실은 없겠지만, 지역이 다른 사람과 오픈 소스 개발을 하거나 클라우드 소스 컨트롤을 사용하는 경우 매우 느리다.

분산제어 방식은 모든 동작이 대부분 로컬에서 이루어 진다. Push, Fetch 같은 동작만이 서버와 연결이 필요하다. 때문에 성능이 매우 좋은 것이 특징이다. 하지만, 중앙제어 방식과 다르게 많은 데이터를 로컬에 저장해야 하므로 중앙제어 방식보다 로컬에 충분한 용량이 확보되어야 한다.

결론

몇 가진 기본적인 관점에서 깊지 않은 내용으로 중앙제어 방식의 소스제어 컨트롤과 분산제어 방식의 소스 컨트롤을 살펴보았다.

필자에게 어떤 것을 사용할지 묻는다면, 작은 개발 조직과 기업 환경에서는 중앙제어 방식을 권장하고 싶다. 많은 소프트웨어 개발 조직에서 여전히 통제하에 소프트웨어 개발을 하기를 원한다. 그리고 암묵적인 소프트웨어 개발 프로세스를 명시적인 프로세스로 개선하고자 하는 곳도 과거보다 많이 생겼다. 이런 환경은 중앙제어 방식이 더 효과적이라 믿는다.

반대로 분산제어 방식은 패키지를 개발하는 기업이나 IT 컨설팅, 국지적 개발 환경이 필요한 경우 효과적일 것이라 생각한다. 물론 기업 환경과 맞지 않는다는 것이 아니며, 통상적인 경우를 말한다.

필자는 우연히 Stack Overflow에서 매우 흥미로운 주제를 발견하였다. 바로 [Git vs Team Foundation Server [closed]]11 인데, 어느 개발팀의 분산제어 방식과 중앙제어 방식의 대결 구도에서 어떤 것을 선택해야 할 것인가에 대한 논의였다. (참고로 필자는 최근 git을 더 좋아한다.)

내용인 즉, 자신의 개발팀에 Git를 도입시켰으나, 개발 팀원들은 팀 파운데이션 서버(Team Foundation Server)로 바꾸길 원했다. 이 질문에 추천 답변의 내용은 ’Git을 버려라. Git을 계속 쓰다가는 계속 비난을 받고 싸우게 될거다’고 한다.

결론은 소스제어 컨트롤(Source Control)은 개인이 아무리 좋고 훌륭한 소스제어라고 생각하더라도 다른 사람들은 그렇게 생각하지 않을 수 있고, 선택에 있어서 다수의 의견에 귀 귀울이는 것이 좋을 것 같다.

I think, the statement

everyone hates it except me

makes any further discussion waste: when you keep using Git, they will blame you if anything goes wrong.
Apart from this, for me Git has two advantages over a centralized VCS that I appreciate most (as partly described by Rob Sobers):
automatic backup of the whole repo: everytime someone pulls from the central repo, he/she gets a full history of the changes. When one repo gets lost: don’t worry, take one of those present on every workstation.
offline repo access: when I’m working at home (or in an airplane or train), I can see the full history of the project, every single checkin, without starting up my VPN connection to work and can work like I were at work: checkin, checkout, branch, anything.
But as I said: I think that you’re fighting a lost battle: when everyone hates Git, don’t use Git. It could help you more to know why they hate Git instead of trying them to convince them.
If they simply don’t want it ’cause it’s new to them and are not willing to learn something new: are you sure that you will do successful development with that staff?

Does really every single person hate Git or are they influenced by some opinion leaders? Find the leaders and ask them what’s the problem. Convince them and you’ll convince the rest of the team.

If you cannot convince the leaders: forget about using Git, take the TFS. Will make your life easier.


Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 이성훈 2018.05.10 14:53 Address Modify/Delete Reply

    분산제어 서버를 이용하면 프라이빗 블록체인과 차이가 없는건가요..?!

[TFS] 어떤 개발자의 외침. "왜 TFS를 쓰기 싫을까? - TFS is suck." [1/2]
[TFS] 어떤 개발자의 외침. "왜 TFS를 쓰기 싫을까? - TFS is suck." [2/2]


지난 1편의 글에 이어, 어떤 분이 원문을 쓰신 분에게 이런 말을 남겼다.

이 코멘트에 대해 원문을 쓰시는 분은 아래의 링크로 반박의 글을 작성하셨다.

원문 : http://imjuni.tistory.com/488

   


필자의 입장에서는 상용 솔루션이 커스터마이징을 해야 쓸만한 제품이란 것은 제품을 구매한 사용자 입장에서는 그리 달갑지는 않을 것이다. 대신 3rd party 벤더나 오픈 소스를 이용하여 기능을 더 보탤 수 있고, SDK API를 이용하여 직접 도메인 제약에 맞게 만들 수도 있을 것이다.

원문을 읽어보면 저 분은 TFS에게 어떻게 데였는지 모르겠지만, 병적으로 거부하는 것 같다. 그렇다고 싫어하는 이유에 대해 근거가 있거나 정확하게 잘못된 정보를 바탕으로 작성이 되었다는 것에 매우 안타까움을 느낀다.



첫 번째로, 위의 원문에서 아래와 같이 잘못된 정보를 가지고 있다.

   

일단 TFS에서는 VCS 기능을 어느 정도 확장을 할 수 있다. 이때 TFS Server는 물론이고, 클라이언트인 Visual Studio Extensibility를 이용하여 클라이언트도 확장할 필요가 있다. 이는 비단 TFS 뿐만이 아니라 SVN도 마찬가지다. 고로 어느 범위까지 확장할 것인가 결정에 따라 개발을 해야 할 범위가 틀려질 수 있다.

   

두 번째로, TFS를 Git와 비교한다는 것은 좀 무리가 있다고 본다.

Git는 유명한 리눅스를 개발한 리누스 토발즈에 의해 분산 버전 관리할 수 있는 소스 제어 솔루션이다. 분산 버전 제어가 자칫 매우 유연해 보일 수 도 있을 것이다. 이에 반해, TFS는 중앙 집중 방식의 소스 제어 솔루션이다.

기업에서 통제가 되지 않는 소스 제어는 보안적인 이슈나 소스 코드 유출 등의 사고가 생기가 마련이다. 이런 점에서 분산 버전보다 중앙 집중 방식이 기업에서 개발 환경 조건에 더 부합한다고 본다.

이런 장단점 등으로 오픈 소스를 지향하는 사람들은 분산 버전 관리 방식인 Git를 선호한다.

반면에, TFS는 TFS란 제품이 나오기 전부터 Microsoft 내부적으로 이슈 관리와 소스 제어를 할 수 있는 솔루션을 만들어 사용하고 있었다. Microsoft는 소프트웨어 기업이다. 소프트웨어를 잘 개발할 수 있도록 Team Foundation이라는 제품으로 발전하면서 상당히 많은 노하우가 녹아있는 제품이다.

SVN는 CVS가 Atomic Transaction(원자성)이 보장되지 않는 이유의 심각한 문제로, SVN으로 다시 태어났다.

   

원문을 쓰신 분은 필자가 이해하기 힘든 이유로 CodePlex와 Git를 비교하는 것은 '중국이 한국보다 인구가 많으니 강대국이다.'라는 논리와 같다.

잘못된 정보만을 가지고 TFS를 혐오하는 것은 바람직하지 않다고 본다. 안된다고 하는 많은 기능들이 이미 예전부터 지원했던 것인데 원문을 쓰신 분은 이런 기능을 이용하는 방법을 몰랐던 것이지, TFS 자체의 문제는 아니다.




이런 말을 해주고 싶다.

도구는 단지 도구일 뿐이다.
쓰는 사람이 잘 써야 좋은 도구이다.
잘 쓸 수 없는 도구는 그 사람의 잘못이지 도구의 문제가 아니다.
 

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 나그네 2013.01.13 17:36 Address Modify/Delete Reply

    git 든 svn 툴이든 오픈소스 제품군만으로도 충분 해서. .굳이 tfs 도입할 이유가 생각나지 않는군요.

    vs 플러그인으로 연동하면 그만이라서..

  2. JIN 2016.08.29 11:56 Address Modify/Delete Reply

    정성스레 작성하신 글 잘 보고 갑니다..
    TFS를 프로젝트에 처음 적용해 나가면서 어떤것인가 하고 경험해 가는 중에 포스팅 하신 몇몇 글들을 읽었습니다. ALM툴/서비스는 처음인지라 TFS가 정말 적당한지 어떤지에 대한 개념도 없이 아래의 몇가지 장점만으로 선택을 했습니다.
    처음엔 제목만 보고 아뿔싸 'TFS' 문제가 많은가보다 하고 심장이 쫀득해졌다가,
    객관적으로 분석해주신 내용을 보고 오히려 최고는 아니었어도 현재로써는 적절한 선택이었다는 생각이 들더군요..

    1. 현재 팀원이 1.2(12명 아닙니다 ㅎㅎ)명.. TFS 정책상 부담없이 쓸수 있고, 중장기적으로 팀이 5명까지 커질일이 없다는점
    2. 현재 Visual Studio를 사용중이며
    3. 1의 이유로 새로운 툴/서비스에 대한 시장조사/검증 자체가 부담
    4. 중앙 집중식 버전 컨트롤
    5. 그나마 접하고, 본게 이것
    6. 처음엔 단지 소프트웨어 버전컨트롤 이상도 이하도 아닌 이유로 사용함
    7. FDA 승인을 필요로 하는 제품 개발과 깊은 관련이 생기면서 Validation 문제에 봉착
    (FDA regulation 의 Validation 입니다 이는 Software의 Validation과는 다른 훨씬더 확장된 내용을 다루고 있습니다. 첨언하면, Software의 Validation하면 Software의 Specification과 Use case를 따르는 기능의 검증이 촛점이라면, FDA의 것은 SDLC를 어우르는 광범위한 Traceablity, 시스템 검증, 변경 관리 등등.. 전사적으로 등골빠지는 것중의 하나가 FDA 승인이죠..)
    8. 다만 7의 결과물이 Documented Evidence 가 되어야 하는게 FDA의 요구사항입니다. TFS내의 WORK ITEM과 Design Specification, Code, Test, Debug(issue) 등의 결과물이 문서상에 존재해야 한다는것이었죠.. 이 작업은 사람을 미치게도 할수 있는 부분입니다.. ㅎㅎ 이부분은 TFS에서도 직접적으로 문서화를 위한 솔류션을 통합한것은 아닌거 같더라구요 때문에 Modern Requirements라는 솔루션을 채택했습니다.. 이는 TFS상의 WORK ITEM의 부모자식관계 변경 이력, User Requirements, Design Specification, Code, Test, Debug(Issue) 의 Traceability등을 자동으로 생성해주는 역할을 합니다..
    9. 그 외에도 TFS가 'Microsoft' 라는 알려진 기업의 솔루션이기에 직접 구축한 Opensource based 시스템이나 시장에 인지도가 없는 회사의 솔류션일 경우 FDA의 Audit시에 수없이 많은 질문을 야기할 가능성을 줄여줄수 있다는 점도 큰 몫이었습니다.

Team Foundation 2010 으로 업그레이드? 마이그레이션? 동기화?

많은 원성을 샀던 Team Foundation 2005 버전과 안정화된 Team Foundation 2008, 그리고 놀라우리만큼 강력해진 Team Foundation 2010… 약 5년 동안 Team Foundation Server 제품은 상당히 안정화되었고 테스트 분야에 상당히 공을 많이 들인 제품이 Team Foundation 2010 버전입니다. 더불어 함께 어울려야 하는 Microsoft SQL Server 2008 R2, SharePoint 2010, 그리고 함께 어울리면 간지나는 SCVMM 2008 R2(System Center Virtual Machine Manager), SCCM 2007 R3(System Center Configuration Manager) 등 모두 새로운 마이너버전으로 업그레이드 되었습니다.

특히 최근에 새롭게 Team Foundation 2010 을 도입하는 곳과, 이전에 쓰던 하위 버전에 대해서도 상위 버전으로 옮기기 위해 많은 문의를 주고 계십니다.

Team Foundation 2010 을 도입하거나 상위 버전으로 갈아타기 위해 업그레이드를 선택할지, 마이그레이션을 선택할지 현명한 선택을 위해 가이드해 드립니다.

   

제한 사항

본 포스팅에서 다루는 범위는 소스 제어에 국한된 범위입니다. SharePoint, MSSQL Reporting Services는 추가적인 업그레이드/마이그레이션 작업이 필요할 수 있습니다.

   

Team Foundation 2010 으로 업그레이드

가장 쉬운 방법이고, 데이터손실을 크게 걱정하지 않는 것이 업그레이드 입니다. 업그레이드는 TFS와 연동되는 SQL 서버의 데이터베이스 스키마가 일부 변경이 되면서, 이 범위의 데이터를 TFS2010 용 SQL 데이터베이스 스키마로 자동으로 변환하여 줍니다.

기존의 데이터베이스의 스키마를 변경하는 작업이므로 이전에 저장되었던 변경 집합(Changeset), 분기 및 병합(Branch and Merge) 의 정보를 그대로 안정하게 상위 버전으로 업그레이드할 수 있습니다.

이전에 사용하던 TFS AT(Application Tier) 는 없어도 무관하며, SQL Server의 데이터베이스만 있으면 업그레이드를 진행할 수 있습니다. 이 방법은 일전에 필자의 블로그에 포스팅으로 자세하게 가이드 하였으니 아래의 필자 포스팅을 참고하시기 바랍니다.

[HowTo] TFS 2005/2008 데이터베이스를 TFS 2010 으로 마이그레이션
http://blog.powerumc.kr/276

단, 업그레이드는 단어에서 의미하듯이 1회의 업그레이드 작업으로 상위 버전으로 업그레이드가 완료됩니다. 하위 버전에서 발생하는 추가적인 데이터의 업그레이드는 업그레이드 작업을 처음부터 다시 시작해야 한다는 의미이기도 합니다. 그렇기 때문에 전사적으로 TFS를 적용한 조직에서의 업그레이드는 일정시간의 TFS가 중지가 필요할 수 있습니다.

   

Team Foundation 2010 으로 마이그레이션

일단 골치 아픈 부분이 바로 마이그레이션 입니다. TFS 이전 버전의 AT(Application Tier)와 DT(Database Tier)가 모두 고스란히 존재해야 합니다. 양측의 TFS AT의 TFS API를 호출하여 서로간의 데이터를 마이그레이션하기 때문에 여차하면 일부 데이터 손실이 있을 수 도 있다고 합니다. (너무 겁먹지는 마시고요^^)

다만 이 마이그레이션은 One-Way 방식이기 때문에, TFS의 원본 서버(Source Server)와 대상 서버(Target Server)로 구분하여 진행하면 됩니다.

 글로벌 팀인 Visual Studio Ranger 에서 이 마이그레이션 작업을 쉽게 할 수 있는 도구를 CodePlex 사이트에 공개를 하였습니다. (http://tfsintegration.codeplex.com/) 이 TFS Integration 사이트에서 Download 로 이동하신 후에 설치 패키지를 설치하시면, 마이그레이션을 도와주는 도구를 설치하셔서 사용하시면 됩니다.

 마이그레이션은 TFS로 마이그레이션 이외의 File System, IBM Rational, SVN 제품간의 마이그레이션도 지원합니다.

   

   

   

Team Foundation 버전간의 동기화

Visual Studio Ranger 팀이 동기화까지 지원해 줄지는 몰랐습니다만, 참으로 기쁘기도 하네요. 동기화는 양측 TFS 서버간의 변경 이력이 생기면 이 데이터를 주기적으로(변경 즉시 동기화가 아님) 대상 TFS 서버와 동기화를 시도합니다.

 기존의 TFS<->TFS 간의 동기화도 지원하지만, File System, IBM Rational 제품, 그리고 SVN 간의 동기화도 지원합니다. 일전에 TFS<->TFS, TFS<->File System 간의 동기화는 잘 동작하는 것으로 확인을 하였습니다. (소스 제어 및 작업 항목간의 동기화)

   

참고

아래의 붉은 마킹을 한 다운로드 문서는 마이그레이션/동기화 작업을 하기 전에 반드시 필독하시기 바랍니다.

 

 

 

   

   

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요