git으로 소스 관리를 하다보면 가끔(실은 종종 ^^) 책임 추궁을 할 일이 발생한다.

빌드를 했는데 에러가 발생했다면,
그 소스파일의 그 라인을 누가 작성한 것인지 알고 싶어지게 된다.

그래야 그 사람에게 그 에러를 해결하라고 말할 수 있기 때문이다.


개발자 입장에서는 조금 부정적인 느낌이 드는 Work-Flow이고,
마음에 들지 않는 명령어이기도 하다. (blame : ...을 탓하다)


하지만, 분명 필요한 명령이기도 하다.



1. General Use

     - 어느 소스코드의 몇 번째 라인을 누가 작성했는지 알고 싶을 때엔 아래와 같이 명령하면 된다.


$ cd /srv/workspace/myrepo
$ git blame -L 1,1 ./readme.txt

     - myrepo라는 repository에 있는 readme.txt 파일의 11번째 라인을 누가 작업했는지 알려달라는 의미이다.

     - [ -L ] 옵션 뒤에는 알고 싶은 라인의 시작과 끝을 명시해줘야 하는데,
       특정 1줄만 알고 싶을 경우에는 위와 같이 같은 숫자를 적어주면 된다.



2. Advanced Use

     - [ git blame --help ] 명령을 해보면 친절한 설명을 볼 수 있다.
     - 혹여라도 도움말이 나오지 않으면, 아래 포스팅을 참조하면 된다.
          ▷ http://whatwant.tistory.com/458

     - 여기에서 살펴볼 것은 [ -e ] 옵션이다.

     - 필자가 최근에 진행하고 있는 업무 중 하나가
     - 빌드 자동화 시스템에 붙여서 빌드 에러가 발생하는 경우 해당 내용의 작성자를 찾은 다음
     - 해당 개발자에게 메일로 에러 내역을 발송하도록 하고자 하는 것이다.

     - 그러기 위해서는 해당 소스 라인의 개발자의 이메일 주소를 잡아내야하는데,
     - 위 스크린샷에서 보는 바와 같이 기본적으로는 개발자의 이름만 보여준다.

     - 그래서 필요한 것이 [ -e ] 옵션이다.


     - 그런데, [ -e ] 옵션이 없는 경우가 있다.
     - 현재 패키지 설치로 했을 경우가 그렇다.
     - 소스 설치로 했을 경우에는 가뿐하게 [ -e ] 옵션을 사용할 수 있다.


가볍게 여기까지~

반응형

'SCM > Git-GitHub' 카테고리의 다른 글

Git 명령어 자동 완성 기능 (Source 설치 時)  (0) 2012.08.20
Git's Tag - git tag  (8) 2012.08.10
git man  (0) 2012.07.25
Gitweb + Apache2  (2) 2012.07.16
Code Review - Gerrit (Install)  (12) 2012.07.07

도움말을 보려고 하는데 다음과 같이 에러가 발생한다면, 다음의 소스코드 설치 과정을 다시 한 번 살펴보기 바란다.


     - [005] Install GIt (in Ubuntu) : http://whatwant.tistory.com/289


이제 [ git blame --help ] 해보면...


짜잔~

반응형

'SCM > Git-GitHub' 카테고리의 다른 글

Git's Tag - git tag  (8) 2012.08.10
git blame (-e 옵션)  (0) 2012.07.29
Gitweb + Apache2  (2) 2012.07.16
Code Review - Gerrit (Install)  (12) 2012.07.07
[004] 당신은 Git을 어떻게 읽나요?  (0) 2012.06.28

Nginx 환경에서 gitweb 구동은 아직 성공은 못했다.
누군가 성공하신 분이 계시면 알려주시면 대단히 감사하겠다는....

일단 기본적인 사항에 대해서는 지난 포스팅을 참고하길 바란다.
     - http://whatwant.tistory.com/397


1. Git 준비 (gitweb 준비)

     - Git을 소스코드 설치를 하셨다면 기본적인 준비는 모두 되어있는 것이다.
     - http://whatwant.tistory.com/289



2. Apache2 준비

     - 간단하게 그냥 패키지로 설치하자.

$ sudo apt-get install apache2



3. 경로 정리

     - 개인적인 취향이 반영된 부분이지만... 여하튼 경로를 정리해보자.
     - git 을 소스설치한 경로는 다음과 같다. [ /srv/install/git/git-1.7.11.2 ]

