우연의 기회로 Gerrit 환경을 구축하게 되었습니다.

구축하게 되면서, 정리한 내용이니 참고하시길 바랍니다.

설치 환경

  1. JDK 1.7 이상 버전 설치
  2. Open SSH Server 설치
  3. Apache 설치
  4. Ubuntu 16.04 Version 설치

Gerrit Site

  1. Release Site : https://gerrit-releases.storage.googleapis.com/index.html
  2. English Helper Site : https://gerrit-documentation.storage.googleapis.com/Documentation/2.12/install.html
  3. 참고 Site
    1. http://pseg.or.kr/pseg/infoinstall/1815
    2. https://d2.naver.com/helloworld/6236097
    3. https://www.hiroom2.com/2018/05/24/ubuntu-1804-gerrit-en/
    4. http://lazyrodi.github.io/2016/08/14/2016-08-14-etc-gerrit-installation/

Apache2

$ sudo apt-get install apache2

$ sudo apt-get install libapache2-mod-proxy-html (있으면 설치. 없으면 안해도 됨)

$ sudo apt-get install apache2-utils

$ sudo a2enmod proxy

$ sudo a2enmod proxy_http

$ sudo service apache2 restart

Open SSH Server

$ sudo apt-get install openssh-server

Git

$ sudo apt-get install git

Gerrit

  1. Web site 에서 Gerrit Download (3.1.4)
    1. Release Site : https://gerrit-releases.storage.googleapis.com/index.html
  2. Gerrit 다운로드 한 gerrit-3.1.4.war 파일 설치
    1. $ java -jar gerrit-3.1.4.war init -d ~/opt/gerrit
    2. a의 명령어 입력 후, 다음의 환경 설정 참고하여 입력
  3. Gerrit 검색 엔지 리빌드
    1. $ java -jar gerrit-3.1.4.war reindex -d ~/opt/gerrit
  4. Gerrit 실행
    1. $ cd ~/opt/gerrit/bin
    2. $ ./gerrit.sh start
  5. Apache Proxy 설정
    1. VirtualHost 파일 생성 (Apache VirtualHost File 참고)
      1. $ sudo vim /etc/apache2/sites-available/gerrit.conf
    2. Site Enabled 설정
      1. $ cd /etc/apache2/sites-enabled
      2. $ sudo ln -s ../sites-available/gerrit.conf ./001-gerrit.conf
      3. $ sudo a2ensite 001-gerrit.conf
    3. 기본 설정 파일의 Port 변경
      1. $ sudo vim /etc/apache2/sites-available/000-default.conf
      2. <VirtualHost *:80> 에서 <VirtualHost *:10080>으로 변경.

Apache VirtualHost File

<VirtualHost *:80>
    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 /home/csjung/opt/gerrit/etc/passwords
    </Location>
    ProxyPass / http://127.0.0.1:8081/
    ProxyPassReverse / http://127.0.0.1:8081/
</VirtualHost>

 

Gerrit 환경설정


Location of Git repositories   [git]: /home/gerrit/repository/

 : 저장소 설정

   아무런 내용을 기입하지 않다면, 기본 저장소로 설정 됨.


Index Type [lucene]

 : 보조 검색 도구

   기본을 사용하면 됨.


*** User Authentication

***

 

Authentication method          [OPENID/?]: http  

Get username from custom HTTP header [y/N]?  

SSO logout URL                 :  http://aa:aa@127.0.0.1:80/login/

 : 사용자 인증 기능

   Gerrit 은 사용자 인증 기능을 제공하지 않는다.

   OpenID와 LDAP(Lightweight Directory Access Protocol), Site Minder 등 외부 인증 시스템 연동을 지원.

   SSO Layout 을 지정 해 주어야 함. 

   -> http://aa:aa@{IP Address}:{Port}/login/

   -> aa:aa 는 문자 그대로 입력해도 됨.

   Custom Header 는 기본을 사용할 시 N을 해주어야 함.


*** Review Labels

***

Install Verified label         [y/N]? y  

 : 검증 레이블

   Gerrit 기본 프로젝트인 All-project의 project.config 파일에 [label "Verified"]와 같이 검증 레이블 섹션을 추가


*** Email Delivery

***

SMTP server hostname           [localhost]:  smtp.gmail.com

SMTP server port               [(default)]:  465

SMTP encryption                [NONE/?]:  SSL

SMTP username                  :  XXX@gmail.com

 : E-Mail 알림 서비스 등록 (원하는 Email 도메인 계정으로 등록하면 됨)


*** Container Process

***

 

Run as                         [gerrit]:  

Java runtime                   

[/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71.x86_64/jre]:  

Copy gerrit-2.9.1.war to /home/gerrit/apps/gerrit/bin/gerrit.war [Y/n]?  

Copying gerrit-2.9.1.war to /home/gerrit/apps/gerrit/bin/gerrit.war  

 : 시스템에 설치된 Java Version을 확인하는 부분

   Gerrit 패키지 파일인 WAR 파일을 복사할 것인지 묻는 질문에는 Enter 키를 누르거나 Y를 입력해 패키지 파일을 Gerrit 설치 디렉터리로 복사


*** SSH Daemon

***

 

Listen on address              [*]:  

Listen on port                 [29418]:

 

Gerrit Code Review is not shipped with Bouncy Castle Crypto SSL 

v149  

  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/bcpkix-jdk15on-149.jar ... OK  

Checksum bcpkix-jdk15on-149.jar OK

 

Gerrit Code Review is not shipped with Bouncy Castle Crypto Provider 

v149  

** This library is required by Bouncy Castle Crypto SSL v149. **

Download and install it now [Y/n]?  

Downloading 

http://www.bouncycastle.org/download/bcprov-jdk15on-149.jar ... OK  

Checksum bcprov-jdk15on-149.jar OK  

Generating SSH host key ... rsa... dsa… done

 : SSH Daemon Service 의 기본 설정


*** HTTP Daemon

***

 

Behind reverse proxy           [y/N]?  

Use SSL (https://)             [y/N]?  

Listen on address              [*]:  

Listen on port                 [8080]:  

Canonical URL                  [http://localhost:8080/]:  

 : HTTP 데몬 설정


*** Plugins

***

 

Install plugin commit-message-length-validator version v2.9.1 [y/N]? n  

Install plugin download-commands version v2.9.1 [y/N]? n  

Install plugin replication version v2.9.1 [y/N]? n  

Install plugin reviewnotes version v2.9.1 [y/N]? n  

Install plugin singleusergroup version v2.9.1 [y/N]? n

 : 설치 패키지를 미리 설치 할 지 문는 부분

Gerrit 환경 설정 정보 파일 (gerrit.config)

[gerrit]
    basePath = /home/csjung/repository/
    canonicalWebUrl = http://127.0.0.1/
    serverId = bcf3d6b4-bc5b-46d5-8594-8bf9e3ec9ed0
[container]
    javaOptions = "-Dflogger.backend_factory=com.google.common.flogger.backend.log4j.Log4jBackendFactory#getInstance"
    javaOptions = "-Dflogger.logging_context=com.google.gerrit.server.logging.LoggingContext#getInstance"
    user = csjung
    javaHome = /usr/lib/jvm/java-11-openjdk-amd64
[index]
    type = lucene
[auth]
    type = HTTP
    logoutUrl = http://aa:aa@127.0.0.1:80/login/
[receive]
    enableSignedPush = false
[sendemail]
    smtpServer = smtp.gmail.com
    smtpServerPort = 465
    smtpEncryption = SSL
    smtpUser = ****@gmail.com
[sshd]
    listenAddress = *:29418
[httpd]
    listenUrl = proxy-http://127.0.0.1:8081/
[cache]
    directory = cache

 

Gerrit 사용자 등록

  1. 관리자 계정 생성 
    $ htpasswd -c /home/gerrit/opt/gerrit/etc/passwords “admin”
    passwords파일을 처음 생성할 때에만 -c 옵션을 사용하며 이후 다른 계정을 추가할 때에는 그냥 아래와 같이 추가한다.
    $ htpasswd /home/gerrit/opt/gerrit/etc/passwords “usera”
  2. Apache 재시작 및 Gerrit 재시작
    $ sudo service apache2 restart
    $ cd ~/opt/gerrit/bin
    $ ./gerrit.sh restart

기타

  1. Gerrit 설치 성공 시, 생성되는 파일들
    etc/gerrit.config : Gerrit 설정 정보
    etc/secure.config : Password 와 같은 정보
  2. Error 발생 시, 로그 출력 위치
    logs/error_log : Gerrit Error Log File

참고

  1. Google Mail 연동 시, 인증 에러가 날 경우.
    -> Google My Account 로 가서 "보안" > "보안 수준이 낮은 앱의 액세스" 활성화 하면 됨.

'기타' 카테고리의 다른 글

넥서스 S 바이너리 올리기  (0) 2012.11.25
[Hudson] 자동 빌드 설정 방법  (0) 2012.08.10
VPN  (0) 2011.05.03
SVN GUI TOOL[SVN Tool - RapidSVN 사용법]  (0) 2011.02.09
SVN  (0) 2011.02.09

Nexus 7에 대해 빌드하는 방법에 대해 정리를 해보았습니다.


그리고 WiFi 전용 모델 입니다.


우선 환경은 Ubuntu 12.04 64bit 환경 입니다.


1. 작업 디렉터리 설정하기

  ~$mkdir Android_Nexus

  ~$mkdir Android_Nexus/bin

  ~$mkdir Android_Nexus/src


 2.필수 패키지 설치

 ~/Andorid_Nexus$sudo apt-get update // Package 최신으로 Update

 ~/Andorid_Nexus$sudo apt-get upgrade // 최신 Package 설치

 ~/Andorid_Nexus$sudo apt-get install git-core gnupg flex bison gperf build-essential zip curl libc6-dev libncurses5-dev:i386 x11proto-core-dev libx11-dev:i386 libreadline6-dev:i386 libgl1-mesa-dev:i386 g++-multilib mingw32 openjdk-6-jdk tofrodos python-markdown libxml2-utils xsltproc zlib1g-dev:i386


 ~/Andorid_Nexus$sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib/i386-linux-gnu/libGL.so


3.JDK 6 설치

  ~/Andorid_Nexus$wget https://raw.github.com/flexiondotorg/oab-java6/master/oab-java.sh


 ~/Andorid_Nexus$chmod a+x oab-java.sh

 ~/Andorid_Nexus$sudo ./oab-java.sh

 ~/Andorid_Nexus$sudo apt-get install sun-java6-jdk

 ~/Andorid_Nexus$sudo update-alternatives --config java


4.Android 4.2 Source Download

 ~/Andorid_Nexus$curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ./bin/repo


 ~/Andorid_Nexus$chmod u+x ./bin/repo


 ~/Andorid_Nexus$gedit ~/.bashrc


[내용 입력]

 - export PATH=${PATH}:~/Andorid_Nexus/src/out/host/linux-x86/bin
   export ANDROID_PRODUCT_OUT=~/Andorid_Nexus/src/out/target/product/grouper


 ~/Andorid_Nexus$source ~/.bashrc


 ~/Andorid_Nexus$cd src

 ~/Andorid_Nexus/src$repo init -u https://android.googlesource.com/platform/manifest -b android-4.2_r1

 ~/Andorid_Nexus/src$repo sync


5. Android 4.2 Binary Driver Download

   https://developers.google.com/android/nexus/drivers#grouperjop40c 로 접속 후,

   해당 드라이버 바이너리들을 Android_Nexus/src/안에 저장.

 

Nexus 7 (Wi-Fi) binaries for Android 4.2 (JOP40C)

Hardware Component Company Download MD5 Checksum SHA-1 Checksum
Wi-Fi, Bluetooth, GPS Broadcom Link 2860929996827f53d38e5432c9dc7dc7 40b15ad807e1cbddca36fd64f60691cc8d621c07
Touch Panel ELAN Link 6c2b4c4f5301c25ff6982b909ba838f1 1de7a664e4bf53a5427e31363ae9024c762ab20f
Orientation Sensor Invensense Link d31fdd0513cf91fbc8aebd8a0a8205f2 95a5a4b2d35bfcdb4ec5f88487f41bef75d04757
Graphics NVIDIA Link bc8c6e082925f642562688b2abebf617 38383f75dfa5fd1573a8b6501940af848b983a2b
NFC NXP Link 436654fa7b2d688f6b332dcf0d053eed b006a2f1e828af068a6c48a8af87b05dd27ab28b
DRM Widevine/Google Link fc4acdc2ccb17b8e9abd8c14957eab49 2916b2ab791fcc07f1a53802e02860136354ae36


위와 같이 다 받았다면, 아래의 명령어 들을 실행합니다.

~/Andorid_Nexus/src$for i in *.tgz; do tar -xvzf "./$i"; done


위의 명령어를 실행하였으면 sh 파일들이 생성되는 것을 확인할 수 있습니다.


여기서 해당 파일들을 하나씩 터미널로 실행시킵니다.


그러면 라이센스가 나오게 되는데 이때, 라이센스틑 반드시 다 읽고 마지막에 "I AGREEDED" [확실치 않음.] 라고 입력해 주고 엔터를 입력해야 정상적으로 바이너리가 설치가 됩니다.


이런 방식으로 나머지 드라이버 바이너리 sh 파일들을 실행시켜 줍니다.


6. Build.

~/Andorid_Nexus/src$source build/envsetup.sh

~/Andorid_Nexus/src$lunch

    lunch 명령을 입력하면 빌드할 명령어를 적어달라고 합니다.

    여기서 엔지니어로 처리하고 싶으면, 출력된 예제대로 출력해주면 되고,

    저는 grouper 빌드 방법에서 userdebug가 아닌 eng로 변경하여 설정하였습니다.

~/Andorid_Nexus/src$make -j4

   여기서 -j4라는 옵션은 Thread를 4개 돌린다는 말로 만약 듀얼코어이면 -j2 이런식으로 처리하면
   됩니다.


7. udev 설치.

~/Andorid_Nexus/src$sudo bash

~/Andorid_Nexus/src#echo SUBSYSTEM==\"USB\", ATTR{idVendor}==\"04e8\", MODE=\"0666\", GROUP=\"plugdev\" >> /etc/udev/rules.d/90-android.rules


~/Andorid_Nexus/src#chmod a+r /etc/udev/rules.d/90-android.rules

~/Andorid_Nexus/src#service udev restart


8. 바이너리 올리기

~/Andorid_Nexus/src$ sudo bash

~/Andorid_Nexus/src#adb reboot bootloader

[기기 upload 모드로 변환]


~/Andorid_Nexus/src#fastboot oem unlock

~/Andorid_Nexus/src#fastboot erase cache

~/Andorid_Nexus/src#fastboot erase userdata

~/Andorid_Nexus/src#fastboot flashall

여기서 flashall은 환경 변수에서 설정한 ANDROID_PRODUCT_OUT의 경로를 통해서 자동으로 image 파일들을 추출 후 연결된 기기로 자동으로 업로드 해주는 명령어 입니다.


[Fastboot 관련 명령어 참고 : http://www.androidpub.com/3633]


위와 같은 작업을 함으로써 정상적으로 바이너리가 올라가는 것을 확인하였습니다.


===================================================================================

Google Apps를 올리는 방법


1. [전제조건 : 루팅이 되어 있어야 함.]

     우선 gapps를 검색하여 다운로드 받습니다.

     [http://goo.im/devs/KonstantinKeller/mako/gapps/gapps-4.2-JOP40C-121116.zip]

     다운로드 받았으면, gapps를 기기의 sdcard에 다운로드 받습니다.

   

     adb shell 상에서 unzip 명령을 사용하기 위해서는 다음의 파일을 다운로드 받아서 설치합니다.

     [busybox.tar]

     설치 방법은 다음과 같습니다.

     1) 위의 파일을 컴퓨터에 다운 받습니다. 그리고 터미널을 이용하여 다운받은 위치로 이동 후 다음과

          같은 명령어로 압축을 풀어줍니다.

          tar -xvf busybox.tar

     2) adb remount 란 명령어를 이용하여 기기를 remount 시켜줍니다.

          그리고 해당 파일을  adb push를 이용하여 /data/busybox 란 위치에 올려줍니다.

          adb push busybox /data/busybox

     3) adb shell 명령어를 이용하여 기기의 shell로 접속 합니다.

     4) 업로드한 busybox 위치로 이동합니다.

          cd /data/busybox

     5) 해당 경로로 이동하였다면, 다음과 같이 명령어를 입력하여 설치합니다.

         chmod 777 busybox

         ./busybox --install -s /data/busybox

         export PATH=/data/busybox:$PATH

      6) 위와 같이 처리하였다면, unzip 명령이 먹힐 것입니다.


     여기까지 작업을 하였다면, 이 전에 기기에 올린 gapps의 zip 파일을 다음의 명령어를 통해서
    설치합니다.

     ./unzip -o /sdcard/gapps-4.2-JOP40C-121116.zip -x "META-INF*" -d /

    위의 명령어를 통해서 설치를 완료하였다면, 기기를 재부팅 합니다.

   그러면 셋업 위자드가 뜨면서 Google App 들이 설치되어 있는 것을 확인 할 수 있습니다.

 

  2. [빌드시 적용 방법.]

      아래의 주소는 어렵게 구한 Gapps가 존재하는 소스 입니다.

      [넥서스 7 Wifi (구글 apk 및 기타 apk들 포함.):
                     https://github.com/rpcraig/grouper_gapps/downloads]

      [구글 apk :
                     https://github.com/rpcraig/android_vendor_google_gapps]

      일단 넥서스 7 WIFI에 포함된 Google Apps 및 깉타 앱들이 포함된 소스를 빌드하는 방법을

     설명해드리겠습니다.

     우선은 위의 소스를 전달 받게 되시면 아래와 같이 몇가지 작업을 하셔야 합니다.


     1. 먼저 위에서 풀소스 및 드라이버 바이너리를 다운받아서 설치를 했기 때문에 전달 받은 파일들의

          mk 파일에서 수정을 해야 합니다.


         수정 내역은 다음과 같습니다.

         1. vendor/asus/grouper/bin/Android.mk 파일에서 glgps 파트 주석 처리.
         2. vendor/asus/grouper/lib/Android.mk 파일에서 gps.tegra3 파트 주석 처리.
         3. vendor/asus/grouper/vendor/Android.mk 파일에서 libpn544_fw 파트 주석 처리.


         위와 같이 수정을 하였다면, 이제 두번째 작업을 시작해야 합니다.

         우선 인터넷에서 gapps-4.2-JOP40C-121116.zip 명으로 검색하여 파일을 다운로드 합니다.

         다운이 완료되면 다운 받은 파일과 방금 다운 받은 넥서스 7 Wifi (구글 apk 및 기타 apk들 포함.)
         압축파일 들을 압축 해제 합니다.


        압축을 풀었다면, 이제 gapps-4.2-JOP40C-121116의 파일들을 잘라내서 그대로 넥서스 7 Wifi
        (구글 apk 및 기타 apk들 포함.)를 압축 푼 폴더에 붙여넣기 합니다.

        이는 인터넷에서 받은 버전은 허니컴버전이기 때문에 App 실행에 있어서 원활하게 실행을 할 수
        가 없다.

        복사가 완료되었다면, 이제  Android 폴더에서 vendor/asus/grouper/에 복사합니다.

        예제)

    


      그리고 빌드를 돌려주시면 됩니다.


     만약 넥서스 7 이 아닌 구글 apk만 설치하겠다면, vendor폴더에서 google이라는 폴더를 생성 후

    그 안에 넣어서 빌드를 돌려주면 됩니다.

    감사합니다.


   




출처 : http://thdev.net/259

Source Build 방법 : http://source.android.com/source/downloading.html

Binary Driver : https://developers.google.com/android/nexus/drivers#grouperjop40c

Build Command : http://yatoyato.tistory.com/25

갤럭시 넥서스의 Factory Images를 이용하여 복원하는 방법을 설명하려고 합니다. 롬을 설치하고, 갑자기 부팅이 되지 않고, 부팅 로고가 멈추거나 하는 경우에는 해당 롬을 다시 올리면 되겠지만, AS를 가야 하거나, 정식버전의 롬이 출시되거나 하는 등의 경우에는 롬을 Factory Images를 이용하여 완전히 복원하는 방법을 사용하시면 좋을 듯 합니다.

 인터넷 검색을 해보면 많은 정보가 있습니다. 그런데 구글에서 직접 .sh 파일을 만들어서 쉽게 롬을 변경할 수 있게 해두었습니다. 그러니 명령어를 직접 입력하지 않아도 되고, 간단한 명령 입력만으로 공장 초기화로 돌릴 수 있습니다.

 그리고 저는 루팅을하고, 롬을 변경할 때 CWM 을 설치하지 않았습니다. 설치하지 않은 이유는 가끔 이용할 프로그램을 굳이 롬에 넣어둘 필요성을 못느꼈기 때문입니다. 만약 CWM을 설치하셨다면 검색을 하셔서 CWM 삭제하는 방법을 찾아보셔야 합니다.


필수 사항

 당연히 UNLOCK 상태이어야 합니다. LOCK 상태라면 아래 글을 먼저 참고하세요(아래 SDK 설치 USB 설치는 이 글을 읽어보시면 됩니다.) 아래 글로 가셔서 UNLOCK 까지만 하시면 됩니다. SUPER Path는 하지 않으셔도 됩니다.

  http://thdev.net/170


Android sdk를 다운 받아 준비해야 합니다. sdk는 아래 사이트로 접속하여 다운 받을 수 있습니다.

   http://developer.android.com/sdk/index.html

   Nexus S 윈도우 XP 드라이브 링크 : http://db.tt/1Pl7vHfg

더보기


갤럭시 넥서스, Nexus S 드라이브가 설치되어야 합니다.

Nexus S의 경우

 설치가 완료되었습니다. 이제 휴대폰을 재부팅하고, 안드로이드 root 권환을 획득하면 됩니다. 그전에 윈도우에서 USB드라이브를 잡아주셔야 합니다. 

 윈도우에서만 드라이브 잡아주시면 되니 아래글을 참고해 주세요.

더보기


갤럭시 넥서스

 갤럭시 넥서스의 경우 삼성에서 제공하는 Driver를 설치해주시면 됩니다.


 Factory Images를 다운 받습니다.

  http://bit.thdev.net/OQRoqD


참고 : sdk 설치가 어렵다고 하시는 분은 아래 파일만 다운 받으시면 됩니다. Android sdk 설치시에 나오는 플렛폼 툴 폴더를 압축해서 올려드립니다.

  http://db.tt/rDBA3oeY (C:\ 아래에 압축을 푸시는게 cmd에서 접근하기 가장 편합니다.)

Nexus S의 경우 USB 드라이브 설치가 안되어 있으시면 아래 드라이브를 다운 받으시면 됩니다.

  http://db.tt/zCd1EEDe


Factory Images 다운로드

 Factory Images 다운로드 홈페이지

   http://bit.thdev.net/OQRoqD

 구글에서 오픈 소스로 정식 운영하는 사이트입니다. 해당 사이트에 접속하면 아래와 같이 Factory Images를 다운 받을 수 있습니다. 그런데 코드명이 소주, 약주, 탁주 등... 익숙한 이름들이 보입니다. ㅋㅋ 넥서스 S 를 사용하신다면 이것 말고 위쪽에 korean 버전이 따로 있습니다. 이걸 다운 받으시면 됩니다. 갤럭시 넥서스의 경우에는 korean 버전이 따로 존재하지 않습니다.

 해외롬으로 적용할 경우 국내에 출시된 갤럭시 넥서스는 GSM/HSPA+ 버전을 다운 받으시면 됩니다. 구글 Wallet 버전도 있지만 국내에서는 구글 Wallet 사용이 안되니...

 현재까지 최신 버전은 갤럭시 넥서스 4.0.4, 넥서스 7은 정식버전인 4.1, 넥서스 S는 4.0.4 버전이 있습니다. 아쉽게도 넥서스 원의 이미지는 해당 페이지에는 없습니다.


넥서스 S는 아래와 같이 4개의 롬이 있습니다. 최신버전을 가장 빨리 받아보는 방법은 당연히 월드 버전을 다운 받아 설치하시면 됩니다. 한국 순정 버전은 Korea version, m200 버전을 다운 받으시면 됩니다.

[https://developers.google.com/android/nexus/images#mantarayjop40c]

 다운받은 Factory Images를 압축을 해제하시면 됩니다. 아래와 같이 5개의 파일이 제공됩니다. 이 중 flash-all.sh에 명령어들이 있습니다. 뭐 직접 열어서 하나하나 입력하시는것도 좋겠지만 이왕 만들어진 스크립트이니 편리하게 사용해야 겠죠?

 일단 아래의 파일들을 모두 android-sdk가 설치된 폴더로 복사합니다. 저는 편의상 C:\ 드라이브 아래에 android-sdk를 설치했습니다. android-sdk-windows\platform-tools\ 폴더에 복사합니다.



- 최근 Factory Images를 압축을 풀면 .bat파일도 함께 존재합니다. .sh.bat로 변경하지 않아도 됩니다.


 아래와 같이 복사를 했습니다. 이중 .sh 파일이 2개가 있습니다. 윈도우에서는 .sh가 동작하지 않습니다.

 이 중에 Factory 이미지 적용에 사용해야 할 .sh 파일은 flash-all.sh 입니다. flash-all.sh를 flash-all.bat 로 변경하는데 이는 윈도우에서 읽을 수 있는 bat 파일로 변환합니다. bat로 변환하면 cmd에서 읽을 수 있는 파일로 변경이 됩니다.

 참 고로 다운 받은 Factory Images를 압축해제하고 아래와 같이 복사한 이유는 platform-tools 폴더에 있는 adb, fastboot 등의 실행 파일이 필요하기 때문에 아래와 같이 복사했습니다. 단, 윈도우 환경 변수에 등록하셨다면 해당 작업은 필요치 않습니다. 그렇지 않으면 fastboot.exe파일만 있어도 됩니다.


Factory Images 설치

갤럭시 넥서스의 경우

 일단 휴대폰을 끄고, 전원 버튼과 볼륨 크게/작게 버튼을 동시에 누릅니다.(볼륨 버튼은 가운데를 누르면 됩니다.) 3개의 버튼을 동시에 눌러 대기모드로 전환하시면 됩니다. 이미 지난 루팅 및 젤리빈 설치 글을 보셨다면 드라이브가 설치되어 있을 것이라고 생각됩니다. 별도로 설명하진 않겠습니다.


넥서스 S의 경우

 일단 휴대폰을 종료하고, 볼륨 크게 + 전원 버튼을 동시에 누르시면 됩니다.

 USB가 연결되어 있다면 아래와 같이 Android 1.0 드라이브를 찾을 수 없다고 할 것입니다. 만약 설치되어 있다면 다음 부분으로 넘어가시면 됩니다.


찾을 수 없을 경우 아래 글을 열어서 참고하세요.

더보기


 휴대폰의 대기상태가 되었으면 이제 윈도우에서 작업을 하면 됩니다. cmd 를 실행합니다.(윈도우에서 실행 또는 명령어에 cmd를 입력하면 됩니다.)

 경로를 변경합니다. c:\ 아래에 android sdk를 설치했기에 아래와 같이 변경합니다.

 해당 폴더에는 flash-all.bat라는 파일이 포함되어 있습니다.

 아래와 같이 실행합니다. (아래쪽에서 flash-all.bat에 어떤 명령이 포함되어 있는지 살펴보겠습니다.)


참고

 진행중에 radio 버전 문제로 진행이 안되는 경우가 발생할 수 있습니다. 젤리빈의 Radio 버전과 ICS의 Radio 버전이 서로 다르기 때문에 발생하는 문제입니다. 이런 문제가 발생 할 경우에는 아래 명령어를 이용하여 radio 패치를 먼저 한 후 다시 진행하시면 됩니다.

  fastboot flash radio radio-maguro-파일명.img


 flash-all.bat를 실행하면 아래와 같이 명령어가 실행됩니다. sleep 5라는 명령어를 사용하는데 윈도우에서는 사용할 수 없는 명령어라 실행되지 않습니다. bat 파일에 저장된 라인 수대로 실행이 이루어집니다. 시간은 약 5분도 안걸리는 듯 합니다. 설치가 완료되고 나면 자동으로 재부팅까지 완료합니다. 이제 남은건 LOCK만 걸어주면 됩니다.


flash-all.bat(또는 flash-all.sh) 명령파일을 실행하면 아래와 같습니다. # 으로 주석이 걸려있는 명령어를 제외한 명령어를 직접 입력하셔도 rom 초기화 하는데에는 문제가 없습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#!/bin/sh
# Copyright (C) 2011 The Android Open Source Project
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
 
#여기서 부터 명령입니다.
fastboot flash bootloader bootloader-maguro-primela03.img
fastboot reboot-bootloader
#sleep 5 /bin/sh 사용되는 명령이라서 사용이 되진 않습니다.
fastboot flash radio radio-maguro-i9250xxla02.img
fastboot reboot-bootloader
#sleep 5 /bin/sh 사용되는 명령이라서 사용이 되진 않습니다.
fastboot -w update image-yakju-imm76i.zip

재부팅을 했지만 아직 LOCK는 UNLOCK 모드입니다.

LOCK 걸어주기

  다시 휴대폰의 전원을 끕니다. 구글에서 제공해주는 명령어를 사용했기 때문에 폰이 자동으로 재부팅 됩니다. 강제로 종료하셔도 문제는 없습니다.

 전원 버튼과 볼륨 크게/작게 버튼을 동시에 누릅니다.(볼륨 버튼은 가운데를 누르면 됩니다.) 3개의 버튼을 동시에 눌러 대기모드로 전환하시면 됩니다.

 위에서 작업하던 cmd창을 열고 아래 명령을 입력합니다.

1
fastboot oem lock


이제 모든 초기화 및 LOCK 걸어주는 작업까지 끝이 났습니다. 갤넥에서 정상적으로 4.0.4 버전으로 돌아갔는지 확인해야 합니다.

설정에서 확인한 4.0.4 버전입니다.


설치된 앱들입니다.


루팅앱도 없고, ICS로 돌아왔네요.


마무리

 이렇게 순정롬으로 변경하는 작업을 진행했습니다. 추가로 어떤 명령어를 사용했는지에 대해서도 살펴봤습니다. 원래는 하나하나 명령어를 직접입력해주기도 합니다. 그런데 간단하게 스크립트를 지원하는데 굳이 하나하나 입력해야 할 필요는 없다고 생각됩니다. 그래서 간단하게 복원하는 방법을 살펴봤습니다.

 그런데 국내롬이 이걸로 해당되는지는 모르겠군요....

'기타' 카테고리의 다른 글

[Gerrit] 환경 구축  (0) 2020.04.15
[Hudson] 자동 빌드 설정 방법  (0) 2012.08.10
VPN  (0) 2011.05.03
SVN GUI TOOL[SVN Tool - RapidSVN 사용법]  (0) 2011.02.09
SVN  (0) 2011.02.09

Hudson을 이용한 빌드와 테스트의 자동화


 

2007-04-04
BEA Systems Korea
Sr consultant Byungwook Cho (bcho@bea.com)

Continuous Integration(점진적 통합,이하 CI)이란, 개발자가 각각 개발한 소스코드를 모아서 한꺼번에 빌드하는 통합 빌드의 과정을 특정 시점이 아니라 매일이나 매주와 같이 아주 잦은 주기로 수행함으로써 통합에서 발생하는 오류와 시간을 줄이기 위한 기법이다.
Extreme Programming Community (XP)에서 애자일 방법론의 일부로 Kent Beck에 의해서 고안된 방법으로 다음과 같은 특징을 가지고 있다.

1. CI의 특징
(1) 소스코드 일관성 유지
CI툴을 설정하기 위해서는 기본적으로 소스 관리 시스템이 필요하다.
대표적인 소스 관리 시스템은 Subversion,CVS,Perforce등이 있다.
CI툴은 이 소스 관리 시스템으로부터 프로젝트 소스의 메인 브랜치(trunk 라고도 한다.) 코드를 Check out 받아서 빌드를 수행한다.

(2) 자동 빌드
소스 코드에 대한 빌드는 CI툴에 의해서 자동적으로 이루어 져야 한다.
빌드가 이루어지는 시점을 정하는 방법이 두가지가 있는데 다음과 같다.

1) 커밋에 따른 자동 빌드
다른 방법으로는 소스코드가 소스 관리 시스템에 커밋이 되었을 때 마다 CI툴이 이를 감지 하고 자동으로 빌드를 수행하도록 설정할 수 있다.
이렇게 설정할 경우 소스 코드의 변경이 있을 때 마다 빌드 작업을 수행하기 때문에 소스 관리 시스템에 저장된 소스 코드에 대한 무결성을 보장하기는 매우 좋지만, 빌드 시간이 길 경우 빌드가 적체 되는 현상이 발생할 수 있다. 
(일반적으로 대규모 애플리케이션의 FULL 빌드는 길게는 2~3시간 까지 소요될 수 있다.) 그래서 이 방법은 빌드 시간이 오래 걸리는 경우나 커밋이 자주 발생하는 경우에는 적절하지 않다.

2) 시간 간격에 의한 빌드
일정 시간 간격을 정해서 빌드를 하는 방법이다. 매일 5시에 빌드를 한다. 또는 매주 금요일 저녁 5시에 빌드를 한다는 것과 같이 주기를 정할 수 있다. 빌드 스케쥴이 미리 정해져있기 때문에 개발자들이 커밋에 대한 스케쥴을 관리할 수 있고 빌드 시간이 오래걸리는 대규모 빌드에도 적정하다.
 빌드 시간을 정할 때 중요한 점은 가급적이면 퇴근 시간 1~2시간 전으로 개발자들이 퇴근하기 전 시간으로 여유를 두는 것이 좋다.