$ cd /srv/www
$ sudo ln -s /srv/install/git/git-1.7.11.2/gitweb ./gitweb.whatwant.com



4. VirtualHost 생성

     - default 사이트는 삭제하고, 포트 변경해서 생성해보자.

$ cd /etc/apache2/sites-available
$ sudo nano ./gitweb

<VirtualHost *:8080>
        ServerAdmin whatwant@whatwant.com

        DocumentRoot /srv/www/gitweb.whatwant.com

        <Directory "/srv/www/gitweb.whatwant.com">

                DirectoryIndex gitweb.cgi
                Allow from all
                AllowOverride all
                Order allow,deny
                Options ExecCGI

                <Files gitweb.cgi>
                        SetHandler cgi-script
                </Files>

                SetEnv  GITWEB_CONFIG  /srv/www/gitweb.conf
        </Directory>

</VirtualHost>

     - 위 설정과 같이 8080 포트로 gitweb을 구동하고자 한다.

$ sudo nano /etc/apache2/ports.conf

NameVirtualHost *:8080
Listen 8080

     - sites 설정을 맞추자

$ cd /etc/apache2/sites-enabled
$ sudo rm -rf ./000-default
$ sudo ln -s ../sites-available/gitweb ./001-gitweb



5. gitweb.conf

     - gitweb 환경설정을 해보자.

$ sudo nano /srv/www/gitweb.conf

$git_temp = "/tmp";

# The directories where your projects are. Must not end with a slash.
$projectroot = "/srv/repositories";

$feature{'blame'}{'default'} = [1];
$feature{'highlight'}{'default'} = [1];



6. gitweb + gitolite

     - 기본적으로 gitolite를 적용한 환경에서 그냥 gitweb을 연결하면 testing.git repository밖에 안보인다.
     - 그래서 별도의 과정을 추가로 진행하여야 한다.

$ sudo usermod -a -G gitolite www-data
$ sudo chown -R git.www-data /srv/repositories
$ sudo chmod -R g+rx /srv/repositories

     - UMASK 기본 값을 변경해야 한다.
     - 이와 관련된 설정 파일은 gitolite를 설치한 repository를 관리하기 위한 계정에 있다.

$ sudo su - git
$ nano ./.gitolite.rc

    #UMASK                       =>  0077,
    UMASK                       =>  0027,


이제 8080 포트로 웹사이트 접속을 하면 된다~!!!

반응형

'SCM > Git-GitHub' 카테고리의 다른 글

git blame (-e 옵션)  (0) 2012.07.29
git man  (0) 2012.07.25
Code Review - Gerrit (Install)  (12) 2012.07.07
[004] 당신은 Git을 어떻게 읽나요?  (0) 2012.06.28
[003] Git의 탄생 비화  (2) 2012.06.26

Git을 사용하게 되면 따라오는 가장 유명한 도구들이 두 가지가 있다.
하나는 앞에서 살펴본 계정 관리를 위한 Gitolite,
다른 하나는 코드 리뷰를 위한 Gerrit 이다.

특징은 Gitolite, Gerrit 두 가지 모두 Git 전용의 도구들이다.

Google에서 사용하고 있는 코드 리뷰 도구라고 해서 Git의 인기와 함께 각광을 받고 있는 Gerrit !!!

"코드 리뷰" 도구 시장에는 아직 세상을 통일한 절대 막강 도구가 마땅히 없다.
야후에서 사용한다고 하여 유명한 "리뷰 보드(Review Board)"가 있지만, Git 지원은 아직 기본적인 수준이다.

현재 현장 분위기는 Git을 사용한다면 코드 리뷰는 당연히 Gerrit을 사용한다고 생각하고 있다.



이번 포스팅을 위해서 몇 일을 날려가며 엄청 고생을 했다.
아무리 생각해도 이런 빈약한 자료들을 가지고도 Gerrit을 셋팅해서 잘 사용하시는 분들은 전부 고수들인가보다.
범인 수준인 필자는 정말 엄청 개고생(?)을 해서야 겨우 Gerrit 화면을 볼 수 있었다.

하지만, 언제나 그렇지만 성공하고나서 보면... 별것도 아닌 수준이었는데....라는 생각이 든다 ^^