이후 빌드가 깨진 경우는 컴파일이 실패하였거나 테스트가 통과하지 못하였을 경우인데 이때 소스 관리 시스템에 저장된 코드는 문제가 있는 코드이다. (빌드가 깨졌기 때문에) 이 코드들을 다른 개발자가 체크아웃 받아서 개발을 했을 때 잘못된 코드로 인해서 잘못된 개발 방향으로 갈 수 가 있기 때문에 빌드가 깨졌을 때는 가급적 빨리 문제를 수정하여 빌드를 정상화 시키고 소스 관리 시스템에 저장되 코드의 무결성을 회복하거나 빌드가 성공한 전버전으로 BACK(Revert) 해서 무결성이 보장된 코드내에서 작업하도록 한다. Revert를 위해서는 소스 관리 시스템에 빌드때마다 Tagging을 해서 무결성이 보장된 버전에 대한 History를 관리해야 한다.

Silent period에 대해서
CI툴에서는 소스 관리 시스템으로부터 소스를 체크아웃 또는 업데이트 받을 때 Silent Period라는 옵션을 제공한다.
개발자가 소스를 커밋하고 있을 때 커밋이 완료되지 않은 상태에서 CI툴이 소스를 체크아웃하게 되면 불완전한 코드가 내려와서 빌드가 망가질 수 있다. 이를 방지하는 옵션이 Silent Period인데, 커밋이 있은후 일정 시간동안 소스 관리 시스템에 변화가 없을 때 CI툴이 체크아웃을 받아서 불완전한 코드를 내려 받을 수 있는 가능성을 최소화 하는 것이다.

이렇게 자동 빌드를 하면서 얻을 수 있는 이점은, 주기적인 빌드를 통해서 소스코드의 무결성 관리와 빅뱅방식의 통합에서 올 수 있는 리스크를 개발과정 전반으로 분산할 수 있다.

(3) 자동 테스팅
빌드 과정에서 테스트를 포함할 수 있는데, 주기적인 빌드 과정에 테스트를 포함해서 자동 빌드를 통한 Syntax에 대한 검증과 더불어 테스팅을 통한 기능과 비기능적(성능등)에 대한 요건을 매번 검증함으로써 코드의 품질에 대한 무결성을 함께 유지한다.

(4) 일일 체크아웃과 빌드
개발자가 출근후 소스 관리 시스템에서 최신 코드를 내려받고, 출근전에 현재 코드를 소스 관리 시스템에 저장함으로써 소스 코드에 대한 무결성을 유지한다.

예를 들어 개발자 A와 개발자 B가 같이 개발을 할 때, 개발자 A가 작성한 모듈을 개발자 B가 참고해서 사용한다고 하자, 이런 경우 개발자 A가 임의로 컴포넌트에 대한 작동 방식이나 인터페이스를 변경했을 때 일일 체크아웃과 빌드를 하면 개발자 A의 모듈을 사용하는 개발자 B의 모듈의 컴파일 오류나 또는 테스트 오류가 발생할 것이고 코드 변경으로 인한 임팩트를 빠르게 발견하여 수정할 수 있다.
그러나 통합 빌드의 과정이 일일이 아니거나 일일 체크아웃 빌드를 하지 않고 일주일이나 한달 단위로 할 경우 일주일동안 개발자 B는 잘못된 코드를 양산할것이고, 그 만큼의 시간 낭비가 발생한다.

일일 체크아웃과 빌드는 이를 방지해주는 역할을 한다.

2.CI 프로세스

CI에 대한 프로세스를 정리해보면 다음과 같다.
 

사용자 삽입 이미지

<그림. Continous Integration Process >


(1) 개발자
1) 개발자는 아침에 출근해서 소스 관리 시스템으로부터 최신 코드를 Checkout 또는 update받는다.
2) 코드를 가지고 개발을 수행하고 테스트를 작성한다.
3) 로컬에서 빌드 및 테스트를 진행한다.
4) 테스트과정에서 커버러지분석과 Code Inspection을 수행한다. (Optional)
 커버리지 분석
커버러지 분석은 테스트의 대상중에 테스트에 해당하는 부분중에 어느 부분이 테스트가 수행이 되었는지를 체크하는 과정이다. 개발 과정에서의 테스트 커버러지 분석은 일반적으로 코드 커버러지로 분석한다.
코드 커버러지란 테스트가 전체 소스 코드중 어느부분을 수행했는지를 검토하는 것이다.
코드 커버러지를 측정할 때 가장 중요한 것은 목표 커버러지율을 결정하는 것이다. 코드 100%를 테스트하는 것이 좋겠지만, Exception,If 문에 대해서 100% 테스트가 불가능하다. 또한 Setter와 Getter만 있는 ValueObject의 경우 테스트를 작성하는 것도 쉽고 테스트 자체가 의미가 없나 Coverate rate는 많이 올릴 수 있다. 만약 커버러지율을 강제적으로 높이고자 하면 개발팀에서 VO등 테스트가 필요하지 않고 테스트가 쉬운곳에만 테스트를 집중할 수 있기 때문에 컴포넌트의 우선순위를 정해서 중요한 컴포넌트에 대해서 커버러지를 관리하는 것이 필요하다.
커버러지율은 잘 만든 테스트라도 50~70% 내외이고, 고 가용성 시스템도 80%를 넘기 힘들기 때문에, 컴포넌트의 중요도별로 목표 커버러지율을 융통성 있게 결정하는 것이 필요하다.
대표적인 오픈소스 도구로는 EMMA와 Cobertura등이 있고, 상용 도구로는 Atlassian社의 Clover등이 있다.
 Code Inspection
Code Inspection이란, 완성된 코드에 대한 검토를 통해서 코드상에 존재하고 있는 잠재적인 문제를 발견하는 과정이다. 흔히 “정적 분석” 이라는 이름으로도 불리는데, 이 과정에서 Deadlock에 대한 검출 Lock contention과 같은 병목 구간에 대한 검출 Memory Leak이나 Connection Leak과 같은 자원 누수에 대한 검출과 코딩 스타일 (변수명이나 메서드명 규칙등)에 대한 가이드를 수행한다.
보통 이런 도구들은 룰 셋을 추가하여 Inspection을 각 팀의 스타일에 맞춰서 Customizing할 수 있으며 대표적인 오픈 소스 도구로는 PMD, FindBugs등이 있다.

5) 완료된 코드를 소스 관리 시스템에 저장한다.
완료된 코드와 테스트를 소스 관리 시스템에 커밋한다.

(2) CI Tools

1) 체크아웃
CI Tools는 정해진 시간이나 소스가 커밋이 되었을 때 등 정책에 따라서 빌드를 시작한다. 먼저 소스 코드를 체크아웃 받는다.
2) 컴파일
체크아웃 받은 코드에 내장되어 있는 빌드 스크립트를 기동하여 컴파일을 수행한다.
3) 배포
컴파일이 완료된 코드를 테스트 서버에 배포한다.
4) 테스트 수행
체크아웃 받은 코드내에 있는 테스트 코드들을 수행하고 리포팅을 한다.
5) 커버러지 분석
테스트 과정중에 코드 커버러지를 수행한다.
커버러지의 기본 원리는 커버러지 분석 대상이 되는 코드내에 커버러지 분석 코드를 삽입하여 테스트가 완료된 후에 그 결과를 수집하여 분석을 하는데 분석 코드를 삽입하는 과정을 Code Instrument라고 한다. Instrumented된 코드는 커버러지 분석 기능으로 인해서 성능 저하를 유발할 수 있기 때문에 만약에 테스트 과정에 성능이나 응답시간에 관련된 테스트가 있을때는 커버러지 분석을 위해서 테스트를 마친후에 Instrument를 다시하여 3),4) 과정을 다시 거쳐서 커버러지 분석을 해야 테스트 과정에서 성능에 대한 요소를 올바르게 추출할 수 있다.
6) Code Inspection
다음으로 Code Inspection을 수행하고 리포트를 생성한다.
7) 소스 태깅
1)~6) 과정이 정상적으로 수행되었을 때, 현재 소스 관리 시스템에 저장된 버전을 안정적인 버전으로 판단하고 소스 관리 시스템에 현재 버전에 대한 이미지를 저장하기 위해서 Tagging을 수행하여 현재 버전을 저장해놓는다. 
8) Reverse (Optional)
만약에 빌드나 테스트가 실패하였을때는 이전에 성공한 빌드 버전으로 소스를 롤백하고, 실패의 원인을 파악한후에 다시 커밋한다. 
이것은 소스 관리 시스템에 저장된 소스는 문제가 없는 소스를 항상 유지하여 개발자들이 문제가 없는 소스로 작업을 할 수 있게 보장해주며, 릴리즈가 필요한 시기에 언제든지 릴리즈가 가능하도록 지원해준다.
9) 결과 분석
빌드와 테스트가 완료된 후에 테스트 결과서를 통해서 문제가 있는 테스트를 개발자가 수정하도록 하고, Code Inspection결과를 PM이 검토하여 담당 개발자가 수정하도록 한다. 
다음으로 Coverage 분석 결과를 통해서 테스트가 부족한 부분은 PM이 담당 개발자에게 지시항 테스트를 보강하도록 한다.

3.Hudson 설치

(1) Hudson의 설치 및 기동


1) https://hudson.dev.java.net/ 에서 hudson을 다운로드 받는다.
2) 다운로드 받은 Hudson.war를 Apache Tomcat에 deploy해서 구동 하거나 도는 java –jar hudson.war로 hudon으르 기동한다. 디폴트로 설치된 hudson은 8080포트를 통해서 접근이 가능하다. (Tomcat을 통해서 설치 하지 않은 경우)

WAS에 인스톨 정보
http://hudson.gotdns.com/wiki/display/HUDSON/Containers

(2) Hudson과 소스 관리 시스템 연동
좌측 메뉴에서 “New Job”을 선택하여 새로운 작업을 등록한다.
Job name을 선택하고 “Build a free-style software project”를 선택한다. 아직까지 다른 빌드 선택은 안정화 되어있지 않기 때문에 이 메뉴를 중심으로 설명한다.
 

사용자 삽입 이미지

<그림 1. 새로운 프로젝트의 생성>

(3) 소스 관리 시스템과 연동
Job이 생성되고 나면 초기화면에서 Job을 선택할 수 있다 Job을 선택하면 좌측에 Configure라는 메뉴가 생기는데, 그 안으로 들어가면 Job에 대한 설정을 할 수 있다.

먼저 소스 관리 시스템으로부터 코드를 내려받도록 설정해야 한다.
“Source Code Management”에서 사용하는 소스 관리 시스템을 선택한다.
이 예제에서는 Subversion을 선택한다.
Subversion을 선택한후 Repository URL에 SVN접근 주소를 입력한다. 
svn://source.example.com/trunk 그 아래에 “Local module directory”에 SVN 레파지토리의 하위 디렉토리를 선택한다. “/myproject” 식으로 
이렇게 하면 svn://source.example.com/trunk/myproject 에서 소스 코드를 매번 내려받게 된다. Repository URL과 Location을 지정하면 Hudson이 자동으로 SVN에 접속을 시도해본다. 만약에 id와 passwd가 필요한 경우에는 아래 그림과 같이 “enter credential”이라는 링크가 Repository URL 아래 나타나서 id와 passwd를 입력할 수 있게 한다.
 

사용자 삽입 이미지

<그림 2. SVN 접속 정보 입력>
여기에 소스 관리 시스템 연결에 관련해서 몇가지 옵션을 추가할 수 있다.

 Use Update
소스 관리 시스템에서 소스를 내려받을 때 디폴트가 모든 소스를 매번 다운로드 받는것인데 이런 경우에는 소스양이 많을 경우 다운로드에 많은 시간이 소요되서 전체 빌드 시간이 늘어날 수 있다. 이때 “Use Update”라는 옵션을 사용하면 처음에만 소스 코드를 전체 다운로드 받고, 두번째 부터는 변경된 소스 코드만 다운로드 받기 때문에 소스 코드를 다운 받는 시간을 많이 줄일 수 있다. (svn update와 같은 명령)

 Repository Browser
Repository Browser란 소스 관리 시스템에 저장된 소스의 내용 웹에서 브라우징할 수 있는 도구이다. 도구에 따라서 이전 버전과 변경된 부분에 대한 Diff비교 또는 처음 소스 코드가 생성되었을 때부터 매번 커밋되었을 때 변경 내용에 대한 Revision등에 대한 모든 히스토리를 출력해준다. 이런 기능은 빌드가 깨졌을 때, 바로 빌드 버전에 대한 소스 변경 내용을 추적하여 누가 어떤 코드를 변경하였는지를 추적하여 가능한한 빠른 시간내에 문제를 해결하게 해준다.
이 옵션을 체크해놓으면 빌드가 완료된후 Job의 Changes를 보면 소스 코드가 변경된 부분에 대해서 Repository Browser로 링크가 걸려서 소스를 웹에서 바로 확인하거나 전버전에서 바뀐 부분을 확인할 수 있다.
대표적인 Repository Browser로는 오픈소스 제품인 Sventon과 상용제품인 Fisheye등이 있다.

(4) 빌드 트리거링
다음 설정해야 하는 부분이 Build Triggers 설정이다.
이 설정은 언제 빌드가 돌아야 하는가를 설정하는 부분으로 3가지 옵션을 제공한다.

1) Build after other projects are built
이 옵션에는 다른 Job(Project)의 이름을 인자로 넣는다. 
이렇게 하면 지정된 프로젝트의 빌드가 정상적으로 끝나면 자동으로 이 프로젝트가 Invoke된다. 만약에 빌드만 하는 Job과 테스트만 하는 Job이 있고 테스트는 자주 사용하고 빌드후에 반드시 테스트를 해야할 때, 테스트 Job에서 이 옵션으로 선행작업을 빌드로 해놓으면 빌드를 수행할 때 마다 빌드가 성공하면 테스트를 수행하게 된다. 테스트만 수행하면 빌드와 상관없이 테스트만 수행된다.
이 옵션은 프로젝트 실행의 전후 관계(Chainning)을 하는데 매우 유용하게 사용할 수 있다.

2) Poll SCM
이 옵션을 사용하면 여기에 지정한 주기별로 소스 관리 시스템을 폴링(체크)하여 변경이 있을 경우에만 빌드를 수행한다.
 

사용자 삽입 이미지

<그림 Build Trigger 등록 >

시간 설정 방법은 unix의 crontab 명령과 같은 형식으로 아래와 같은 형식을 사용한다.
분 시간 날짜 월 요일

사용 예는 다음과 같다.
# 매일 12시에 실행
00 12 * * *
# 매주 일요일 1시에 실행
00 01 * * 7
# 매일 12시와 5시에 실행
00 05 * * *
00 12 * * *

3) Build periodically
마지막으로 Build periodically는 정해진 시간 주기별로 소스가 변경과 상관없이 무조건 주기적으로 빌드를 수행하며 Poll SCM과 마찬가지로 crontab과 같은 형식으로 스케쥴을 등록한다.

(5) Build
정해진 스케쥴 정책에 따라 빌드 프로세스가 기동되면 실제 빌드를 수행할 빌드 스크립트가 구동되어야 하는데, Hudson에서는 ANT,MAVEN,그리고 Unix/Windows shell을 수행할 수 있도록 되어 있다. 여기서는 ANT 기반으로 설명을 한다.
 

사용자 삽입 이미지

<그림. Invoke ANT 설정 >

Invoke ANT를 선택 하면 다음과 같은 옵션을 선택할 수 있다.

 ANT Version
Hudson 초기화면에서 “Manage Hudson”메뉴로 들어가면 “System configuration” 메뉴에서 여러 개의 ANT_HOME을 등록할 수 있다.
ANT 버전에 따라서 플러그인이 차이가 날 수 도 있고, 프로젝트에 따라서 사용해야 하는 ANT 버전이 틀릴 수 있기 때문에 여러 개의 ANT를 등록할 수 있게 해준다.
예를 들어 프로젝트가 JUnit 3.8대와 JUnit 4.X대로 각각 구현되어 있다면 ANT에 설치되어야 하는 JUnit 라이브러리 버전이 틀리기 때문에 두개의 ANT를 설정해야 할 수 있다. 이런 경우에 “System configuration”에서 ANT를 여러 개 등록해놓고, 이 ANT Version 메뉴에서 필요한 ANT 버전을 선택하면 된다.

 Target
ANT 스크립트의 Target을 설정한다.

 Build File
ANT 스크립트를 지정한다. 일반적으로 build.xml을 지정한다.

 Properties
ANT 스크립트에 전달해야 하는 Property를 지정한다.
예를 들어 스크립트내에 $workspace라는 변수를 지정하였을 경우 –Dworkspace=값 이런식으로 텍스트 상자에 정의하면 빌드 스크립트로 인자를 전달할 수 있다.

 Java Options
ANT 를 기동하는데 필요한 자바 옵션을 지정한다. ANT도 자바 프로그램이기 때문에 여러가지 JVM 옵션이 지정되는데 Heap,Perm size등을 여기서 –Xmx256m 식으로 지정하여 이 옵션으로 ANT 프로세스를 실행할 수 있다.

여기 까지 설정하면 주기적으로 빌드를 자동화 하는 설정이  완료 되었다.

(6) Hudson의 사용
초기화면에 들어가면 등록된 프로젝트 리스트들이 나온다. 
 

사용자 삽입 이미지

초기화면에서는 현재 빌드 상태와 프로젝트별 빌드 성공 실패 여부가 나타난다. 빌드가 성공하면 맑은 태양이 실패율이 높으면 천둥 모양으로 아이콘이 변경이 된다.

초기화면에서 프로젝트를 클릭하면 아래와 같은 화면이 나오는데
 

사용자 삽입 이미지

< 그림, Hudson 프로젝트별 초기화면 >
Changes는 빌드 버전별로 소스 관리 시스템에서 지난 버전에 비해서 변경된 내용 누가 변경했는지 그리고 커밋시에 개발자가 추가한 Comment를 확인할 수 있다.Workspace는 이 프로젝트의 빌드 디렉토리를 보여준다. 브라우져를 통해서 빌드에 사용된 파일등을 확인할 수 있다. 
그 아래 메뉴가 “Build Now”인데 이 메뉴는 스케쥴에 상관없이 지금 강제적으로 빌드를 하게 한다. 
좌측 맨 아래 메뉴는 BuildHistory로 언제 빌드가 수행되었고 현재 빌드 상태와 빌드 성공 실패 여부를 나타낸다.

(7) Hudson과 Email 연동
Hudson 초기화면에서 Manage Hudson > System Configuration 메뉴에 들어가면 Email-Notification 설정부분이 있는데, 여기 SMTP 서버를 설정해주면 빌드가 실패하였을 때 등에 담당자들에게 메일로 통보를 할 수 있다. SMTP 설정을 한후 프로젝트의 configuration 메뉴에서 Post-build Actions에서 Email Notification에 Receipients에 이메일 주소를 적어놓으면 빌드가 실패했을때와 실패한 빌드가 복구 되었을 때 이메일이 발송된다.
 

사용자 삽입 이미지

<그림. Email Notification 설정 >


(8) JUnit 테스트 연동
CI에 대해서 설명할 때 Test에 대해서 설명했는데, Hudson에서는 JUnit Test Report를 출력해주는 기능을 지원한다.
프로젝트 configuration에서 Post-build actions의 “Publish JUnit test result report” 메뉴에서 JUnit 리포트 파일명을 지정해주면 아래와 같이 테스트가 끝나고 테스트 리포트가 생성되면 테스트 성공 실패 여부를 그래프로 나타내주고, 테스트의 Progress도 누적 그래프로 프로젝트 초기화면에서 출력해준다.

사용자 삽입 이미지

<그림. 프로젝트 초기화면에서 테스트 히스토리에 대한 그래프 >  
사용자 삽입 이미지

<그림. 프로젝트별 테스트 성공 실패 요약 >

이때 주의할점은 JUnit의 테스트 리포트의 파일 경로는 절대 경로가 아니라 프로젝트 Workspace에 대한 상대 경로이기 때문에 상대 경로로 지정해야 한다.

(9) Hudson과 Japex를 이용한 부하 테스트 연동
Japex는 단위 테스트에 대한 부하 테스트를 할 수 있는 단위 부하 테스트 자동화 프레임웍이다. Japex에 대한 사용 방법은 단위 테스트의 “단위 부하 테스트” 부분을 참고하기 바란다.
Japex 역시 JUnit과 마찬가지로 성능에 대한 결과 (테스트 소요 시간)를 그래프로 출력할 수 있다. JUnit과 설정 방법이 같으며 프로젝트 > configuration > Post-build Actions > Record Japex test report에 Japex 테스트 리포트 경로를 추가하면 된다.
 
설정이 제대로 됐으면 테스트 수행후에 왼쪽에 Japex Trends Report라는 메뉴가 생겨서 성능 테스트에 대한 결과를 누적 그래프로 출력해준다.

Japex 테스트 플러그인은 Hudson에 Default로 포함된 것이 아니기 때문에http://hudson.dev.java.net에서 다운받아서 Hudson에 추가로 설치해줘야 한다.


(10) Hudson과 Cobertura를 이용한 Coverage분석
Coverage 분석에 대해서는 EMMA와 Cobertura, Clover에 대한 확장 플러그인을 제공하는데, 플러그인을 설치한후 JUnit과 Japex와 동일한 방법으로 리포트에 대한 위치를 등록해주면 아래와 같이 커버러지의 누적 그래프를 클래스별,라인별,브랜치별로 출력해준다.
 

사용자 삽입 이미지

(11) 그외의 기능들
본 문서에서는 Hudson에 대한 대략적인 기능을 살펴보았다.
Hudson은 이 이외에도 여러 개의 Hudson 인스턴스를 구성하여 클러스터된 빌드환경을 구축할 수 있다. 여기서 클러스터란 로드분산이나 장애 대응등의 의미가 아니라,
하나의 소스 코드를 가지고 Windows,AIX,HP 버전으로 각각 빌드가 필요할 때, 각 서버에 Hudson을 따로 설치하고 각각 관리하는 것이 아니라 설치는 각각 하더라도 하나의 콘솔화면에서 컨트롤을 하도록 설정이 가능하다.
또한 여러 확장 플러그인을 통해서 기능 확장이 가능하다.

(12) Hudson 사용시 주의할점
Hudson은 이미 JBoss 프로젝트나 기타 상용 프로젝트에서 사용될정도로 매우 널리 쓰이고 안정적인 버전이다. 그럼에도 불구하고 오픈 소스의 한계점과 잦은 업그레이드로 인해서 잠재적인 버그가 있고 특히 플러그인들의 버전이 Hudson의 버전 업그레이드를 쫓아가지 못해서 일부 플러그인들은 하위 버전에서만 작동하고 최신 버전에서 작동하지 않는 경우가 있기 때문에 자신이 사용하고자 하는 플러그인들에 맞는 Hudson 버전을 사용하는 것이 중요하다.
여기서 소개된 플러그인들은 Hudson 1.7 버전을 기준으로 사용 및 검증이 되었다.

4. 그외의 CI Tools
예전에는 CI 툴이 Cruise Control이나 Ant hill이 주류를 이루고 있었으나,
Hudson이 등장하면서 많은 프로젝트들이 쉽고 직관적인 인터페이스와 확장성으로 인해서 많이 사용되고 있다.
TeamCity의 경우 일반 버전은 무료로 제공되며 TeamCity Pro는 상용이다. 무료 버전도 상용 코드를 기반으로 하는 만큼 Hudson에 비해서 높은 안정성을 가지고 있으다.
AntHill Pro 역시 꾸준히 Java 진영의 CI도구로 사용되고 Atlassian의 Bamboo도 근래에 들어 많이 프로젝트에 사용되고 있다.


출처 : http://bcho.tistory.com/entry/Hudson%EC%9D%84-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EB%B9%8C%EB%93%9C-%EB%B0%B0%ED%8F%AC-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%9E%90%EB%8F%99%ED%99%94


'기타' 카테고리의 다른 글

[Gerrit] 환경 구축  (0) 2020.04.15
넥서스 S 바이너리 올리기  (0) 2012.11.25
VPN  (0) 2011.05.03
SVN GUI TOOL[SVN Tool - RapidSVN 사용법]  (0) 2011.02.09
SVN  (0) 2011.02.09
virtual private network의 약자로, 우리말로 가상사설망이라고 한다.

VPN이란 인터넷망과 같은 공중망을 사설망처럼 이용해 회선 비용을 크게 절감할 수 있는 기업통신 서비스.

인터넷망을 전용선처럼 사용할 수 있도록 특수통신체계와 암호화기법을 제공하는 서비스로 기업 본사와 지사 또는 지사간에 전용망을 설치한 것과 같은 효과를 거둘 수 있으며, 전용선에 비해 20∼80% 이상의 비용을 줄일 수 있다. 

뿐만 아니라 사용자의 이동성 보장과 편리한 네트워크 구성 등이 장점이 있다. 그러나 VPN 구축을 위해서는 데이터암호화하는 보안기술이 뒷받침돼야 한다. 

가상사설망서비스는 미국에서 1980년 말부터 시작된 이후에 미국의 US Sprint와 AT&T에 의해 급속히 확산 보급되었다. 국내에 도입된 것은 지난 98년이며 VPN의 약점이던 보안문제가 해결되면서 서비스의 확산 속도가 더욱 빨라지고 있다.

VPN모든 회사들이 저마다 개별적으로 회선을 임차하는 것보다 공중망을 공유함으로써 비용은 낮추면서도 전용회선과 거의 동등한 서비스를 제공하려는 아이디어에서 출발하였다. 

VPN은 공중망을 통해 데이터를 송신하기 전에 데이터를 암호화하고, 수신측에서 이를 복호화한다.

마이크로소프트, 3Com 등 몇몇 회사들이 PPTP (Point-to-Point Tunneling Protocol)라는 표준 프로토콜을 제안하였으며, 마이크로소프트는 이 프로토콜을 윈도우NT 서버에 내장시켰다. 
출처 :  네이버 지식사전

'기타' 카테고리의 다른 글

넥서스 S 바이너리 올리기  (0) 2012.11.25
[Hudson] 자동 빌드 설정 방법  (0) 2012.08.10
SVN GUI TOOL[SVN Tool - RapidSVN 사용법]  (0) 2011.02.09
SVN  (0) 2011.02.09
MMAP  (0) 2011.01.27
이 문서는 계속 업데이트 됩니다. v0.1

1. SVN 개념

개념도

개념도. SVN의 Checkout, Update, Commit 등의 명령으로 형상관리를 할 수 있다.


SVN은 위처럼 서버등록된 파일을 자신의 PC에 내려받아 수정하고 SVN 서버에 업로드 하는 방식의 버전관리시스템이다.

2. RapidSVN
Tigris.org Open Source Software Engineering Tools 에서 배포하는 SVN 클라이언트다.
왜 이걸 쓰냐면 크로스플랫폼 프로그램이기때문에 리눅스, MAC, 윈도우 똑같이 무료로 사용할 수 있다.

2.1 RapidSVN 설치.
http://rapidsvn.tigris.org/ 에서 최신버전을 다운 받는다. 글쓴 시점에서 0.12.0-8051 이다.

설치진행중

컴맹이라도 Next만 클릭하면 설치는 식은 죽먹기.


실행화면

설치 완료 후 실행


2.2 RapidSVN 작업 준비
 글 처음의 개념도에서 1번의 내용이다.
 아래 그림처럼 북마크에서 우 클릭 후 메뉴중 Checkout New Working Copy.. 을 클릭한다.
 - Checkout New Working Copy.. : 새로운 폴더에 Checkout 을 하겠단 뜻이다.
 - Add Existing Working Copy.... : 이미 Checkout 받은 폴더를 북마크에 추가
 - Add Existing Repository... : SVN서버의 목록을 등록한다. Checkout New Working Copy.. 는 데이터를 내려 받지만 이 메뉴는 서버데이터의 목록만 확인 가능하다.
 - Create New Repository... : 커맨드라인 서브버전(svnadmin) 파일로 받아 처리 하라고 한다. *_*;;
 - Switch Repository... : 선택된 저장소의 URL을 바꿀때 쓴다. 저장소 주소가 바뀐 경우 필수다.
Checkout New Working Copy.. 선택 화면

Checkout New Working Copy.. 를 눌러 내 PC에 SVN서버에서 파일을 Checkout 받자.




다음의 Checkout 팝업창에서 URL 과 목적폴더를 눌러 OK를 누른다.
Checkout 창

URL 및 Dest Dir 을 선택하고 OK를 누른다.


계정정보입력창

계정정보를 요구하면 저장소에 접근가능한 계정정보를 입력한다.



아래는 OK 누른후 다운 받아진 항목과 결과 창이다.
Revision 이 1 이고 Rep.. 이 1이니 현재 저장소와 내 폴더의 리비전이 일치하는 현재로선 최신버전이다.
Ckechout 완료 화면

Checkout 완료 후 Bookmarks 에 폴더가 추가되어 있고 폴더 및 파일 내용이 나온다.



실제 탐색기에도 파일이 받아져 있다.
탐색기 내용

탐색기에도 동일한 파일이 들어있다.



하지만 Checkout 된 폴더에는 숨겨진 파일로 .svn 폴더가 존재한다.
다음은 폴더 속성에 숨김 파일 보기를 했을때 화면이다.
숨겨진 svn 폴더

숨김파일보기를 했을때 숨겨진 .svn 폴더가 나타난다.


이게 SVN 을 사용하면서 가장 중요한 부분이 아닐까 싶다.
이 .svn 파일 속에는 현재 폴더에 각 파일의 정보를 담고 있는 META 파일이 존재하기때문에 함부로 위치이동을 하면 안된다.
.svn 폴더가 삭제됐을 경우 update 받으면 새로 받아지지만 혹시나 다른 svn 폴더로 덮어 쓰기 되버리면 감당하기 힘들다.. ;;
그리고 A라는 폴더의 내용의 이름을 B라고 바꾸고 싶을때 그냥 파일이름 변경으로 하면 절대 안된다.
(저 .svn 속의 META 파일에선 A라는 파일로 계속 남아있을테니까..)
그래서 SVN 에서 이름 바꾸기는 A폴더의 내용을 B로 복사(B폴더내의 .svn삭제) 후 A폴더 삭제(delete) 명령, B폴더 추가(add) 명령을 한다.
이걸 깜빡하면 Commit 했을때 경로가 깨졌다니 충돌이 났다니 저장소를 찾을 수 없다느니하는 엄청난 결과가 온다.
이러면 이전의 리비전으로 모두 받고 수정파일만 다시 저장하고 Commit 하는 사태가 벌어질 수 있으니 매번 강조해도 지나칠 수 없는 것이다.

2.2 RapidSVN 최신 버젼 갱신
 Checkout 으로 작업폴더를 만들었으면 작업을 시작할때다.
 모든 작업은 시작하기전에 Update 를 받아 최신파일로 갱신해야한다.
 예전 파일을 수정하면 다른 사람이 수정한 최신파일 적용받지 못해 충돌이 날 수 있기때문이다.

Update 선택

작업전 update 는 필수다.


OK를 누르면 최신버전을 확인 후 자동으로 적용시켜준다.
Update 창