1. Ready

     - Gerrit을 사용하기 위해서는 다음의 조건이 필요하다.
          ▷ JDK          : version 1.6 이상
          ▷ Database  : Gerrit 내장 H2, 또는 MySQL, PostgreSQL

     - JDK 설치는 다음의 포스팅으로 따라하면 된다.
     - http://whatwant.tistory.com/438

     - Gerrit 자체도 두 가지 방식으로 다운로드 받을 수 있다.
          ▷ Binary  : Jenkins와 같이 *.war 파일로 다운로드 받을 수 있다.
          ▷ Source : 빌드하여 바이너리로 직접 만들 수 있다. Apache Maven으로 빌드할 수 있다.

     - 좋은건지 나쁜건지 모르겠지만, 버전업이 상당히 빠른 Gerrit이다.
     - 안전성을 올리기 위한 것이라면 그나마 괜찮은데, 기능적인 면까지 많이 바뀌는 버전업이라 부담스럽기도 하다.



2. Download

     - 굳이 빌드를 수행할 필요없이 *.war 파일로 다운로드 받자.



     - 포스팅을 하던 중에 업그레이드가 계속 되어 결국 스크린샷도 새로 만들어야 했다는... ^^



3. PostgreSQL

     - 이 블로그를 계속 봐오신 분들이라면 아시겠지만, 개인적으로 PostgreSQL을 사랑하는 것을 아실것이다!
     - postgresql이 설치되어있지 않은 경우엔, 그냥 [ sudo apt-get install postgresql ] 실행하면 된다.

     - Gerrit을 위한 PostgreSQL 계정과 db를 만들어줘야 한다.


$ sudo su - postgres

$ createuser -A -D -P -E gerrit2
$ createdb -E UTF-8 -O gerrit2 reviewdb

$ exit

     - 위와 같이 깔끔하게 끝~



4. Gerrit User

     - 참고로 Gerrit의 현재 버전은 version 2.4.1 이다. 그래서 그런지 Gerrit도 그냥 부르지 않고, Gerrit2 라고 한다.
     - Gerrit2를 위한 계정을 하나 만들고 그 계정에 모두 맞추자.


$ sudo adduser gerrit2
$ sudo chown gerrit2.gerrit2 ./gerrit-2.4.2.war
$ sudo su gerrit2


     - "gerrit2" 계정을 만들고 gerrit-2.4.1.war 파일을 해당 계정 소유로 만든 후 gerrit2 계정으로 su하자.




5. apache

     - 이번에는 웹서버로 apache로 셋팅을 해보겠다.
     - 나중에 시간이 잠시나면 꼭 nginx 환경에서 다시 해보도록 하겠다.

 

$ sudo apt-get install apache2


     - 설치를 했으면 확인을 하자.


     - Gerrit에서는 웹서버의 proxy 기능을 요구한다.

 

$ sudo apt-get install libapache2-mod-proxy-html


     - apache2의 proxy 모듈을 추가로 설치를 해주고,


$ sudo a2enmod proxy
$ sudo a2enmod proxy_http
$ sudo service apache2 restart


     - 웹서버 준비는 여기까지 끝~



6. Gerrit Install

     - 이제 준비 작업은 모두 끝났다. 설치를 진행하면 된다.

     - Gerrit의 기본적인 구성은 Jenkins와 같은 *.war 파일 구동방식이다.
     - 차이가 있다면, init 과정이 있다는 점 정도?!

 

$ sudo su gerrit2
$ cd /srv/install/gerrit


     - 설치과정을 진행하기 전에 권한을 맞추기 위한 선행 준비를 먼저 하자.


$ java -jar ./gerrit-2.4.2.war init -d /srv/workspace/gerrit


     - 위에서 명시한 디렉토리는 gerrit2 계정 권한으로 미리 만들어 두었다.

*** Gerrit Code Review 2.4.2
***

Create '/srv/workspace/gerrit' [Y/n]?  (Enter)

*** Git Repositories
***

Location of Git repositories   [git]: repositories

*** SQL Database
***

Database server type           [H2/?]: ?
       Supported options are:
         h2
         postgresql
         mysql
         jdbc
Database server type           [H2/?]: postgresql
Server hostname                [localhost]: (Enter)
Server port                    [(POSTGRESQL default)]: (Enter)
Database name                  [reviewdb]: (Enter)
Database username              [gerrit2]: (Enter)
gerrit2's password             : (passwd)
              confirm password : (passwd)


     - 이어서 계속 진행하자.


*** User Authentication
***

Authentication method          [OPENID/?]: ?
       Supported options are:
         openid
         http
         http_ldap
         client_ssl_cert_ldap
         ldap
         ldap_bind
         custom_extension
         development_become_any_account