최신 버전을 항상 확인하자.



계속 됩니다.

'기타' 카테고리의 다른 글

[Hudson] 자동 빌드 설정 방법  (0) 2012.08.10
VPN  (0) 2011.05.03
SVN  (0) 2011.02.09
MMAP  (0) 2011.01.27
Source Insight 3.5 에서 한글 주석 읽는 방법  (0) 2011.01.16

ubversion 사용 HOWTO


 
CVS의 단점들을 개선한 버전 관리 시스템인 Subversion을 이용하여 프로그램의 소스 코드를 관리하는 방법과 유닉스, 리눅스 및 Windows에서 Subversion을 설치해보고 사용하는 방법을 설명합니다.

 

1 소프트웨어 버전 관리의 이해
1.1 버전 관리 시스템의 필요성
1.2 버전 관리 시스템의 종류
1.3 버전 관리 시스템의 용어들
1.4 저장소의 디렉토리 배치
2 Subversion
2.1 CVS와 비교한 Subversion의 장점들
2.2 설치 준비 작업
2.3 사용 할 각각의 파일들 구하기
3 설치하기
3.1 Apache 컴파일과 설치
3.2 Subversion 컴파일과 설치
4 세부 설정
4.1 저장소 만들기
4.1.1 공동 작업을 위한 저장소 그룹 설정
4.2 Apache 설정
4.2.1 Apache에서 ID로 사용자 인증
4.3 svnserve를 사용한 서버
4.3.1 svnserve에서 ID로 사용자 인증
4.4 SSH + svnserve 서버
5 실제로 사용하기
5.1 에디터 설정
5.2 기본 디렉토리 만들기
5.3 Import
5.4 Checkout
5.5 Update
5.6 Commit
5.7 Log
5.8 Diff
5.9 Blame
5.10 Add
5.11 Export
5.12 Branch와 Tag
5.12.1 Branch
5.12.1.1 Merge
5.12.2 Tag
5.13 Revert
5.14 백업 및 복구
5.14.1 Dump
5.14.2 Load
6 Microsoft Windows에서 사용하기
6.1 설치 파일 구하기
6.2 설치
6.3 사용하기
7 운영체제별 전용 패키지
8 GUI 클라이언트 프로그램
8.1 TortoiseSVN
8.2 Ankhsvn
8.3 RapidSVN
9 웹 인터페이스
9.1 ViewCVS
9.2 WebSVN

 


1 소프트웨어 버전 관리의 이해 #
Subversion은 소프트웨어 버전 관리 시스템입니다. 이전에 CVS같은 역사가 깊은 소프트웨어 버전 관리 시스템을 사용해 본 경험이 있다면 쉽게 진행 할 수 있을 것입니다. 이 장에서는 소프트웨어 버전 관리 시스템을 처음 접하는 분들을 위해 자주 나오는 용어들과 개념을 정리 하였습니다.

 

1.1 버전 관리 시스템의 필요성 #
과연 소프트웨어를 만드는데 버전관리가 왜 필요할까요? 버전 관리가 필요하게 된 이유는 공동 작업 때문입니다. 한사람이 큰 프로젝트를 진행 하는 것이 아니기 때문에 버전 관리 시스템이 필요 하게 되었습니다.

 

버전 관리 프로그램을 사용하게 되면 다음과 같은 장점이 있습니다.

개발 버전과 릴리즈 버전을 섞이지 않고 쉽게 관리 할 수 있습니다.

소스를 잘 못 수정 했더라도 기록이 남고 되돌리기가 쉽습니다.(많은 파일의 경우 유용)

수정, 추가, 삭제 등의 기록이 모두 남고 변경 사항을 추적하기 쉽습니다.

개발자들이 따로 따로 백업을 하지 않아도 됩니다.


가장 유용한 장점은 아무래도 잘못 수정한 소스를 쉽게 되돌릴 수 있다는 것입니다. 프로젝트가 커지다보면 소스가 꼬이게 되고 골치 아픈 상황이 한두 번 발생하는 것이 아니죠. 그리고 변경 사항이 모두 기록되고 무엇을 변경 했는지 쉽게 볼 수 있습니다. 옆 사람이 수정한 것을 쉽게 볼 수 있습니다. 그리고 가장 큰 문제를 일으키는 백업을 하지 않아 소스를 분실하는 최악의 상황도 쉽게 해결 됩니다.

 

장점을 나열하자면 더 많습니다만 단점을 이야기 하자면 아무래도 프로그램 개발자들이 소프트웨어 버전 관리 시스템의 개념을 제대로 이해하고 기능들을 잘 사용하여 효율적인 버전 관리가 되려면 또다시 새로운 것을 배워야 한다는 것 때문에 쉽게 접근하지 않으려는 경향이 있습니다. 특히나 우리나라 프로그램 개발자들의 경우 윈도우 공유 폴더를 이용해서 개발을 하는 경우가 많습니다. 이렇게 되면 누가 무엇을 수정했는지 알 수도 없고 남이 해 놓은 소스 위에 잘못된 소스를 덮어쓰는 경우도 많이 발생하고 있습니다.

 

한사람이 개인적으로 진행 하는 프로젝트가 있더라도 버전 관리 프로그램을 사용하는 것이 매우 편리합니다. 앞서 말한 장점들은 여러 명이 개발 하는 것과 한사람이 개발 하는 것에 모두 해당되는 것들입니다.

 

소프트웨어 버전 관리 시스템을 이용하는 프로젝트들은 아주 많습니다. 대부분 Open Source로 된 프로젝트들은 CVS를 이용하여 버전 관리를 합니다. 대표적으로 *BSD, OpenOffice, Mozilla, XFree86, Apache와 SourceForge.net의 모든 프로젝트들 입니다. 비단 Open Source 뿐만이 아닌 상업 프로그램을 만드는 회사들에서도 소프트웨어 버전 관리 시스템은 필수적입니다.

 

1.2 버전 관리 시스템의 종류 #
현재 나와 있는 소프트웨어 버전 관리 시스템은 여러 종류가 있습니다. 각각 장단점이 있습니다.

CVS (Concurrent Version System) : 가장 널리 사용되며 역사가 깊은 버전 관리 시스템입니다. http://www.cvshome.org

Subversion : CVS의 단점을 개선하고 CVS를 대체할 목적으로 개발 되었습니다. 이 문서에서 설명할 버전 관리 시스템입니다.http://subversion.tigris.org

Visual Sourcesafe : Microsoft에서 만든 버전 관리 시스템입니다. CVS와는 버전 관리 관점에서 조금의 차이점이 있습니다. 윈도우 기반 소프트웨어의 버전 관리를 할 때 자주 사용됩니다. http://msdn.microsoft.com/ssafe/

Clear Case : Rational이라는 회사에서 만든 버전 관리 시스템입니다. 지금은 IBM에 합병되었습니다. 상용 소프트웨어입니다.http://www-306.ibm.com/software/rational

BitKeeper : 리눅스 커널이 BitKeeper를 이용해서 개발 하고 있습니다. 상용 소프트웨어입니다. http://www.bitkeeper.com


1.3 버전 관리 시스템의 용어들 #
소프트웨어 버전 관리 시스템에서 사용되는 용어들을 알아보도록 하겠습니다.

 

저장소 : 리포지토리(Repository)라고도 하며 모든 프로젝트의 프로그램 소스들은 이 저장소 안에 저장이 됩니다. 그리고 소스뿐만이 아니라 소스의 변경 사항도 모두 저장됩니다. 네트워크를 통해서 여러 사람이 접근 할 수 있습니다. 버전 관리 시스템 마다 각각 다른 파일 시스템을 가지고 있으며 Subversion은 Berkeley DB를 사용합니다. 한 프로젝트 마다 하나의 저장소가 필요합니다.

 

체크아웃 : 저장소에서 소스를 받아오는 것입니다. 체크아웃을 한 소스를 보면 프로그램 소스가 아닌 다른 디렉토리와 파일들이 섞여 있는 것을 볼 수 있습니다. 이 디렉토리와 파일들은 버전 관리를 위한 파일들입니다. 임의로 지우거나 변경하면 저장소와 연결이 되지 않습니다. 체크아웃에도 권한을 줄 수 있습니다. 오픈 소스 프로젝트들에서는 대부분 익명 체크아웃을 허용하고 있습니다.

 

커밋(Commit) : 체크아웃 한 소스를 수정, 파일 추가, 삭제 등을 한 뒤 저장소에 저장하여 갱신 하는 것입니다. 커밋을 하면 CVS의 경우 수정한 파일의 리비전이 증가하고 Subversion의 경우 전체 리비전이 1 증가하게 됩니다.

 

업데이트(Update) : 체크아웃을 해서 소스를 가져 왔더라도 다른 사람이 커밋을 하여 소스가 달라졌을 것입니다. 이럴 경우 업데이트를 하여 저장소에 있는 최신 버전의 소스를 가져옵니다. 물론 바뀐 부분만 가져옵니다.

 

리비전(Revision) : 소스 파일등을 수정하여 커밋하게 되면 일정한 규칙에 의해 숫자가 증가 합니다. 저장소에 저장된 각각의 파일 버전이라 할 수 있습니다. Subversion의 경우 파일별로 리비전이 매겨지지 않고 한번 커밋 한 것으로 전체 리비전이 매겨 집니다. 리비전을 보고 프로젝트 진행 상황을 알 수 있습니다.

 

임포트(Import) : 아무것도 들어있지 않은 저장소에 맨 처음 소스를 넣는 작업입니다.

 

익스포트(Export) : 체크아웃과는 달리 버전 관리 파일들을 뺀 순수한 소스 파일을 받아올 수 있습니다. 소스를 압축하여 릴리즈 할 때 사용합니다.

 

1.4 저장소의 디렉토리 배치 #
저장소에 바로 소스를 넣어 프로젝트를 진행 할 수 있습니다. 그렇지만 버전 관리 시스템에서 권장하는 디렉토리 배치 방법이 있습니다.


-- http://svn.samplerepository.org/svn/sample
 +--+---+- branches
    |   +--+- dav-mirror
    |   |  |--- src
    |   |  |--- doc
    |   |  +--- Makefile
    |   |
    |   +--- svn-push
    |   +--- svnserve-thread-pools
    |
    +---+- tags
    |   +--- 0.10
    |   +--+- 0.10.1
    |   |  |--- src
    |   |  |--- doc
    |   |  +--- Makefile
    |   |
    |   +--- 0.20
    |   +--- 0.30
    |   +--- 0.50
    |   +--- 1.01
    |
    +---+- trunk
        |--- src
        |--- doc
        +--- Makefile


위에 보이는 구조는 보통 자주 사용되는 디렉토리 구조입니다. 저장소 디렉토리 아래 branches, tags, trunk 라는 3개의 디렉토리가 있습니다. 이 디렉토리들은 각각의 용도가 있습니다. CVS는 branch와 tag를 위한 명령이 따로 존재 하지만. Subversion의 경우 명령이 있긴 하지만 단순한 디렉토리 복사와 같은 효과를 냅니다.

 

trunk : 단어 자체의 뜻은 본체 부분, 나무줄기, 몸통 등 입니다. 프로젝트에서 가장 중심이 되는 디렉토리입니다. 모든 프로그램 개발 작업은 trunk 디렉토리에서 이루어집니다. 그래서 위의 구조에서 trunk 디렉토리 아래에는 바로 소스들의 파일과 디렉토리가 들어가게 됩니다.

 

branches : 나무줄기(trunk)에서 뻗어져 나온 나무 가지를 뜻합니다. trunk 디렉토리에서 프로그램을 개발하다 보면 큰 프로젝트에서 또 다른 작은 분류로 빼서 따로 개발해야 할 경우가 생깁니다. 프로젝트안의 작은 프로젝트라고 생각하면 됩니다. branches 디렉토리 안에 또 다른 디렉토리를 두어 그 안에서 개발하게 됩니다.

 

tags : tag는 꼬리표라는 뜻을 가지고 있습니다. 이 디렉토리는 프로그램을 개발하면서 정기적으로 릴리즈를 할 때 0.1, 0.2, 1.0 하는 식으로 버전을 붙여 발표하게 되는데 그때그때 발표한 소스를 따로 저장하는 공간입니다. 위에서 보면 tags 디렉토리 아래에는 버전명으로 디렉토리가 만들어져 있습니다.

 

2 Subversion #
Subversion은 CVS를 대체하기 위해 개발되고 있습니다. Subversion은 소스 코드는 물론 바이너리 파일 등의 여러가지 형식의 파일을 관리 할 수 있습니다.

 

2.1 CVS와 비교한 Subversion의 장점들 #
커밋 단위가 파일이 아니라 체인지셋이라는 점입니다. CVS에서라면 여러 개의 파일을 한꺼번에 커밋하더라도 각각의 파일마다. 리비전이 따로 붙습니다. 반면 Subversion에서는 파일별 리비전이 없고 한번 커밋할 때마다 변경 사항별로 리비전이 하나씩 증가합니다.

CVS에 비해 엄청나게 빠른 업데이트/브랜칭/태깅 시간.

CVS와 거의 동일한 사용법. CVS 사용자라면 누구나 어려움 없이 금방 배울 수 있습니다.

파일 이름변경, 이동, 디렉토리 버전 관리도 지원.

원자적(atomic) 커밋. CVS에서는 여러 파일을 커밋하다가 어느 한 파일에서 커밋이 실패했을 경우 앞의 파일만 커밋이 적용되고 뒤의 파일들은 그대로 남아있게 됩니다. Subversion은 여러개의 파일을 커밋하더라도 커밋이 실패하면 모두 이전 상태로 되돌아 갑니다.

양방향 데이터 전송으로 네트워크 소통량(트래픽) 최소화.

트리별, 파일별 접근 제어 리스트. 저장소 쓰기 접근을 가진 개발자라도 아무 소스나 수정하지 못하게 조절할 수 있습니다.

저장소/프로젝트별 환경 설정 가능

확장성을 염두에 둔 구조, 깔끔한 소스


2.2 설치 준비 작업 #
이 장에서는 리눅스, 유닉스 등의 POSIX 호환 운영체제에서 소스를 컴파일하고 설치하는 방법을 다루고 있습니다.

 

Microsoft Windows에서의 사용은 Microsoft Windows에서 사용하기(#s-6) 장을 참조하십시오.

 

각각 리눅스 배포판 및 FreeBSD, NetBSD 등의 전용 패키지에 대해서는 운영체제별 전용 패키지 장을 참조하십시오.

 

설치를 위해 준비해야 할 일.

 

2.3 사용 할 각각의 파일들 구하기 #
Subversion 소스파일 http://subversion.tigris.org subversion-1.1.X.tar.gz
Subversion은 최신 버전을 받습니다.


Apache2 http://httpd.apache.org httpd-2.0.XX.tar.gz
Apache 2 도 최신 버전을 받습니다. 1.3버전은 연동이 불가능 합니다.


Berkeley DB http://www.sleepycat.com/download/index.shtml db-4.2.52.tar.gz
Berkeley DB는 버전을 꼭 4.2.52를 사용하여야 합니다.


OpenSSL http://www.openssl.org/source openssl-0.9.7c.tar.gz
OpenSSL은 LASTEST라고 된 것을 받습니다.


위의 파일들을 /root에 받습니다.

 

3 설치하기 #
Subversion과 연관된 프로그램들을 컴파일 하고 설치하겠습니다.

 

3.1 OpenSSL 컴파일과 설치 #
# tar vxzf openssl-0.9.7c.tar.gz
# cd openssl-0.97c
openssl-0.97c# ./config
openssl-0.97c# make
openssl-0.97c# make install


3.2 Berkeley DB 컴파일과 설치 #
# tar vxzf db-4.2.52.tar.gz
# cd db-4.2.52
db-4.2.52# cd build_unix
db-4.2.52/build_unix# ../dist/configure
db-4.2.52/build_unix# make
db-4.2.52/build_unix# make install
db-4.2.52/build_unix# echo "/usr/local/BerkeleyDB.4.2/lib" >> /etc/ld.so.conf
db-4.2.52/build_unix# ldconfig


3.3 Apache 컴파일과 설치 #
Apache는 설치해도 되고 안 해도 됩니다. 웹으로 저장소를 공개한다거나. http:// 프로토콜을 이용해서 subversion을 이용하고 싶다면 설치하도록 합니다.

# tar vxzf httpd-2.0.52.tar.gz
httpd-2.0.52# ./configure --prefix=/usr/local/apache2 --enable-suexec \
                          --enable-so --with-suexec-caller=bin \
                          --enable-ssl --with-ssl=/usr/local/ssl --enable-cache \
                          --enable-ext-filter --with-z=/usr/include --enable-dav \
                          --with-dbm=db4 --with-berkeley-db=/usr/local/BerkeleyDB.4.2
httpd-2.0.52# make
httpd-2.0.52# make install


3.4 Subversion 컴파일과 설치 #
데비안의 경우 zlib1g-dev, libxml2-dev, libexpat1-dev의 패키지가 필요합니다. 다른 배포판의 경우도 거의 같은 이름으로된 패키지가 있을 것입니다. 이 패키지들은 라이브러리와 헤더 파일을 포함하고 있는 것들입니다.

 

앞에서 Apache를 설치했을 경우

# tar vxzf subversion-1.0.0.tar.gz
# cd subversion-1.0.0
subversion-1.0.0# ./configure --with-zlib --with-ssl=/usr/local/ssl \
                           --with-apr=/usr/local/apache2 \
                           --with-apr-util=/usr/local/apache2 \
                           --with-apxs=/usr/local/apache2/bin/apxs \
                           --with-dbm=db4 --with-berkeley-db=/usr/local/BerkeleyDB.4.2
subversion-1.0.0# make
subversion-1.0.0# make install


Apache를 설치하지 않았을 경우

# tar vxzf subversion-1.0.0.tar.gz
# cd subversion-1.0.0
subversion-1.0.0# ./configure --with-zlib --with-ssl=/usr/local/ssl \
                              --with-dbm=db4 --with-berkeley-db=/usr/local/BerkeleyDB.4.2
subversion-1.0.0# make
subversion-1.0.0# make install


4 세부 설정 #
4.1 저장소 만들기 #
소스를 저장할 공간을 만들어야 합니다. 저장소(Repository)는 프로젝트 마다 하나씩 있어야 합니다. 저장소 안에 프로젝트의 소스가 다 들어가게 되며 다른 프로젝트를 진행한다면 그 프로젝트를 위한 저장소를 하나 더 만들어 주어야 합니다. /home/svn안에 저장소를 만들도록 하겠습니다. 앞으로 저장소를 추가 할 때에는 /home/svn 아래에 추가하면 됩니다. 꼭 /home/svn에 하지 않아도 되며 다른 곳에 해도 됩니다.

 

버클리DB를 이용한 저장소 만들기

# mkdir /home/svn
# cd /home/svn/
/home/svn# svnadmin create --fs-type bdb sample


파일시스템을 이용한 저장소 만들기

# mkdir /home/svn
# cd /home/svn/
/home/svn# svnadmin create --fs-type fsfs sample


svnadmin으로 sample이라는 저장소를 만들면 /home/svn 아래 sample이라는 디렉토리가 생깁니다. 이 디렉토리 안에는 Subversion이 제어하는 파일들이 들어있습니다. 이 디렉토리 안의 파일들은 Berkeley DB 형식으로 되어 있습니다. DB 파일들은 수정하는 일이 없도록 합니다. sample 저장소의 전체 경로는 /home/svn/sample이 됩니다.

 

이제부터 sample 저장소를 계속 사용하여 설명을 하겠습니다.

 

4.1.1 공동 작업을 위한 저장소 그룹 설정 #
svn+ssh://로 작업을 하려면 시스템 계정을 만들어야 합니다. 대부분 계정을 만들고 그룹을 하나로 묶는데. 이럴 경우 그룹에 소속된 사용자들에게도 저장소 쓰기 권한을 주어야 합니다. 그래서 저장소의 그룹 권한을 조정해주어야 합니다. 그룹 쓰기 권한을 주지 않으면 저장소를 만든 계정만 저장소에 접근이 가능하고. 그룹에 속해 있더라도 다른 사용자는 저장소에 접근 할 수 없게 됩니다.

# chmod -R g+w sample


4.2 Apache 설정 #
Apache를 설치했다면 Apache 설정을 해주어야 합니다.

 

Apache가 저장소에 접근할 수 있도록 소유자와 권한을 바꿉니다. Apache는 기본적으로 설치하면 nobody와 nogroup로 실행됩니다.

# cd /home/svn
/home/svn# chown -R nobody.nogroup sample


Apache를 /usr/local/apache2에 설치했으므로 설정파일은 /usr/local/apach2/conf/httpd.conf 입니다. dav, dav_svn 모듈이 설정되어 있는지 확인 합니다. 주석처리 되어 있으면 주석을 없애고 없다면 아래 두줄을 추가합니다.

LoadModule dav_module         modules/mod_dav.so
LoadModule dav_svn_module     modules/mod_dav_svn.so


httpd.conf 파일 맨 뒷부분에 아래와 같이 추가 합니다. 설정을 저장한 뒤에 Apache를 재시작 합니다.

<Location /svn/sample>
  DAV svn
  SVNPath /home/svn/sample
</Location>
이렇게 설정을 하고 웹 브라우저에서 http://(Subversion과 Apache를 설치한 IP주소 또는 도메인)/svn/sample 로 접속을 합니다.

 

웹 브라우저에 아래와 같은 화면이 보이면 Subversion 저장소와 아파치가 잘 동작하고 있는 것입니다. 아래와 같이 나오지 않는다면 아파치 설정과 저장소의 소유자와 그룹을 다시 한 번 살펴보시기 바랍니다.

Revision 0: /

--------------------------------------------------------------------------------
Powered by Subversion version 1.0.0.
위와 같이 설정하면 누구든지(Anonymous) 웹 브라우저로 저장소를 볼 수 있고 Subversion 클라이언트를 이용해서 소스를 체크아웃, 익스포트, 커밋을 할 수 있습니다.

 

이렇게 실행 시켰으면 "# svn checkout http://(Subversion서버 IP또는 도메인)/svn/sample sample"을 입력합니다. "Checked out revision 0."이 나오면 제대로 설정이 된 것입니다. 아무나(Anonymous) 저장소에 접근해서 체크아웃, 커밋 등을 할 수 있습니다.

 

4.2.1 Apache에서 ID로 사용자 인증 #
이제 ID를 통해 인증된 사용자만 소스를 체크아웃하고 커밋 할 수 있도록 설정 하겠습니다.
아파치에 사용할 패스워드 파일을 만듭니다. "# htpasswd -c 패스워드파일명 사용자ID"

# cd /usr/local/apache/conf
/usr/local/apache/conf# ../bin/htpasswd -c passwd sampleuser
New password:
Re-type new password:
"# htpasswd -c"는 패스워드 파일을 처음 만들 때의 옵션이고 사용자를 추가하고 싶을 때에는 "# htpasswd 패스워드파일명 사용자ID" 로 해주면 됩니다.

 

방금 수정했던 /usr/local/apache2/conf/httpd.conf 파일의 맨 마지막 부분에 추가한 부분을 다시 설정 합니다.

<Location /svn/sample>
  DAV svn
  SVNPath /home/svn/sample
  AuthType Basic
  AuthName "pyrasis's Repository"
  AuthUserFile /usr/local/apache2/conf/passwd
  Require valid-user
</Location>
4줄이 추가 되었습니다. AuthType Basic은 Apache 기본 패스워드 인증입니다. AuthName은 패스워드가 걸린 웹페이지에 뜨는 로그인창에 나올 문장입니다. AuthUserFile은 방금 전 만들었던 아파치 패스워드 파일입니다. 절대경로로 적어주어야 합니다. Require valid-user는 인증된 사용자만 볼 수 있게 한다는 것입니다.

 

이제 웹 브라우저로 다시 sample저장소로 접속해 보면 ID와 패스워드를 묻는 창이 나올 것입니다. 만든 ID와 패스워드를 입력하면 저장소를 볼 수 있습니다. 이렇게 되면 체크아웃, 커밋등을 할 때 ID와 암호를 물어보게 됩니다.

 

웹 브라우저로 저장소를 보는 것과 체크아웃은 아무에게나(Anonymous) 할 수 있게 하고 커밋은 지정된 사용자만 할 수 있도록 하려면 httpd.conf에서 설정한 부분을 아래와 같이 바꾸어 주면 됩니다.

<Location /svn/sample>
  DAV svn
  SVNPath /home/svn/sample
  AuthType Basic
  AuthName "pyrasis's Repository"
  AuthUserFile /usr/local/apache2/conf/passwd
  <LimitExcept GET PROPFIND OPTIONS REPORT>
    Require valid-user
  </LimitExcept>
</Location>
이렇게 하면 저장소를 보거나 체크아웃을 할 때는 ID와 패스워드를 묻지 않고 커밋이나 디렉토리. 파일복사 등의 저장소를 변경하는 작업을 할 때에는 ID와 패스워드를 물어보게 됩니다.

 

"# svn checkout http://(Subversion서버 IP또는 도메인)/svn/sample sample" 을 입력하면 ID와 패스워드를 물어옵니다. ID와 패스워드를 입력하고 나서 "Checked out revision 0." 이 출력되면 제대로 설정 된 것입니다.

 

4.3 svnserve를 사용한 서버 #
Subversion의 고유 프로토콜인 svn://을 이용할 수 있는 svnserve를 사용해서 서버 설정을 해보겠습니다. 이것을 사용하면 Apache를 사용한 것보다 체크아웃, 커밋 속도가 더 빠릅니다.

 

svnserve로 서버를 실행 시키면 3690번의 포트가 열립니다. sample 저장소가 /home/svn 아래에 있을 경우

# svnserve -d -r /home/svn/


이렇게 실행 시켰으면 "# svn checkout svn://(Subversion서버 IP또는 도메인)/sample sample"을 입력합니다. "Checked out revision 0."이 나오면 제대로 설정이 된 것입니다. 이것 또한 아무나(Anonymous) 저장소에 접근해서 체크아웃, 커밋 등을 할 수 있습니다.

 

4.3.1 svnserve에서 ID로 사용자 인증 #
Subversion 0.33.0버전 이후부터 svnserve로 ID로 사용자 인증이 가능하게 되었습니다. 그 이전 버전에서 svnadmin으로 저장소를 만들면 저장소 디렉토리 아래에 conf 디렉토리가 생기지 않지만 0.33.0 버전이후에 svnadmin으로 저장소를 만들었다면 저장소 디렉토리 아래에 conf 디렉토리가 자동으로 생성됩니다. 이전 버전에서 먼저 저장소를 만들어 두었다면 저장소 디렉토리 /home/svn/sample 아래 conf 디렉토리를 만들어 줍니다. (/home/svn/sample/conf)

 

이제 각 저장소 디렉토리 아래 conf 디렉토리가 있습니다. /home/svn/sample/conf/svnserve.conf 파일이 svnserve의 설정 파일입니다. 0.33.0 버전 이전 만든 저장소에는 conf 디렉토리 및 svnserve.conf 파일이 없습니다. 그럴 경우에는 conf 디렉토리와 svnserve.conf 파일을 만들어 주면 됩니다.

 

svnserve.conf 파일을 아래와 같이 설정 합니다.

### This file controls the configuration of the svnserve daemon, if you
### use it to allow access to this repository.  (If you only allow
### access through http: and/or file: URLs, then this file is
### irrelevant.)

### Visit http://subversion.tigris.org/ for more information.

[general]
### These options control access to the repository for unauthenticated
### and authenticated users.  Valid values are "write", "read",
### and "none".  The sample settings below are the defaults.
anon-access = none
auth-access = write
### The password-db option controls the location of the password
### database file.  Unless you specify a path starting with a /,
### the file's location is relative to the conf directory.
### The format of the password database is similar to this file.
### It contains one section labelled [users]. The name and
### password for each user follow, one account per line. The
### format is
###    USERNAME = PASSWORD
### Please note that both the user name and password are case
### sensitive. There is no default for the password file.
password-db = passwd
### This option specifies the authentication realm of the repository.
### If two repositories have the same authentication realm, they should
### have the same password database, and vice versa.  The default realm
### is repository's uuid.
realm = pyrasis's Repository


anon-access = none으로 아무에게나(Anonymous) 저장소에 접근하는 것을 막았습니다. read로 하면 읽기만 가능하며 write로 해주면 읽고 쓰기가 가능해집니다.

 

auth-access = write는 ID로 인증된 사용자에게 쓰기 권한을 주는 것입니다.

 

password-db = passwd 이 설정은 svnserve의 패스워드 파일입니다 이전의 Apache 패스워드 파일과는 별개입니다. 아래 내용으로 /home/svn/sample/conf 아래 passwd 라는 이름으로 만듭니다. ID = 패스워드 형식 입니다. 아직 암호화된 패스워드는 지원하지 않는 것 같습니다. 버전 업을 통해 개선 될 것 같습니다.

 

passwd

[users]
sampleuser = 02030104


이제 "# svn checkout svn://(Subversion 서버의 IP또는 도메인)/sample sample" 을 해보면 ID와 패스워드를 입력하라고 나옵니다. 위에서 설정했던 ID와 패스워드를 입력하면 체크아웃이 되며 "Checked out revision 0." 이 나오면 설정이 제대로 된 것입니다.

 

4.4 SSH + svnserve 서버 #
SSH2 데몬으로 svnserve을 터널링 하여 작동시킵니다. 이렇게 되면 svn+ssh:// 프로토콜을 사용하게 되며 사용자 인증은 시스템 계정으로 인증을 합니다. 구동시키는 방법은 따로 있지 않으며 SSH데몬만 떠 있으면 됩니다.

 

클라이언트에서 svn+ssh:// 를 사용하기

 

클라이언트에서 서버로 접속할 ID설정, 각 사용자 계정의 디렉토리에 .subversion이라는 디렉토리가 있습니다. 여기에 보면 config 라는 파일의 맨 마지막에 아래와 같이 추가합니다. ssh -l 서버에 접속할 ID

 

~/.subversion/config

[tunnels]
ssh = ssh -l sampleuser


주의할 점은 IP주소나 도메인 뒤에 저장소의 절대 경로를 적어주어야 합니다. svnserve를 띄워서 /home/svn/과 같이 지정해 주지 않았기 때문에 각 저장소의 절대경로인 /home/svn/sample로 합니다.

# svn checkout svn+ssh://(Subversion 서버의 IP주소 또는 도메인)/home/svn/sample sample


5 실제로 사용하기 #
간단한 예제 프로그램을 통해서 Subversion의 사용법을 알아보도록 하겠습니다. 커맨드 라인 클라이언트을 통해 알아보겠습니다. X 윈도우, MS 윈도우용 GUI 클라이언트 프로그램에 대해서는 뒤에 설명하도록 하겠습니다.

 

5.1 에디터 설정 #
Subversion에서 사용할 기본적인 에디터를 지정해야 합니다. 이것을 지정하지 않으면 커밋 등을 할 수 없게 됩니다.

 

각 사용자 계정의 디렉토리에는 .profile이나 .bash_profile 등의 환경 변수 등을 지정하는 파일이 있습니다. 여기에 아래와 같이 추가 합니다. 여기에서는 에디터를 vim으로 설정 하겠습니다. vim의 경로는 사용자마다 다를 수 있으므로 사용하고자 하는 시스템에 맞게 적어주십시오.

SVN_EDITOR=/usr/bin/vim
export SVN_EDITOR


5.2 기본 디렉토리 만들기 #
앞서 설명 했던 trunk, branches, tags 디렉토리를 만들어 보겠습니다.

 

trunk 디렉토리의 생성, 앞에서 Apache를 통해 설정 했다면 http://를 svnserve로 설정했다면 svn://로 SSH를 사용한다면 svn+ssh://로 하여 서버 설정에 맞게 주소를 적어 주십시오.
apache를 연동한 경우

# svn mkdir http://(Subversion 서버의 IP주소 또는 도메인)/svn/sample/trunk
svnserve만 실행한 경우

# svn mkdir svn://(Subversion서버 IP또는 도메인)/sample/trunk
위처럼 입력을 하면 vim이 실행되면서 아래와 같이 나올 것입니다. :q!로 빠져 나갑니다.

--This line, and those below, will be ignored--

A    http://(Subversion 서버의 IP주소 또는 도메인)/svn/sample/trunk


vim을 빠져 나왔다면 아래와 같이 나오는데(커밋 로그를 입력하지 않으면 아래와 이 나오게됩니다.) c를 누르고 엔터를 치면 디렉토리가 만들어 지게 됩니다.

Log message unchanged or not specified
a)bort, c)ontinue, e)dit