Authentication method          [OPENID/?]: http
Get username from custom HTTP header [y/N]? (Enter)
SSO logout URL                 : (Enter)

*** Email Delivery
***

SMTP server hostname           [localhost]: smtp.gmail.com
SMTP server port               [(default)]: 587
SMTP encryption                [NONE/?]: (Enter)
SMTP username                  [gerrit2]:  @gmail.com
   @gmail.com's password  : (passwd)
              confirm password : (passwd)

*** Container Process
***

Run as                         [gerrit2]: (Enter)
Java runtime                   [/usr/local/java/jdk1.7.0_05/jre]: (Enter)
Copy gerrit.war to /srv/workspace/gerrit/bin/gerrit.war [Y/n]? (Enter)
Copying gerrit.war to /srv/workspace/gerrit/bin/gerrit.war


     - 인증 방식은 [ http ]로 정했다.
     - SMTP 설정은 gmail을 활용하기로 정했다. (이메일 주소는 살짝 지웠다 ^^ 다 알겠지만서도...)

 

*** SSH Daemon
***

Listen on address              [*]: (Enter)
Listen on port                 [29418]: (Enter)

Gerrit Code Review is not shipped with Bouncy Castle Crypto v144
  If available, Gerrit can take advantage of features
  in the library, but will also function without it.
Download and install it now [Y/n]?
Downloading http://www.bouncycastle.org/download/bcprov-jdk16-144.jar ... OK
Checksum bcprov-jdk16-144.jar OK
Generating SSH host key ... rsa... dsa... done

*** HTTP Daemon
***

Behind reverse proxy           [y/N]? (Enter)
Use SSL (https://)             [y/N]? (Enter)
Listen on address              [*]: (Enter)
Listen on port                 [8080]: (Enter)

Initialized /srv/workspace/gerrit
Executing /srv/workspace/gerrit/bin/gerrit.sh start
Starting Gerrit Code Review: OK
Waiting for server to start ... OK
Opening browser ...
No protocol specified


     - 나중에 설정 내용은 변경할 수 있으므로 최대한 기본값으로 정했다.

     - 그런데, 마지막 줄이 마음에 걸린다. [ No protocol specified ]




7. Configuration

     - 여기에서 바로 Gerrit이 실행되면 좋겠는데, 몇 가지 더 설정할 것들이 많다.

     - 앞에서도 언급을 했지만, 우리는 Apache의 Proxy를 활용하여 Gerrit을 띄울 것이다.
     - 그리고 Apache의 http authentication을 적용할 것이다.

     - 우선 관리자 계정 하나를 만들어 넣자.

$ sudo su gerrit2
$ htpasswd -c /srv/workspace/gerrit/etc/passwords "admin"


     - 앞의 설치 과정을 통해 만들어진 gerrit site 의 etc 디렉토리에 passwords 파일을 생성하는 것이다.
     - 앞으로 Gerrit 웹페이지는 이 파일을 이용하여 인증을 하게 된다.

     - Apache의 VirtualHost도 설정을 해주자.

$ sudo nano /etc/apache2/sites-available/gerrit2


<VirtualHost *:8081>
        ServerName localhost

        ProxyRequests Off
        ProxyVia Off
        ProxyPreserveHost On

        <Proxy *>
                Order deny,allow
                Allow from all
        </Proxy>

        <Location /login/>
                AuthType Basic
                AuthName "Gerrit Code Review"
                Require valid-user
                AuthUserFile /srv/workspace/gerrit/etc/passwords
        </Location>

        ProxyPass / http://127.0.0.1:8080/
</VirtualHost>


     - 위에서 각 포트가 중요한데, VirtualHost 에서는 8081 포트를 사용하고
     - Proxy에서는 8080 포트를 사용한다.

     - 추가로 sites-enabled 디렉토리에 동적링크도 만들어주자.

$ cd /etc/apache2/sites-enabled
$ sudo ln -s ../sites-available/gerrit2 ./001-gerrit2


     - 위와 같이 설정을 하였으면 Apache의 port 설정에도 추가해줘야 한다.

$ sudo nano /etc/apache2/ports.conf


NameVirtualHost *:8081
Listen 8081


     - 위와 같이 8081 포트에 대해서 설정을 추가로 적어주면 된다.

     - gerrit 의 설정값도 다시 한 번 살펴봐야 한다.

$ sudo su gerrit2
$ nano /srv/workspace/gerrit2/etc/gerrit.config


[gerrit]
        basePath = repositories
        canonicalWebUrl = http://localhost:8081/

[database]
        type = POSTGRESQL
        hostname = localhost
        database = reviewdb
        username = gerrit2

[auth]
        type = HTTP

[sendemail]
        smtpServer = smtp.gmail.com
        smtpServerPort = 587
        smtpUser =     @gmail.com

[container]
        user = gerrit2
        javaHome = /usr/local/java/jdk1.7.0_05/jre

[sshd]
        listenAddress = *:29418

[httpd]
        listenUrl = proxy-http://127.0.0.1:8080/

[cache]
        directory = cache


     - 위에서 빨간색으로 표시한 부분만 수정, 추가하면 된다.



8. restart

     - 재시작을 한 번 해보자.

$ sudo su gerrit2
$ cd /srv/workspace/gerrit/
$ ./bin/gerrit.sh restart


     - 이제 웹으로 확인을 해보자.


     - [ http://localhost:8081 ] 주소로 접속을 하면 위와 같이 이름과 암호를 물어본다.
     - 앞에서 "htpasswd"로 만든 계정을 이용해서 로그인하면 된다.


     - 드디어 길고 긴 과정을 거쳐서 gerrit의 화면이 나왔다.



9. Sign Out

     - 이렇게 설치를 했는데, 가장 원초적인 문제가 있다. 바로 [ Sign Out ]이 동작하지를 않는다.

     - 앞에서 [ gerrit.conf ] 파일을 수정할 때 넣은 [ canonicalWebUrl = http://localhost:8081/ ] 때문에 발생했다.
     - 하지만, 그 부분을 없애면 기본적인 동작도 하지 않는다.

     - 이 부분에 대한 해결책은 아직 찾지 못했다.
     - 찾게 되는 즉시 업데이트하도록 하겠다.

반응형

'SCM > Git-GitHub' 카테고리의 다른 글

git man  (0) 2012.07.25
Gitweb + Apache2  (2) 2012.07.16
[004] 당신은 Git을 어떻게 읽나요?  (0) 2012.06.28
[003] Git의 탄생 비화  (2) 2012.06.26
[002] 분산 버전 관리 시스템 (Distributed Version Control System, DVCS)  (0) 2012.06.25

Git의 발음

   - 기트
   - 깃
   - 지트
   - 짓


이와 관련된 공식입장이 있는데,
현재 사이트 접속이 안되어 확인이 안된다(예전에 봤는데 기억이 가물가물).
   - http://git.wiki.kernel.org/index.php/GitFaq#Why_the_.27git.27_name.3F
그런데, 위 위키 페이지는 사라졌다. 이런...


보통 일반적으로 "깃"이라고 발음하고 있다.
나도 그렇게 발음하고 있고,
현업에서 근무하고 있는 주위의 다른 사람들도 그렇게 발음하고 있다.
KLDP에서도 그렇게 의견이 수렴되었다.


최근에 결정적인 증거(?)도 찾았다!!
리누즈 토발즈 아저씨도 깃으로 발음을 하고 있다.

   - http://www.youtube.com/watch?v=4XpnKHJAok8


결론! "깃"이라고 발음하면 된다.

[ 참고 ]
http://kldp.org/node/113721
반응형

Git에 대해서 소개하는 글 중에서 가장 와닿는 내용이 있다.

'Linux Kernel'의 형상관리를 위해서 사용하는 도구이며
'리누스 투르발스(Linus Benedict Torvalds)'가 직접 만들고 있는 도구


그런데, 여기에서 궁금증이 생겼다.

Git의 역사가 Kernel에 비해서 훨씬 짧은데,
그 이전에는 뭘 사용했었지!?

CVS?! Subversion?!


그래서 알아봤는데,
다른 도구들과는 달리 이에 대해서
공식적인 입장은 물론이고
다양한 이야기를 확인할 수 있었다.


1999년도에 Linux Power PC에서 사용하기 시작한 'BitKeeper'는
리누스가 "Best Tool For The Job"라며
2002년도부터 Kernel의 mainline에 적용하였다.

2002년도 이후 Kernel 개발 속도가
엄청 증가한 배경에
BitKeeper가 기여했다는 점은
아무도 반론할 수 없을 것이다.

BitKeeper는 상용 제품이다.
다만, Linux Kernel을 위해서(도움도 받았으니)
Free 버전을 계속 개발 해주고 있었다.

하지만, 오픈소스 진영의 대표주자격인 Kernel에서
상용 제품을 사용하는 것에 대한 비판이 많았던 것 같다.

하지만, 분산 개발을 제대로 지원하는
Linux Kernel 개발에 적합한 다른 대안 도구가
없었기에 그대로 사용할 수 밖에 없었다.

그러던 중, BitKeeper에 대한 Reverse-Engineer 시도가 있었고
경고를 했음에도 두 번 더 발각(?) 되면서
BitKeeper의 무료 버전 개발이 중단 되게 된다.

이 부분에 대해서 많은 이야기가 오가는데...
결론적으로

BitKeeper의 입장에서는
매년 $50,000 정도씩을 투자해서
Free로 제공해주고 있는데
그런 우리의 제품을 reverse engineer를 해서
기술을 빼가다니 너네 괘씸해!
이제 안줘!!!

오픈소스 커뮤니티 입장에서는
Free로 풀린거면 자유롭게 쓸 수 있는거지
왜 시비야~!!

하지만, BitKeeper 입장에서는
돈 안받고 쓸 수 있게 해준거지,
너네 맘대로 손대라고 한 것이 아니야~!!!

뭐 이렇게 정리가 되는 것 같다.



이렇게 되어 BitKeeper가 아닌
대안을 찾아야 하는 상황이 되었는데..

마땅한 대안이 없자,
직접 만들어 버리게 된다.

그것이 바로 Git 이다!!!



그것도 '리누스'아저씨가 주도하여
개발을 하다니...



그 유명한 '리누스' 아저씨가 개발을 하고,
운영체제의 양대 산맥 중 하나인
리눅스 커널을 개발하는데 사용중인 도구이며,

최근 모바일의 가장 뜨거운 핫이슈인
구글의 안드로이드도 사용하는 도구!!!

바로,
"GIt"
이다.


[ 참고 ]
http://en.wikipedia.org/wiki/Git_(software)
http://kerneltrap.org/node/4966
http://www.pcworld.idg.com.au/article/129776/after_controversy_torvalds_begins_work_git_/
반응형

'Git'이라는 '버전 관리 도구'를 언급하면 바로 따라오는 말이 있다.

- 리누스 투르발스 (Linus Benedict Torvalds, 위키피디아 기준 발음)
- 리눅스 커널 (Linux Kernel)
- 안드로이드 (Android)
- 분산 버전 관리 시스템 (Distributed Version Control System, DVCS)



다른 것들은 다음에 기회가 있으면 이야기하도록 하고,
여기에서는 '분산 버전 관리 시스템'에 대해서만 이야기를 해보고자 한다.



소프트웨어 형상관리의 흐름을 살펴보면,

로컬에서 파일시스템 기반으로 형상관리를 하다가,
네트워크 기반의 중앙집중식으로 관리를 하고,
최근에는 분산형 관리가 유행이다.



도구로 따지면,
'버전 관리 도구'의 고전작품인 'CVS'
'버전 관리 도구'의 대중화를 이끈 'Subversion'

이들과 'Git'이 차별점을 보여주는 부분이 바로 '분산 (Distribute)'이다.





컴퓨터 세상은 우리가 살아가는 사람들의 세상과 밀접하다.

C++을 통해서 우리에게 알려진 객체지향(Object-Oriented)이라는 것도
컴퓨터 언어에만 있는 것이 아니라
세상을 바라보는 관점에 대한 철학의 산물인 것처럼

분산 처리라는 것도 신경망 모델 중 하나로 개념화되어
일반적으로 부하가 걸리는 것을 해결하기 위한 방안으로
나누어 처리하는 것을 의미하는 아주 대중화된 방법이다.

말단 처리 장치의 능력이 좋아지고
네트워크가 잘 이루어진 상황에서는
당연한 수순으로 집중처리에서 분산처리로 변화하게 되는 것이다.





'CVS'와 'Subversion'과 같은 기존의 '중앙 집중식 버전 관리 도구'
'서버-클라이언트 (Server-Client)' 구조를 따른다.

'서버'를 구축해 놓고 사용자는 '클라이언트'로 붙어서 작업을 하는 방식이다.

이러한 구조에서 발생하는 문제 중에서 가장 큰 것은
'서버'가 없으면 '클라이언트'는 작업을 할 수 없다는 점이다.

다른 문제로는 '중앙 집중식 버전 관리 도구'의 장점이자 단점인데,
시스템을 구성하는데 단순하고 쉽게 할 수 있는 반면에
다양한 '워크 플로우(Work Flow)'를 구현하는데에 한계가 있을 수 밖에 없다.

실제 현업에서 이러한 '중앙 집중식 버전 관리 시스템'을 사용할 때
피부에 와닿는 문제는 협업을 할 때에 있었다.
특히 해외 연구소들... 더욱 더 특히 인도와 같이 느린 네트웍...




'중앙 집중식 버전 관리 시스템'의 경우를 예를 들어보자,
서버를 구축하는 것도 쉽고 시스템을 구성하는 것도 쉽고
한 곳에 모여서 열심히 작업을 할 때에는 아무런 문제도 없다.

그러던 중 해외의 연구소와 협업을 하게 되면서 문제가 발생한다.

그냥 기존과 같이 새로 계정 발급해주고 국내 서버에 붙어서
협업을 하게 하는데 해외쪽의 네트웍 속도가 느려서
제대로 check-out/in이 되지 않는 경우가 발생하는 것이다.

즉, 소스를 다운 받는데 네트웍이 느리다보니 종종 실패를 하게 되고,
더 큰 문제는 작업한 내용을 서버로 올릴 때 실패를 하는 경우이다.

실패를 하는 것은 그나마 나은 경우이고,
에러가 없었는데 파일 일부를 누락하게 되면 정말 괴롭게 된다.

이 모든 원인은 느린 네트웍 속도.

특히 관리하는 소스 코드의 용량이 클 경우에는
추가적인 더더욱 심각한 문제가 발생하게 된다.


이를 극복하기 위한 흔한 방법은
'프록시 서버(Proxy Server)'를 원격지 가까운 곳에 두는 것이다.

그리고는 메인 서버와 '동기화(Synchronization)'를 하도록 하면 된다.

보통은 이와 같은 방법으로 이와 같은 상황을 해결하지만,
동기화 과정에서 많은 문제가 발생하는 것을 완전히 피할 수는 없다.



이러한 것을 극복하기 위한 것이 바로
"분산 버전 관리"이다!

서버에서 check-out을 하게 되면
서버와 똑같은 내용을 전부 클라이언트가 갖게 된다.
즉, 클라이언트가 서버가 될 수 있는 것이다.

'로컬(local)'에 서버 복사본을 구축해버리면,
서버와 연결되지 않아도 혼자서 commit을 할 수 있다.

필요할 때에 필요한 내용만 서버로 보낼 수가 있다.

'프록시 서버'와 유사하면서도 또 다른 구성이다.

"Git"과 같은 "분산 버전 관리 도구"에서
기본적으로 손쉽게 '복사본(clone)'을 구축할 수 있게 함으로써
정말 다양한 '워크 플로우'를 구축할 수 있게 되었다.

정말 유연한 시스템을 구축할 수 있도록 도와주는 것인데,
이러한 유연성이 부담스러울 경우에는
기존 방식과 같은 타이트한 워크 플로우를 구성할 수도 있다.

비록 "Git"이 지향하는 '분산 버전 관리'의 모습은
'병렬 분산 처리 (Parallel Distributed Processing, PDP)'이지만,
사용자가 원하는 워크 플로우를 구성할 수 있다는 점이 중요하다.




'Git'의 명령어들을 공부하는 것도 중요하지만,
더욱 중요한 것은 'Git'을 이용하여 어떻게 작업을 할 것인지에 대해서이다.

'C언어'를 공부하는 것과 마찬가지인 것이다.
문법을 모두 공부했다고 해서 끝나는 것이 아니고
어떻게 프로그램을 만들 것인지에 대해서 공부해야하는 것처럼 말이다.


실제로 'Git'으로 이를 어떻게 사용할 수 있는지는
앞으로 차차 살펴보도록 하자.



[ 참조 ]
리누스 투르발스 - http://ko.wikipedia.org/wiki/%EB%A6%AC%EB%88%84%EC%8A%A4_%ED%86%A0%EB%B0%9C%EC%A6%88
분산 버전 관리 - http://ko.wikipedia.org/wiki/%EB%B6%84%EC%82%B0_%EB%B2%84%EC%A0%84_%EA%B4%80%EB%A6%AC_%EC%8B%9C%EC%8A%A4%ED%85%9C
인지과학 - http://terms.naver.com/entry.nhn?docId=8403
분산 버전 제어 시스템 소개 - http://www.ibm.com/developerworks/kr/library/au-dist_ver_control/
Reversion Control System - http://en.wikipedia.org/wiki/Revision_control_software
반응형

[ 한글 ]
형상 관리 (소프트웨어 형상 관리)
버전 관리 (소프트웨어 버전 관리)
소스 관리 (소스 코드 관리)


[ 영어 ]
Version Control
Revision Control
Source Control
Source Code Management (SCM)
Software Version Management
Software Configuration Management (SCM)




Subversion, Git, ClearCase 등과 같은 도구를 통해서 (또는 도구가 없더라도)
소스 코드, 문서, 결과물 등을 번호(버전)를 사용하여
관리하는 것을 무엇이라고 지칭해야 할까?



소프트웨어 공학(Software Engineering)이라는 학문은
개인적으로 '공학계의 인문학'이라고 여겨진다.

바꿔말하면 무엇을 정의하는 것이 어려우며,
정답이 없는 경우가 대부분이라는 말이다.



최근 아이폰이나 안드로이드로 인하여
대중화 되어버린 "플랫폼(Platform)"이라는 것을 보아도
분야마다 사람마다 그 정의가 전부 다를 수밖에 없다.

시험 문제로 "플랫폼의 정의를 쓰시오"라고
나오면 정말 당황스러울 것 같다.



이번의 경우는 조금은 색다른 경우인데,
이것을 지칭하는 용어가 너무 많아서 문제가 된다.

같은 것을 지칭하면서
다들 다른 용어를 사용하고 있는 것이다.



일반적으로는
Subversion, Git 과 같은 것을 지칭할 때에는
"버전 관리 도구 (Version Control Tool)"
라고 한다.

그러한 버전 관리 도구를 사용하여 구축한 시스템은
"버전 관리 시스템 (Version Control System, VCS)"
이라고 부르곤 한다.



소프트웨어 공학을 공부하다 보면
상당 부분의 개념이 산업 공학 특히 생산 공학에
그 기반을 두고 있는 것을 알 수 있다.

그로 인하여, 버전 관리를 포괄하는 다른 용어가 나오는데
"형상 관리 (Configuration Management)"
가 그것이다.


그 중에서 소프트웨어 분야에 대해서는
"소프트웨어 형상 관리 (Software Configuration Management, SCM)"
라고 부르고 있다.



'소프트웨어 형상 관리'는
'버전 관리'를 포함하는 더 크게 포괄하는 의미다.

'소프트웨어 생명 주기 (Software Life Cycle)' 전반에 걸쳐서
개발 환경을 비롯한 전반적인 모든  형상물들에 대한
'변경 관리'를 위한 모든 활동을 의미한다.


형상 식별, 버전 제어, 변경 제어, 형상 감사, 형상 상태 보고 등
어려운 말로 소프트웨어 형상 관리에 대한 정의들이 있긴 하다.



어려운 이야기를 계속 하고자 하는 것은 아니다.

다만, '소프트웨어 형상 관리'라는 것이
곧 '소프트웨어 버전 관리'를 의미하는 것은 아니라는
말을 하고 싶은 것이다.

'소프트웨어 형상 관리'의 범주 안에
'소프트웨어 버전 관리'가 포함이 되어 있을 뿐이다.



문제는 이러한 것을 실무자들도 분명히 알고 있으면서도
아니, 최소한 어렴풋하게 알고 있으면서도
이 두 가지 용어를 그냥 동의어로 사용하고 있다.

또 사실 동의어로 사용해버린다고 하여
꼭 틀렸다고 할 수 없는 것도 사실이다.
( 우기면 뭐 그렇다고 할 수 밖에 없는 것이 현실! )


단순히 소스 코드에 대해서만 관리한다고 하면
"버전 관리"
소스 코드를 비롯하여 개발 환경, 빌드, 기타 등등까지라면
"형상 관리"
라고 지칭하기로 하자.


우리가 앞으로 계속 살펴볼 "Git"은
기본적으로 "버전 관리 도구"이다!


하지만, Git을 기반으로 하여 소프트웨어를 관리하는 시스템을 만든다면
그것은
"소프트웨어 형상 관리 시스템"
이라고 부르기로 하자.


[ 참고 ]
http://ko.wikipedia.org/wiki/%EB%B2%84%EC%A0%84_%EA%B4%80%EB%A6%AC
http://ko.wikipedia.org/wiki/%ED%98%95%EC%83%81_%EA%B4%80%EB%A6%AC
정보통신단체 표준, TTA.IE-828, 소프트웨어 형상 관리 계획 표준
반응형

+ Recent posts