c를 입력한뒤 아래와 같이 나오면 디렉토리 생성은 성공한 것입니다. 이 방법대로 branches, tags 디렉토리도 만듭니다.

Committed revision 1.


만약 read-only에러가 나올 경우 conf/svnserve.conf에서 계정을 만들지 않아서 그렇습니다. anonymous로 사용할 경우 #general, #anon-access = read 가 주석 처리 되어 있는데 주석을 없애고 anon-access = write로 바꾸시면 됩니다.

 

제대로 만들어 졌는지 확인을 하려면 다음과 같이 입력 합니다. list는 저장소 안의 디렉토리와 파일들을 표시해 줍니다.

# svn list http://(Subversion 서버의 IP주소 또는 도메인)/svn/sample
branches/
tags/
trunk/


앞으로 디렉토리 생성, 삭제, 이름변경, 파일, 추가, 삭제, 복사, 이동과 커밋, 등을 할 때 vim이 실행되면서 어떤 것들이 바뀌는지 표시가 됩니다. 커밋 로그를 입력한뒤 vim을 종료하면 커밋이 완료 됩니다. 커밋 로그를 입력하지 않았을 경우 a)bort, c)ontinue, e)dit가 나오게 되는데 c)ontinue)로 계속 하면 됩니다.
 하지만! 커밋 로그 입력은 필수입니다. 소프트웨어 버전 관리에서 가장 중요한 것은 커밋 로그입니다. 어떤 코드를 어떻게 수정했고 디렉토리, 파일을 만들고 삭제 했는지를 꼼꼼히 기록해야합니다. 나중에 소스코드가 바뀌는 흐름을 따라가고자 할때나 문제점(버그)을 추적할때 커밋 로그가 아주 유용하게 이용될 것입니다.

 

5.3 Import #
맨 처음 프로젝트를 시작할 때 저장소에 소스들을 넣어야 합니다. 이럴 때 하는 것이 import 작업입니다. sampledir 이라는 디렉토리를 만든 뒤에 그 아래 다음과 같은 간단한 소스를 작성해 보십시오.

# mkdir sampledir
# cd sampledir
sampledir# vim sample.c


#include <stdio.h>

int main()
{
  printf("Sample Program Version 0.1\n");

  return 0;
}


이 소스를 저장소의 trunk 디렉토리에 import 하겠습니다. 아래 sampledir은 디렉토리입니다. 파일을 적으면 import되지 않습니다. 꼭 디렉토리를 만들고 그 디렉토리를 적어 주십시오. 저장소의 trunk 디렉토리에는 sampledir 디렉토리안의 sample.c 파일만 올라가게 되고 sampledir은 올라가지 않습니다. sampledir 아래 디렉토리를 만들었다면 그 디렉토리는 저장소의 trunk 디렉토리 아래에 올라가게 됩니다.

sampledir# cd ..
# svn import sampledir http://(Subversion 서버의 IP주소 또는 도메인)/svn/sample/trunk
import도 위에서 디렉토리를 만들었을 때 처럼 vim이 실행되게 됩니다. import되는 파일들이 표시됩니다. :q!로 닫고 c를 입력하면 import 되게 됩니다.

 

import가 제대로 되었는지 확인해 봅시다. list 명령을 이용해 trunk 디렉토리에 무엇이 있나 보겠습니다.

# svn list http://(Subversion 서버의 IP주소 또는 도메인)/svn/sample/trunk
sample.c

 

5.4 Checkout #
이제 부터 Subversion을 이용해서 프로그램 소스를 관리 할 수 있습니다. checkout을 해서 어디서든 소스를 받아 볼 수 있습니다. 방금 import를 하기위해 만들었던 sampledir은 지워도 됩니다.

 

svn checkout은 svn co로 줄일 수 있습니다. "svn checkout 저장소주소 로컬디렉토리" 의 형식 입니다.

# svn checkout http://(Subversion 서버의 IP주소 또는 도메인)/svn/sample/trunk sample
A  sample/sample.c
Checked out revision 4.


checkout을 한 디렉토리 안에는 .svn 이라는 디렉토리가 있습니다. 이 디렉토리는 Subversion 저장소 정보가 들어 있기 때문에 지우면 안 됩니다.

 

5.5 Update #
체크아웃 해서 받은 소스를 저장소의 최근 내용으로 업데이트 하는 명령입니다. 체크아웃 해서 받은 소스의 revision보다 저장소의 revision이 높으면 업데이트 하게 됩니다. 업데이트를 하게 되면 전부 다 받아오는 것이 아니라 변경 된 것들만 받아옵니다. 소스를 수정하기 전에 언제나 update 명령으로 소스를 가장 최신 revision으로 맞추고 작업을 해야 합니다.

 

svn update는 svn up로 줄여 사용할 수 있습니다.

sample# svn update


5.6 Commit #
checkout 해서 받은 소스를 수정하고 저장소에 수정된 소스를 적용해 보겠습니다. 이 작업을 커밋(Commit)이라고 합니다.

 

체크아웃 받은 sample.c 소스를 아래처럼 수정합니다.

#include <stdio.h>

int main()
{
  printf("Sample Program Version 0.2\n");
  printf("Hello Subversion\n");

  return 0;
}


이제 커밋을 해 봅시다 커밋 명령은 체크아웃 해서 소스를 받은 디렉토리에서 해야 됩니다. svn commit은 svn ci로 줄여 쓸 수 있습니다. 커밋 명령을 내리면 커밋 로그를 작성하는 에디터가 실행 됩니다. 커밋 로그를 입력한후 저장을 하면 커밋이 됩니다.

sample# svn commit
Sending        sample.c
Transmitting file data .
Committed revision 5.


5.7 Log #
이제 저장소에 어떠한 것들이 변경 되었는지 확인 할 수 있는 log 명령에 대해 알아보겠습니다.

 

log 명령은 체크아웃 받은 디렉토리 안에서 해야 합니다. revision과 날짜, 누가 커밋을 했는지 알 수 있습니다. 여기서는 (no author)로 나옵니다. 이것은 서버 설정에서 아무나 커밋 할 수 있게 하여서 이렇게 나오는 것이고 ID를 통해 인증을 하도록 설정을 했으면 ID가 표시 됩니다.

sample# svn log
------------------------------------------------------------------------
r4 | (no author) | 2003-11-23 14:40:05 +0900 (Sun, 23 Nov 2003) | 1 line


------------------------------------------------------------------------
r1 | (no author) | 2003-11-23 14:39:00 +0900 (Sun, 23 Nov 2003) | 1 line


-----------------------------------------------------------------------
--revision과 -r은 같습니다.

sample# svn log --revision 5:19    # revision 5부터 9까지의 로그를 출력합니다.
sample# svn log -r 19:5            # revision 19부터 5까지 역으로 출력합니다.
sample# svn log -r 8               # revision 8의 로그를 출력합니다.
하나의 파일이나 디렉토리 로그를 볼 수도 있습니다.

sample# svn log sample.c
sample# svn log http://(Subversion 서버의 IP주소 또는 도메인)/svn/sample/trunk/sample.c
-v 옵션은 더 자세한 정보를 얻을 수 있습니다. 아래 M은 Modify(수정)의 표시 입니다. 소스 파일을 수정하고 커밋 했기 때문입니다.

sample# svn log -r 5 -v
------------------------------------------------------------------------
r5 | (no author) | 2003-11-23 14:42:34 +0900 (Sun, 23 Nov 2003) | 1 line
Changed paths:
   M /trunk/sample.c


------------------------------------------------------------------------
A 는 Add(추가) 표시 입니다. trunk라는 디렉토리를 만들었고 sample.c 파일을 import 했기 때문에 A(추가) 표시가 나오게 되는 것입니다.

sample# svn log -v
------------------------------------------------------------------------
r4 | (no author) | 2003-11-23 14:40:05 +0900 (Sun, 23 Nov 2003) | 1 line
Changed paths:
   A /trunk/sample.c


------------------------------------------------------------------------
r1 | (no author) | 2003-11-23 14:39:00 +0900 (Sun, 23 Nov 2003) | 1 line
Changed paths:
   A /trunk


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


5.8 Diff #
diff 명령을 사용하면 예전 소스 파일과 지금의 소스 파일을 비교해 볼 수 있습니다. 위에서 나온 로그와 같이 우리는 revision 4(r4)에서 sample.c를 import 했습니다. 그리고 revision 5에서 소스를 수정하고 커밋 했습니다.

 

최초에 import 했던 소스 sample.c의 revision 4와 수정해서 커밋한 revision 5의 차이점을 diff 명령으로 출력해 보겠습니다. --revision 4만 적으면 현재 revision 5와 비교하게 됩니다.

sample# svn diff --revision 4 sample.c
Index: sample.c
===================================================================
--- sample.c    (revision 4)
+++ sample.c    (working copy)
@@ -2,7 +2,8 @@

 int main()
 {
-  printf("Sample Program Version 0.1\n");
+  printf("Sample Program Version 0.2\n");
+  printf("Hello Subversion\n");

   return 0;
 }
revision 4와 5를 비교 하고 싶으면 --revision 4:5 (-r 4:5)로 하면 됩니다. --revision 8:10 도 가능합니다.

sample# svn diff --revision 4:5 sample.c
Index: sample.c
===================================================================
--- sample.c    (revision 4)
+++ sample.c    (revision 5)
@@ -2,7 +2,8 @@

 int main()
 {
-  printf("Sample Program Version 0.1\n");
+  printf("Sample Program Version 0.2\n");
+  printf("Hello Subversion\n");

   return 0;
 }


여기서 주의할 점은 CVS는 revision을 파일 하나하나에 다 매기지만 Subversion은 파일에 revision을 매기지 않고 소스 수정, 파일 복사, 이동, 삭제 등을 하고 그때 한 커밋으로 revision을 매깁니다. 그래서 다른 파일들이라도 같은 revision 번호를 가지게 됩니다.

 

5.9 Blame #
Blame은 한 소스파일을 대상으로 각 리비전 대해서 어떤 행을 누가 수정했는지 알아보기 위한 명령입니다.
리비전, 커밋한 사용자의 ID, 소스 순서입니다.

sample# svn blame sample.c
     4 sampleuser #include <stdio.h>
     4 sampleuser
     4 sampleuser int main()
     4 sampleuser {
     5 sampleuser   printf("Sample Program Version 0.2\n");
     5 sampleuser   printf("Hello Subversion\n");
     4 sampleuser
     4 sampleuser   return 0;
     4 sampleuser }
     4 sampleuser
여기서는 커밋한 사용자가 한명 밖에 없으므로 전부 똑같이 나옵니다.

 

한 예로 여러사람이 커밋했을 경우 아래처럼 나옵니다.

     4 sampleuser #include <stdio.h>
     4 sampleuser
     4 sampleuser int main()
     4 sampleuser {
     7 epifanes     printf("Sample Program Version 0.3\n");
     6 pyrasis      printf("Hello Subversion\n");
     4 sampleuser
     4 sampleuser   return 0;
     4 sampleuser }
     4 sampleuser


특정 리비전만 지정해서 볼 수도 있습니다. 리비전을 지정하지 않으면 현재 리비전을 대상으로 합니다.

sample# svn blame -r 4 sample.c


5.10 Add #
svn add 명령으로 새 파일을 추가할 수 있습니다.

sample# svn add hello.c
A         hello.c
svn add로 파일을 추가한 뒤에는 svn commit으로 커밋을 해주어야 완전히 파일이 저장소에 추가됩니다.

sample# svn commit
물론 커밋 로그도 입력해야 됩니다.

 

5.11 Export #
체크아웃은 Subversion이 버전관리를 할 수 있도록 각종 파일이 소스 폴더 안에 함께 생깁니다. 이것과는 달리 Export는 순수하게 프로그램의 소스만 가져올 수 있습니다. 만들어진 소스를 압축하여 릴리즈 할 때 사용합니다.

sample# svn export http://(Subversion 서버의 IP주소 또는 도메인)/svn/sample2/trunk sample
--revision (-r)으로 revision을 지정하면 지정한 revision의 소스를 받아옵니다. 지정하지 않으면 가장 최근의 revision의 것을 가져옵니다.

 

5.12 Branch와 Tag #
CVS에서의 Branch와 Tag는 Branch와 Tag를 위한 명령이 있습니다. CVS에서 Branch와 Tag를 하게 되면 저장소의 파일에는 Branch 또는 Tag 되었다는 표시가 함께 붙게 됩니다. 체크아웃 할 때에도 Branch와 Tag의 소스를 받아오려면 Branch, Tag를 지정하는 옵션 주어야 했습니다.

 

CVS와는 달리 Subversion은 Branch와 Tag가 특별한 명령이 있는 것도 아니고 이런 것들을 한다고 해도 저장소에 특별히 Branch, Tag라고 기록이 남는 것도 아닙니다. Subversion에서 Branch와 Tag는 단순한 디렉토리 복사 명령으로 할 수 있고 Branch, Tag를 했더라도 디렉토리 복사와 같습니다.

 

5.12.1 Branch #
Branch를 해야 할 경우는 앞서 설명 했듯이 프로젝트중 작은 분류로 나누어 개발 하거나 소스를 따로 분리하여 실험적인 코드 를 작성할 경우 등 입니다.

 

Subversion에서는 Branch를 copy 명령으로 수행 합니다. trunk의 내용을 Branches안에 새로운 이름으로 복사 하는 것입니다. 체크아웃 받은 소스에서 바로 copy를 할 수도 있고 원격에서 URL로 복사를 할 수도 있습니다. 아래 체크아웃 받은 것은 trunk만 받은 것이 아니고 sample 디렉토리 아래를 전부 받는 것입니다.

svn checkout http://(Subversion 서버의 IP주소 또는 도메인)/svn/sample sample
sample# svn copy trunk branches/sample-branch
sample# svn commit
원격에서 URL로 copy를 하면 commit도 같이 이루어집니다. 체크아웃 받은 소스에서는 update를 해주어야 합니다.

# svn copy http://(Subversion 서버의 IP주소 또는 도메인)/svn/sample/trunk \
http://(Subversion 서버의 IP주소 또는 도메인)/svn/sample/branches/sample-branch
Branch된 소스를 받기 위해서는 branches/sample-branch를 체크아웃 하면 됩니다. trunk와 branche는 따로 revision을 가지지 않습니다. Subversion의 revision은 저장소 전체의 revision입니다.

# svn checkout \
  http://(Subversion 서버의 IP주소 또는 도메인)/svn/sample/branches/sample-branch \
  sample-branch


5.12.1.1 Merge #
위와 같이 우리는 trunk를 sample-branch로 Branch 했습니다. sample-branch를 수정하다가 trunk에도 반영하고 싶다면. merge 명령을 사용하면 됩니다. 하나하나 소스 코드를 옮겨서 입력하지 않아도 됩니다. 다만 merge 한 뒤에는 꼭 사람이 확인을 해 봐야겠죠.

 

sample-branch를 체크아웃 합니다.

# svn checkout \
  http://(Subversion 서버의 IP주소 또는 도메인)/svn/sample/branches/sample-branch \
  sample-branch


sample-branch의 sample.c를 다음과 같이 수정 합니다. printf("Hello World\n");를 추가 했습니다. 그리고 commit을 합니다. 지금 수정된 것은 revision 7입니다.

#include <stdio.h>

int main()
{
  printf("Sample Program Version 0.2\n");
  printf("Hello Subversion\n");

  printf("Hello World\n");

  return 0;
}
이제 sample의 trunk를 체크아웃 합니다.

# svn checkout http://(Subversion 서버의 IP주소 또는 도메인)/svn/sample/trunk sample
trunk의 sample.c는 아래와 같습니다.

#include <stdio.h>

int main()
{
  printf("Sample Program Version 0.2\n");
  printf("Hello Subversion\n");

  return 0;
}
이제 sample-branch의 수정된 것을 trunk에 merge 해 보겠습니다. "svn merge -r N:N 저장소주소 체크아웃된디렉토리" 형식 입니다. 아래는 저장소 주소 하나만 입력되어 있습니다. 이렇게 되면 지금 체크아웃한 소스와 merge를 하게 됩니다. merge할 revision 번호를 주의해 주십시오. 6:7은 r 6과 r 7의 차이점을 뜻합니다. sample-branch의 r 6과 r 7의 차이점을 지금의 체크아웃된 trunk에 적용하라는 것 입니다.

sample# svn merge -r 6:7 \
        http://(Subversion 서버의 IP주소 또는 도메인)/svn/sample/branches/sample-branch
U  sample.c
sample# svn commit
sample# svn update
이제 sample.c를 열어보면 아래와 같이 sample-branch에서 수정한 것이 merge가 되어 있습니다.

#include <stdio.h>

int main()
{
  printf("Sample Program Version 0.2\n");
  printf("Hello Subversion\n");

  printf("Hello World\n");

  return 0;
}


파일 하나만 merge를 할 수도 있습니다.

# svn merge -r 6:7 sample.c


저장소 주소끼리 merge를 할 수도 있습니다.

# svn merge http://(Subversion 서버의 IP주소 또는 도메인)/svn/sample2/trunk \
  http://(Subversion 서버의 IP주소 또는 도메인)/svn/sample2/branches/sample-branch


5.12.2 Tag #
Tag는 만든 프로그램을 웹 사이트 등에 공개할 때 사용합니다. Tag도 Subversion에서는 Branch와 마찬가지로 디렉토리 복사(copy)와 같습니다. tags 디렉토리 안에는 일반적으로 릴리즈(발표)하는 버전별 디렉토리를 만들어 사용합니다.

 

0.1 버전을 발표할 때 0.1 버전의 순간을 tags 디렉토리에 복사하는 것입니다. 0.2가 되었을 때 tags아래 0.2 디렉토리로 복사합니다. 이렇게 되면 각각의 버전별로 소스를 관리 할 수 있습니다. 저장소에서는 실제로 복사가 되는 것은 아니고 변경된 점만 복사하기 때문에 저장소의 용량이 소스코드의 크기만큼 배로 늘어나지는 않습니다.

 

trunk의 소스를 0.1 버전으로 Tag, Branch와 마찬가지로 체크아웃 받은 소스에서도 할 수 있고 원격에서 URL로도 할 수 있습니다. 아래 체크아웃 받은 것은 trunk만 받은 것이 아니고 sample 디렉토리 아래를 전부 받는 것입니다.

# svn checkout http://(Subversion 서버의 IP주소 또는 도메인)/svn/sample sample
sample# svn copy trunk tags/0.1
sample# svn commit


원격에서 URL로 복사합니다. 이 경우 commit도 같이 이루어집니다. 체크아웃 받은 소스는 update를 해주어야 합니다.

# svn copy http://(Subversion 서버의 IP주소 또는 도메인)/svn/sample/trunk \
  http://(Subversion 서버의 IP주소 또는 도메인)/svn/sample/tags/0.1


이제 0.1로 Tag한 소스를 Export로 받아서 압축한 뒤에 릴리즈(공개)를 하면 됩니다.

# svn export http://(Subversion 서버의 IP주소 또는 도메인)/svn/sample/tags/0.1 sample-0.1


5.13 Revert #
소스를 수정하면서 merge를 하다 보면 분명히 잘못 했을 경우가 생깁니다. 이럴 때 하는 것이 revert입니다. revert는 단어 뜻 그대로 되돌리는 명령입니다. 커밋을 하기 전에만 되돌릴 수 있습니다. 커밋 하기전의 체크아웃 받은 소스를 되돌리는 명령입니다. 원격 저장소의 것은 되돌릴 수 없습니다.

sample# svn revert sample.c


5.14 백업 및 복구 #
저장소는 가장 중요한 공간이기 때문에 백업은 필수입니다. 저장소 디렉토리를 그대로 보관할 수도 있지만 백업과 복구 명령을 사용하는것이 편리합니다.
Windows, 리눅스, BSD 등 운영체제에 관계없이 백업 및 복구가 가능합니다. Windows에서 백업한것을 리눅스에서 사용할 수도 있고 BSD에서 백업한 것을 Windows에서 사용할 수도 있습니다.
저장소의 서버를 옮길때에는 저장소 디렉토리를 옮기는 것이 아니라 저장소 백업을 한뒤 그 백업파일을 이용하여 새 서버에서 복구를 하는 방식으로 옮겨야합니다.

 

5.14.1 Dump #
sample 저장소를 백업합니다. 표준 입출력을 통해서 저장소의 내용을 파일로 생성합니다. svnadmin dump 명령을 사용하며 이 명령은 저장소 디렉토리 바깥에서 사용해야 합니다.

repos# ls
sample
repos# svnadmin dump sample > sample.dump


5.14.2 Load #
저장소 백업 파일을 이용해서 저장소를 복구합니다. svnadmin load 명령을 사용합니다.
빈 저장소를 생성한 뒤 백업 파일을 이용해서 복구를 합니다.

repos# svnadmin create sample
repos# ls
sample   sample.dump
repos# svnadmin load sample < sample.dump


6 Microsoft Windows에서 사용하기 #
Microsoft Windows에서도 Subversion을 사용할 수 있습니다. 소스를 컴파일하지 않고 설치 파일을 통해 간단하게 설치해서 사용할 수 있습니다. Windows에서도 리눅스, 유닉스와 똑같은 기능을 사용할 수 있습니다.

 

6.1 설치 파일 구하기 #
Subversion Windows 설치파일

 

Subversion Windows http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91

 

Windows 용 설치 파일을 받습니다. ZIP으로 압축된 바이너리를 사용해도 상관없습니다.

 

svn-1.0.0-setup.exe

 

6.2 설치 #
설치 파일을 받았다면 일반적인 Windows 프로그램을 설치하듯이 설치하면 됩니다. ZIP으로 압축된 것은 적당한 디렉토리에 압축을 해제한뒤 사용하면 됩니다.

 

6.3 사용하기 #
지금 설치한것들은 Subversion 커맨드 라인 클라이언트와 저장소를 네트워크에서도 사용할 수 있도록 하는 서버 프로그램 들입니다. 커맨드라인 사용법은 리눅스, 유닉스와 똑같습니다. 다만 Windows에서는 명령 프롬프트(cmd.exe)에서 사용합니다.

 

ZIP으로 된 바이너리를 사용하려 한다면 명령 프롬프트에서 Subversion의 명령을 실행하기 위해 환경 변수의 시스템 변수 PATH에 Subversion 압축을 해제한 디렉토리를 추가합니다. 설치 파일로 설치했다면 자동으로 환경 변수에 추가됩니다.

 

커밋 로그를 입력할 수 있도록 환경 변수의 Administrator에 대한 사용자 변수에 변수이름 SVN_EDITOR, 값 notepad를 설정합니다. notepad가 아닌 다른 편집기를 이용하려면 편집기의 실행파일의 경로를 지정해 주면 됩니다.

 

저장소 만들기. C:\에 repos라는 폴더를 만들었습니다. 명령 프롬프트를 실행합니다.

C:\Documents and Settings\Administrator>cd c:\repos
버클리 DB를 이용한 저장소

C:\repos>svnadmin create --fs-type bdb sample
파일시스템을 이용한 저장소

C:\repos>svnadmin create --fs-type fsfs sample


체크아웃. svn://, http://를 이용한 체크아웃 방식은 위에서 설명한 방법과 똑같습니다.

 

윈도우 파티션에 있는 저장소에 직접 접근하는 방법.

C:\temp>svn checkout file:///C:/repos/sample


svnserve를 사용한 서버

C:\>svnserve -d -r C:\repos


명령행에서 일일이 실행하는 불편함을 덜어주는 SVNSERVE Manager같은 프로그램을 이용할 수도 있습니다. svnserve의 동작/정지 상태를 트레이 아이콘으로 표시해 주며 시스템 시작시 svnserve를 자동으로 실행 하게 할 수 있습니다.

 

Windows용 Subversion 명령도 리눅스, 유닉스에서의 명령과 똑같습니다. 하지만 Windows에서는 그래픽 클라이언트가 있기 때문에 명령 프롬프트를 사용하는 일은 많지 않습니다. TortoiseSVN을 사용하면 팝업 메뉴를 이용해서 저장소 만들기, 체크아웃, 커밋 등 매우 편리하게 사용할 수 있습니다.

 

7 운영체제별 전용 패키지 #
리눅스 배포판별(Redhat, Debian, SuSE) 전용 바이너리 패키지, FreeBSD 포트 컬렉션, NetBSD pkgsrc, Mac OS X 패키지 등 편리하게 설치할 수 있도록 운영체제별 전용 패키지가 제공되고 있습니다. 이것들을 사용하면 소스를 컴파일 하지 않고 바로 설치해서 사용할 수 있는 장점이 있습니다.

 

운영체제별 패키지는 아래 링크에서 받을 수 있습니다.
http://subversion.tigris.org/project_packages.html

 

8 GUI 클라이언트 프로그램 #
Subversion에서 기본적으로 지원하는 커맨드 라인 명령 svn은 사용하기에 불편한 점이 많습니다. 앞으로 소개할 것들은 MS Windows, X Window 등에서 사용 가능한 Subversion 클라이언트 프로그램 입니다.

 

8.1 TortoiseSVN #
MS Windows용 GUI 클라이언트 프로그램입니다. CVS GUI 클라이언트 프로그램으로 유명한 TortoiseCVS와 거의 같은 인터페이스를 가지고 있습니다.
http://tortoisesvn.tigris.org

 

8.2 Ankhsvn #
Visual Studio .NET 애드인 형식의 Subversion 클라이언트 프로그램입니다. VS.NET과 통합성이 매우 높습니다. VS.NET의 솔루션 뷰에서 커밋, 업데이트 등의 작업이 가능하며 솔류션 뷰의 각 파일에 수정되었거나 수정되지 않은 파일의 상태를 표시해줍니다.
http://ankhsvn.tigris.org

 

8.3 RapidSVN #
크로스 플랫폼 Subversion 클라이언트 프로그램입니다. Windows, 리눅스, BSD의 X Window에서 사용할 수 있습니다.
http://rapidsvn.tigris.org

 

9 웹 인터페이스 #
저장소를 웹브라우저로 편하게 볼 수 있는 인터페이스들입니다.

 

9.1 ViewCVS #
CVS 웹 인터페이스로 유명합니다. 아파치와 mod_python 기반으로 동작하며 Subversion 파이썬 바인딩으로 만들어져 있습니다. 최신버전은 Subversion도 지원하고 있습니다. 유닉스, 리눅스, Windows 모두 사용할 수 있습니다.
http://sourceforge.net/projects/viewcvs

 

윈도우에서 Subversion과 ViewCVS 사용하기

 

9.2 WebSVN #
Subversion 전용 웹 인터페이스입니다. Subversion svnlook과 연동하여 웹으로 표시합니다. 아파치와 php가 필요합니다.
http://websvn.tigris.org


SVN 명령어 설명 참조 : http://develop.sunshiny.co.kr/43

출처 : http://linuxne.springnote.com/pages/381909

'기타' 카테고리의 다른 글

[Hudson] 자동 빌드 설정 방법  (0) 2012.08.10
VPN  (0) 2011.05.03
SVN GUI TOOL[SVN Tool - RapidSVN 사용법]  (0) 2011.02.09
MMAP  (0) 2011.01.27
Source Insight 3.5 에서 한글 주석 읽는 방법  (0) 2011.01.16
이름
mmap, munmap - 
파일이나 장치를 메모리로 대응시키거나 대응을 푼다. 
사용법
#include 
#include 
#ifdef _POSIX_MAPPED_FILES 

void * mmap(void *start, size_t length, int prot , int flags, int fd, off_t offset); 

int munmap(void *start, size_t length); 

#endif 

설명
mmap 
함수는 fd로 지정된 파일(또는 다른 객체)에서 offset을 시작으로 length 바이트만큼을 start 주소로 대응시키도록 한다. 이 주소는 단지 그 주소로 했으면 좋겠다는 정도이며, 보통 0으로 지정한다. mmap는 지정된 영역이 대응된 실제 시작 위치를 반환한다. prot 인자는 원하는 메모리 보호 모드를 설정한다. 해당 비트는 다음과 같다. 
PROT_EXEC 
페이지는 실행될 수 있다. 
PROT_READ 
페이지는 읽을 수 있다. 
PROT_WRITE 
페이지는 쓰여질 수 있다. 
PROT_NONE 
페이지는 접근될 수 없다. 
flags 
인자는 대응된 객체의 타입, 대응 옵션들, 대응된 페이지 복사본에 대한 수정이 그 프로세스에만 보일 것인지 다른 참조하는 프로세스와 공유할 것인지를 설정한다. 해당 비트들은 다음과 같다. 

MAP_FIXED 
지정된 주소 이외의 다른 주소를 선택하지 않는다. 지정된 주소가 사용될 수 없다면, mmap은 실패할 것이다. 만일 MAP_FIXED가 지정되면, start는 페이지 크기의 배수이어야 한다. 이 옵션은 사용하지 않는 것이 좋다. 
MAP_SHARED 
이 객체를 대응시키는 다른 모든 프로세스와 이 대응 영역을 공유한다. 
MAP_PRIVATE 
개별적인 copy-on-write 대응을 만든다. (다른 프로세스와 대응 영역을 공유하지 않는다.) 
MAP_SHARED
 MAP_PRIVATE 중 하나는 반드시 명시해야 한다. 

위 세 플래그는 POSIX.1b에 규정되어 있다.(공식적으로 POSIX.4) 또한 리눅스에는 MAP_DENYWRITE, MAP_EXECUTABLE 그리고 MAP_ANON(YMOUS)도 있다. 

munmap 
시스템 콜은 지정된 주소 공간에 대한 대응을 푼다. 범위내의 주소에 대한 참조 계수를 늘려서 유효하지 않는 메모리 참조로 만든다. 



반환값
성공시, mmap은 대응된 영역의 포인터를 반환한다. 에러시, MAP_FAILED(-1)이 리턴되며, errno는 적당한 값으로 설정된다. 성공시, munmap 0을 리턴하며, 실패시 -1이 리턴되며, errno가 설정된다 (보통EINVAL이 설정된다). 
에러
EBADF 
fd
가 유효한 파일 기술자가 아니다 (그리고 MAP_ANONYMOUS가 설정되어 있지 않다). 
EACCES 
MAP_PRIVATE
가 설정되었지만, fd가 읽을 수 있도록 열려있지 않다. 또는 MAP_SHARED PROT_WRITE가 설정되었지만, fd가 쓸 수 있도록 열려있지 않다. 
EINVAL 
start
 length offset가 적당하지 않다 (, 너무 크거나 PAGESIZE 경계로 정렬되어 있지 않다). 
ETXTBUSY 
MAP_DENYWRITE
가 설정되었으나 fd로 지정된 객체가 쓰기 위해 열려있다. 
EAGAIN 
파일이 잠겨있거나, 너무 많은 메모로가 잠겨있다. 
ENOMEM 
사용할 수 있는 메모리가 없다. 

호환
SVr4, POSIX.1b (formerly POSIX.4), 4.4BSD. Svr4 
문서에는 ENXIO ENODEV 에러 코드가 추가되있다. 
관련 항목
getpagesize(2), msync(2), shm_open(2), B.O. Gallmeister, POSIX.4, O'Reilly, 
페이지. 128-129 389-391. 
역자
정강훈 , 2000 5 14

'기타' 카테고리의 다른 글

[Hudson] 자동 빌드 설정 방법  (0) 2012.08.10
VPN  (0) 2011.05.03
SVN GUI TOOL[SVN Tool - RapidSVN 사용법]  (0) 2011.02.09
SVN  (0) 2011.02.09
Source Insight 3.5 에서 한글 주석 읽는 방법  (0) 2011.01.16

이 내용은 http://blog.naver.com/rshane?Redirect=Log&logNo=10098367070 에서 내용을 가지고 왔습니다.

Source Insight를 실행 -> Project Tab 클릭 -> Open Project 실행 -> Project 목록에서 Base를 실행 -> 첨부파일을 추가 -> Project를 저장.

위와 같은 순서로 하면 됩니다.

'기타' 카테고리의 다른 글

[Hudson] 자동 빌드 설정 방법  (0) 2012.08.10
VPN  (0) 2011.05.03
SVN GUI TOOL[SVN Tool - RapidSVN 사용법]  (0) 2011.02.09
SVN  (0) 2011.02.09
MMAP  (0) 2011.01.27

+ Recent posts