HTML 이벤트 버블링(Event Bubbling) 에 대해서

자바스크립트의 이벤트 처리는 아주 직관적이다.
그 만큼 사용이 간단한 지식만으로 쉽게 사용이 가능하다.

그런데 간혹 이벤트의 발생이 원하지 않는 방향으로 흐를 때가 있다.
특히, 마우스 이벤트 처리시에 자주 발생되는데, 메뉴 드랍다운 UI를 자바스크립트로 구현하면서 많이 겪어봤을 거라고 생각한다.
드랍메뉴 영역에 mouseout을 걸어서 영역을 벗어날 때 사라지게 했는데, 결과는 메뉴 영역의 아이템에 마우스를 갖다대도 사라져 버린다든가...

골치아프다. 이벤트가 왜 이러는거야!

이벤트 버블링에 대해 예제와 함께 좀더 알아보자.
아래와 같은 예제를 준비했다.

div 를 여러개 계층 구조로 겹쳐 두었다.

<!DOCTYPE html>
<html>
<head>
<style>
div margin10px; padding: 10px; background-color: red; }
div div background-coloryellow; } 
div div div { background-color: blue; }
textarea width: 90%; height: 200px; }
</style>
</head>
<body>

<div id="depth1">
<div id="depth2">
<div id="depth3">
</div>
</div>
</div>
<textarea></textarea>
</body>
</html> 

그다음 이벤트 바인딩이다.
div영역에 마우스를 올릴 때, 해당아이디를 텍스트에리어에 출력한다.

window.onload = function(e) {

    var logger = document.getElementsByTagName("textarea")[0];
    function log(newtext) {
        logger.value += newtext + "\n";
        logger.scrollTop = logger.scrollHeight; 
    }
    var divs = document.getElementsByTagName("div");
    for(var i=0; i < divs.length; i++) {
        (function(){
            var div = divs[i];
            div.onmouseover = function(e) {
                if(div.id === "depth1") {
                    log(div.id);
                }
                else if(div.id === "depth2")  {                    
                    log(div.id);
                }
                else if(div.id === "depth3") {
                    log(div.id);
                }
            }
        })();
    }
}


가장 안쪽의 depth3에 마우스를 올려보자.
실행 결과를 보면 아래 영역의 아이디부터 textarea에 출력되는것을 볼 수 있다.

depth1
depth2
depth1
depth3
depth2
depth1

이제 어떤 일이 일어났는지 확인해보자.
먼저 앞으로 쓰일 용어 정의부터 하자

이벤트 핸들러 : 요소에 어떠한 이벤트가 일어날 때 실행되는 함수. 캡처 핸들러와 버블 핸들러로 구분할 수 있다.
요소 : HTML Element

HTML 이벤트 모델에서 이벤트가 실행되는 것은

캡처 (Capture)
버블 (Bubble)

이라는 두 단계가 있다.

캡처는 말 그대로 캡처이다.
이벤트가 뭔가에 의해 발생하였다면 그 이벤트를 캡처하기 위해 이벤트가 발생한 요소를 포함하는 부모 HTML부터 이벤트의 근원지인 자식 요소까지 이벤트를 검사한다. 이때, 캡처 속성의 이벤트 핸들러가 있다면 실행시키면서 이벤트 요소로 접근한다.

이렇게 이벤트의 근원을 아래로 내려가며 찾아가는 단계를 이벤트 캡처링(Event Capturing)이라고 부른다.

이제 캡처가 끝났으니 버블이 발생한다.

이벤트 요소에 도달했다면 이제 다시 이벤트 요소로부터 이벤트 요소를 포함하고 있는 부모 요소까지 올라가며 이벤트를 검사한다.
이때 버블 속성의 이벤트 핸들러가 있다면 실행시킨다.

마우스를 영역에 갖다대면 이벤트는 하나에서만 발생하는것이 아니라 모든 영역에서 발생한다. 가장 안쪽의 div에 마우스를 갖다대면 이벤트의 발생 순서는 안쪽 div부터 바깥쪽의 부모 div로 전파되며 발생한다.

여기서는 모든 div에 이벤트 핸들러를 할당했지만, 이벤트 핸들러가 있든 없든 상관없이 이벤트 처리기는 이벤트를 체크하며 핸들러가 있을 경우 실행시키면서 차례로 상위 요소로 이벤트를 전파시킨다.

사이다등의 탄산 음료를 컵에 담아두면 탄산 기포가 아래에서 위로 올라오는 것을 봤을 것이다. 그것과 같이 이벤트도 자식 요소로부터 부모 요소로 올라오며 실행된다고 하여 이벤트 버블링(Event Bubbling)이라고 부른다.

보통 기본 이벤트 핸들러는 버블 속성이며 W3C 표준에서는 이벤트를 묶을 때 캡처 핸들러인지 버블 핸들러인지 지정할 수 있게 되어 있다.
하지만 인터넷 익스플로러 계열은 캡처 이벤트를 지원하지 않는다.

위의 예제에서도 모든 이벤트 핸들러는 버블 이벤트 핸들러이다.

그럼 위의 예제의 결과를 이해할 수 있을것이다.
  • depth1에 진입하여 아이디를 출력
  • depth2에 진입하여 아이디를 출력하고 이벤트는 버블되어 depth1의 아이디를 출력
  • depth3에 진입하여 아이디를 출력하고 이벤트는 버블되어 depth2, 또 버블되어 depth1 의 아이디를 순서대로 출력
이제 한번 캡처링 이벤트 핸들러를 등록하고 실행 순서가 어떻게 되는지 알아보자.
주의할 점은 아래 예제는 인터넷 익스플로러에서는 동작하지 않는다.

캡처 이벤트를 지원하려면 다음 표준 메서드가 필요하다.


element.addEventListener
target.addEventListener(이벤트타입, 핸들러, 캡처여부);

위의 예제에서 이벤트를 등록하는 부분을 아래와 같이 변경한다.

var divs = document.getElementsByTagName("div");
if(document.addEventListener) {
    for(var i=0; i < divs.length; i++) {
        (function(){
            var div = divs[i];
            if(div.id === "depth1") {
                div.addEventListener(
                    "mouseover", 
                    function(evt) {
                        log(div.id);
                    },
                    true // 이벤트 캡처로 등록
                )
            }
            else if(div.id === "depth2") {
                div.addEventListener(
                    "mouseover", 
                    function(evt) {
                        log(div.id);
                    },
                    false // 이벤트 버블로 등록
                )
            }
            else if(div.id === "depth3") {
                div.addEventListener(
                    "mouseover", 
                    function(evt) {
                        log(div.id);
                    },
                    false // 이벤트 버블로 등록
                )
            }
        })();
    }
}
코드가 복잡해 보이지만 사실 단순한 반복 코드이다.


실행 순서를 예측한 사람이라면 캡처와 버블에 대해 정확하게 이해하고 있는 것이다.
실행 순서는 다음과 같다

depth1
depth1
depth2
depth1
depth3
depth2
  • depth1에 캡처하면서 캡처 이벤트 핸들러 동작, 아이디를 출력
  • depth2에 캡처하면서 depth1 아이디를 출력하고 이벤트는 버블되며 depth2의 아이디를 출력
  • depth3에 캡처하면서 depth1 아이디를 출력하고 이벤트는 버블되며 depth3, depth2의 아이디를 순서대로 출력
이러한 이벤트 동작은 때로 원치 않는 결과를 가져온다.
그러나 이벤트 버블 동작을 막는 방법도 지원한다.
물론 인터넷 익스플로러는 이번에도 따로 논다. 익스폴로러를 죽입시다 익스플로러는 나의 원수

eventObject.stopPropagation() // W3C방식
eventObject.cancelBubble = true; // 인터넷 익스플로러 방식


이벤트 핸들러에서 이벤트 객체의 특정 메서드를 샐행하거나 속성을 수정하면 버블링을 막을 수 있다.

우리가 원하는 이벤트 버블 막기 작업을 위해서는 먼저 이벤트 객가 필요하다. 이벤트 객체는 어디 있을까?

W3C 표준에 따르면 이벤트핸들러에는 첫번째 인자로 이벤트 객체가 전달된다.
그러나 인터넷 익스플로러는 전역 객체의 속성에 이벤트 객체가 바인딩된다.

이벤트 객체를 확인하는 간단한 함수 예제이다.

function alertEventObject(e) {
    var objEvent = e || window.event;
    alert(objEvent + " is Event Object");
}


첫번째 예제의 depth2 이벤트 핸들러 지정 부분을 아래와 같이 수정한다.

else if(div.id === "depth2") {
    var evt = e || window.event;
    if(evt.stopPropagation) {
        evt.stopPropagation();  // W3C 표준
    }
    else { 
        evt.cancelBubble = true; // 인터넷 익스플로러 방식
    }
    log(div.id);
}

그렇다면 실행 결과는 다음과 같이 될 것이다.

depth1
depth2
depth3
depth2
  • depth1에 진입, 아이디를 출력
  • depth2에 진입, depth2의 아이디를 출력하고 이벤트를 버블시키려 하지만 이베트 버블이 막아져 있어 이벤트 전파 종료
  • depth3에 진입, depth3 아이디를 출력하고 이벤트는 버블되어 depth2 의 아이디를 출력, 그뒤 버블이 막혀 이벤트 전파 종료.

이벤트 버블링을 정확하게 이해하고 있어야 복잡한 자바스크립트 어플리케이션을 구현시에 알 수 없는 오류를 줄일 수 있을 것이다.


출처 - http://blog.javarouka.me/2011/12/html-event-bubbling.html





jquery 이벤트 전파 방지


event.stopPropagation()

  • 이벤트 전파 방지

event.preventDefault()

  • 링크,폼등의 기본동작 중지

예제보기 – http://jsbin.com/amized/1/

$(a).click(function(event){
    //동작구현

    //이벤트막고 , 기본동작 중지
    event.stopPropagation();
    even.preventDefault();

    //return false; 로 대체가능

});


출처 - http://uix.kr/archives/1153




Posted by linuxism
,

Git 명령어

OpenSource/Common 2012. 10. 31. 10:49


Git를 포함하여 요즘 DVCS의 매력에 빠져들고 있는 중인데 좀 간단하게 SVN처럼 간단한 사용들만 하다가 본격적으로 DVCS의 장점을 활용해 보려고 공부한 김에 나중에 참고할 수 있도록 내용을 정리합니다.



환경 설정
git config --global --list 
현재 설정정보 조회할 수 있습니다. --global옵션은 전역설정에 대한 옵션이며 현재 프로젝트에만 적용할때는 주지 않습니다.
git config --global user.name "사용자명" 
사용자명을 등록합니다 (필수)
git config --global user.email "이메일주소" 
이메일 주소를 등록합니다. (필수)
git config --global color.ui “auto”
터미널에 표시되는 메시지에 칼라를 표시해줌


git에 대해서 사전에 알아야 될 부분은 아래와 같습니다.

  • git의 저장소는 3가지 단계로 나누어 집니다. 커밋한 소스가 보관되는 저장소와 현재 프로젝트 파일들이 있는 작업트리, 저장소와 작업트리사이의 버퍼영역으로 커밋될 대상이 저장되는 스테이징 영역입니다.
  • git은 빈 디렉토리는 추적하지 않습니다.
  • 형상관리를 하지 않을 파일은 .gitignore 파일 에 추가합니다.
  • HEAD는 현재 브랜치의 가장 최신커밋을 의미한다.
  • 기본원격 저장소를 origin이라고 부릅니다.




기본적인 명령어
git --version
현재 git의 버전을 확인합니다.

git init
현재 디렉토리에 git 저장소를 생성합니다.

git add 파일명
git add는 2가지를 하는데 untracked files의 파일들을 git가 추적하도록 하거나 파일은 수정했지만 아직 스테이징 영역에 올라가지 않은(Changed but not updated) 파일들을 스테이징 영역에 올립니다. -i 옵션을 주면 대화형모드가 시작되며 파일의 일부분만 선택해서 스테이징하는 것이 가능합니다. -p 옵션을 사용하면 -i 대화형모드없이 바로 패치모드를 사용할 수 있습니다.

git commit -m "커밋메시지"
스테이징 영역에 올라가 있는 파일들을 커밋합니다. -m 은 커밋메시지를 주는 옵션으로 여러 줄의 커밋메시지를 쓸 경우 -m 을 여러개 사용할 수 있습니다. -a 옵션을 사용하면 스테이징에 올리는 작업과 커밋을 동시에 할 수 있습니다.(추적되지 않는 파일은 추가하지 않습니다.) -m을 사용하지 않을때 -v옵션을 사용하면 편집기에 커밋하려는 변경사항의 다른점을 보여줍니다. 특정파일만 커밋하려면 마지막에 파일명을 추가해주면 됩니다.

git commit -C HEAD -a --amend
지정한 커밋의 로그메시지를 다시 사용하여 기존커밋을 수정합니다. -c를 사용하면 기존메시지를 수정할 수 있는 편집기를 실행해 줍니다.

git status
커밋되지 않은 변경사항을 조회합니다.

git diff
스테이징영역과 현재 작업트리의 차이점을 보여줍니다. --cached 옵션을 추가하면 스테이징영역과 저장소의 차이점을 볼 수 있다. git diff HEAD를 입력하면 저장소, 스테이징영역, 작업트리의 차이점을 모두 볼 수 있다. 파라미터로 log와 동일하게 범위를 지정할 수 있으며 --stat를 추가하면 변경사항에 대한 통계를 볼 수 있습니다.

git mv 파일명 새파일명
기존에 존재하는 파일을 새파일로 이동합니다. 변경이력은 그대로 유지합니다.

git checkout -- 파일명
아직 스테이징이나 커밋을 하지 않은 파일의 변경내용을 취소하고 이전 커밋상태로 돌립니다. svn에서 revert와 동일합니다.




Branch와 Tag
git branch
현재 존재하는 브랜치를 조회합니다. -r 옵션을 사용하면 원격저장소의 브랜치를 확인할 수 있습니다. 

git branch 브랜치명B 브랜치명A
브랜치명A에서 새로운 브랜치 브랜치명B를 만듭니다. (git에서 기본 브랜치는 master라는 이름을 사용합니다.)

git branch 브랜치명
브랜치명의 새로운 브랜치를 만듭니다.(체크아웃은 하지 않습니다.)

git branch -d 브랜치명
브랜치를 삭제합니다.

git branch -m 존재하는브랜치명 새로운브랜치명
존재하는 브랜치를 새로운브랜치로 변경합니다. 이미 존재하는 브랜치명이 있을 경우에는 에러가 나는데 -M 옵션을 사용하면 이미 있는 브랜치의 경우에도 덮어씁니다.

git tag 태그명 브랜치명
브랜치명의 현재시점에 태그명으로 된 태그를 붙힙니다. git tag만 입력하면 현재 존재하는 태그 목록을 볼 수 있습니다.

git checkout 브랜치명/태그명
해당 브랜치나 태그로 작업트리를 변경합니다. 

git checkout -b 브랜치명B 브랜치명A
브랜치명A에서 브랜치명B라는 새로운 브랜치를 만들면서 체크아웃을 합니다.

git rebase 브랜치명
브랜치명의 변경사항을 현재 브랜치에 적용합니다.

git merge 브랜치명
브랜치명의 브랜치를 현재 브랜치로 합칩니다. --squash 옵션을 주면 브랜치명의 모든 커밋을 하나의 커밋으로 만듭니다.

git cherry-pick 커밋명
커밋명의 특정 커밋만을 선택해서 현재 브랜치에 커밋으로 만듭니다. -n 옵션을 주면 작업트리에 합치지만 커밋은 하지 않기 때문에 여러개의 커밋을 합쳐서 커밋할 수 있습니다.




로그 관리
git log
커밋로그들을 볼 수 있으면 -1나 -2같은 옵션을 주어 출력할 커밋로그의 갯수를 지정할 수 있습니다. --pretty=oneline 옵션을 주면 한줄로 간단히 보여주고 --pretty=format:"%h %s"처럼 형식을 정해줄 수 있습니다. -p 옵션을 사용하면 변경된 내용을 같이 보여줍니다. --since="5 hours" 이나 --before="5 hours"같은 옵션도 사용가능합니다. --graph 옵션을 주면 브랜치 트리를 볼 수 있습니다.

git log 커밋명
해당 커밋명의 로그를 볼 수 있습니다. 커밋명A..커밋명B (마침표2개)와 같이 입력하면 커밋명A이후부터 커밋명B까지의 로그를 볼 수 있습니다. ^은 -1과 동일해서 HEAD^라고 하면 최신바로 이전 커밋이고 HEAD^^^와 같이 쓸 수 있으며 HEAD~3을 하면 HEAD의 3개 이전의 커밋을 뜻합니다.

git blame 파일명
갈 줄 앞에 커밋명과 커밋한 사람등의 정보를 볼 수 있습니다.

git blame -L 10,15 파일명
-L 옵션을 사용하면 10줄부터 15줄로 범위를 지정해서 볼수 있고 15대신 +5와 같이 사용할 수 있습니다. 숫자의 범위 대신 정규식도 사용이 가능합니다.

git blame -M 파일명
-M 옵션을 사용하면 반복되는 패턴을 찾아서 복사하거나 이동된 내용을 찾아줍니다.  -C -C 옵션을 사용하면 파일간의 복사한 경우를 찾아줍니다. -C -C는 git log에서도 사용가능하며 내용의 복사를 찾을때는 git log에서 -p옵션을 사용합니다.

git revert 커밋명
기존의 커밋에서 변경한 내용을 취소해서 새로운 커밋을 만듭니다. -n옵션을 사용하면 바로 커밋하지 않기 때문에 revert를 여러번한 다음에 커밋할 수 있습니다.(항상 최신의 커밋부터 revert해야 합니다.)

git reset 커밋명
이전 커밋을 수정하기 위해서 사용합니다. --soft 옵션을 사용하면 이전 커밋을 스테이징하고 커밋은 하지 않으며 --hard옵션은 저장소와 작업트리에서 커밋을 제거합니다. git reset HEAD^와 같이 입력하면 최근 1개의 커밋을 취소할 수 있습니다.

git rebase -i 커밋범위
-i옵션으로 대화형모드로 커밋 순서를 변경하거나 합치는 등의 작업을 할 수 있습니다.




원격저장소
git clone 저장소주소 폴더명
원격저장소를 복제하여 저장소를 생성합니다. 폴더명을 생략가능합니다.

git fetch
원격저장소의 변경사항 가져와서 원격브랜치를 갱신합니다.
 
git pull
git fetch에서 하는 원격저장소의 변경사항을 가져와서 지역브랙치에 합치는 작업을 한꺼번에 합니다. 파라미터로 풀링할 원격저장소와 반영할 지역브랜치를 줄 수 있습니다.

git push
파라미터를 주지 않으면 origin 저장소에 푸싱하며 현재 지역브랜치와 같은 이름의 브랜치에 푸싱합니다. --dry-run 옵션을 사용하면 푸싱된 변경사항을 확인할 수 있습니다. 로컬에서 tag를 달았을 경우에 기본적으로 푸싱하지 않기 때문에 git push origin 태그명이나 모든 태그를 올리기 위해서 git push origin --tags를 사용해야 합니다.

git remote add 이름 저장소주소
새로운 원격 저장소를 추가합니다.

git remote
추가한 원격저장소의 목록을 확인할 수 있습니다.

git remote show 이름
해당 원격저장소의 정보를 볼 수 있습니다.

git remote rm 이름
원격저장소를 제거합니다.




서브모듈
git submodule
연관된 하위모듈을 확인할 수 있습니다.

git submodule add 저장소주소 서브모듈경로
새로운 하위모듈을 해당경로에 추가합니다. 추가만하고 초기화 하지는 않으며 커밋해쉬앞에 마이나스(-) 표시가 나타납니다.

git submodule init 서브모듈경로
서브모듈을 초기화 합니다.

git submodule update 서브모듈경로
서브모듈의 변경사항을 적용합니다.(저장소의 최신커밋을 추적하지 않습니다.)




기타 명령어
git archive --format=tar --prefix=폴더명/ 브랜치혹은태그 | gzip > 파일명.tar.gz
git archive --format=zip --prefix=폴더명/ 브랜치혹은태그 > 파일명.zip
해당 브랜치나 태그를 압축파일로 만듭니다. --prefix를 주면 압축하일이 해당폴더 안에 생성되도록 할 수 있습니다.

git mergetool
설정에 merge.tool의 값에 있는 머지툴을 찾아서 실행합니다.

git gc
저장소의 로그를 최적화 합니다. 로그가 변경되지는 않고 저장하는 방식만 최적화 합니다. --aggressive 옵션을 주면 더 자세하게 최적화합니다.

git rev-parse --show-toplevel
git 저장소내에서 입력하면 루트디렉토리를 알려줍니다.



Last modified : 2011.08.15


출처 - http://blog.outsider.ne.kr/572#comment28285



'OpenSource > Common' 카테고리의 다른 글

list of PDF software  (0) 2013.03.25
OpenSource 소프트웨어의 개요  (0) 2012.12.29
DVCS(DRCS)  (0) 2012.10.31
OSGi - 서비스 개념  (0) 2012.10.08
OSGi - “Getting started with OSGi”의 번역  (0) 2012.10.08
Posted by linuxism
,

DVCS(DRCS)

OpenSource/Common 2012. 10. 31. 10:46


In computer programming, a distributed revision control system (DRCS), distributed version control or decentralized version control system (DVCS) keeps track of software revisions and allows many developers to work on a given project without necessarily being connected to a common network.



버전 관리 시스템 (버전 관리 시스템)는 컴퓨터 에서 작성, 편집되는 파일 의 변경 이력을 관리하는 시스템. 특히 소프트웨어 개발에서 소스 코드 관리에 이용되는 경우가 많다.

목차

  [ 숨기기 ] 

개요 편집 ]

버전 관리 시스템의 가장 기본적인 기능은 파일의 생성 날짜, 수정 한 날짜, 변경 사항 등의 기록을 보관하기위한 것이다. 따라서 여러 번 변경 한 파일도 과거의 상태와 변경 내용을 확인하거나 변경 이전 상태로 복원하는 것이 용이하게된다. 더 많은 버전 관리 시스템은 여러 사람이 파일의 편집에 관한 상황을 상정하고있다. 상업적 소프트웨어 개발이나 오픈 소스 프로젝트 등에서는 여러 사람이 여러 파일을 각각 편집하는 각 파일의 최신 상태를 알 수 없게되거나 동일한 파일에 대한 변경 내용이 충돌하는 등의 문제가 생기기 쉽다 이 버전 관리 시스템은 이러한 문제를 해결하는 방법을 제공한다. 그러나 버전 관리 시스템을 개인의 파일 관리에 사용하는 것도 가능하다하고, 소스 코드뿐만 아니라 설정 파일이나 문서의 관리 등에도 사용할 수있다이다.

관리 방식 편집 ]

버전 관리 시스템에서는 파일 버전을 데이터베이스에 저장하고,이 데이터베이스를 일반적으로 저장소 라고 부른다.

버전 관리 시스템의 기본적인 이용 방법은 다음 흐름이된다.

  1. 파일을 저장소에 등록한다.
  2. 파일을 저장소에서 로컬로 추출 (체크 아웃)
  3. 로컬 환경에서 파일에 대해 변경.
  4. 변경된 파일을 저장소에 다시 (체크인)

파일이 체크인되면 시스템에서 "언제" "누가" "어떤 변경했다"등이 기록되어 나중에 참조 할 수있다. 또한 필요에 따라 이전 버전을 검색 할 수도있다.

이러한하는 사용자 인터페이스 는 CUI 와 GUI 등 다양하다. 또한, 통합 개발 환경 을 함께 사용할 수있는 것도있다.

저장소 편집 ]

개인의 RCS 등은 만든 파일을 즉시 출시 할 수 있지만, CVS , Subversion 등의 공동 이용을위한 시스템의 경우 먼저 " 저장소 "라는 파일 관리를위한 디렉토리를 준비한다. 저장소 만들기 작업은 기본적으로 시스템 또는 프로젝트 관리자가 수행 작업자는 그에 대한 파일을 커밋 (체크인), 체크 아웃한다.

저장소가 한곳에 집중하는 시스템을 단일 저장소, 여러 물건을 분산 리포지토리한다.

저장소가 손상 파일을 복구 할 수 없게 될 수 저장소의 정기적 인 백업은 필수로되어있다.

체크 아웃 편집 ]

저장소에서 데이터를 꺼내는 것을 체크 아웃이라고 부른다.

CVS 와 Subversion 은 저장소에서 처음 데이터를 가져 로컬에 저장하는 것을 체크 아웃이라고 부른다. 이후에 다시 다른 사람에 의해 업데이트 된 저장소에서 데이터를 추출하여 데이터를 최신 버전으로 유지하는 것은 체크 아웃이라고 부르지 않고, 업데이트 라고 부른다.

Visual Source Safe (VSS)는 저장소에서 파일을 검색뿐만 아니라, 또한 그 파일에 잠금을 체크 아웃 한 사람이 파일을 체크 인 할 때까지 다른 사람이 편집 할 수 없도록되는 것을 체크 아웃 라고, CVS 나 Subversion은 체크 아웃의 정의가 약간 다르다. 그러나 VSS는 소프트웨어의 버전 및 구성에 따라 잠금을 방지 할 수있다.

저장소에서 체크 아웃 한 후 잠시 동안 누군가가 저장소에 최신 버전의 데이터를 커밋 (체크인)하고있을 가능성이 있기 때문에, 충돌, 충돌을 피하기 위해 체크 아웃 한 데이터로 작업 하기 전에 나 커밋 (체크인)하기 전에 반드시 로컬 업데이트 (VSS에서는 새로라고 부른다)하여 항상 최신 상태로 유지하는 것이 좋습니다있다.

체크인 편집 ]

저장소에 파일을 쓰는 것을 체크인이나 커밋이라고 부른다. VSS는 저장소에서 파일을 검색뿐만 아니라, 또한 그 파일에 잠금을 체크 아웃 한 사람이 파일을 체크 인 할 때까지 다른 사람이 편집 할 수 없도록한다.

잠금 방식과 복사 병합 방식 편집 ]

하나의 파일에 대해 다른 변경이 동시에 발생하면 파일의 일관성을 유지할 수 없게되어 버린다. 버전 관리 시스템에서는 이러한 문제를 방지하기위한 시스템이 준비되어 있지만, 그 방법은 크게 두 가지로 나뉜다. 하나가 " 잠금 "을 이용하는 방법이고, 다른 하나는"복사 병합 "을 이용하는 방법이다.

잠금 방식은 사용자가 편집 할 파일에 잠금을 다른 사용자가 편집 할 수 없도록 해두고 편집​​이 완료되면 잠금을 해제한다. 간단하고 확실한 방법이지만, 다른 사용자는 파일의 편집 완료까지 기다려야하고 비효율적. 또한 무책임한 사용자가 파일에 잠금을 그대로 방치 해 버리는 등의 위험성도있다.따라서 그룹의 사용보다 개인의 파일 관리에 적합하다.

복사 병합 방식으로 편집 할 파일을 시스템에서 사용자의 원래로 복사하고이 복사본을 편집한다. 편집 완료 후 수정 한 부분을 시스템 측에 반영하지만,이 작업을 병합이라고 부른다. 다른 사용자의 편집 중에도 시스템에서 복사는 자유롭게 할 수 있도록하는 것으로, 여러 사용자가 동시에 편집 작업을 진행할 수 있으므로 그룹의 이용에 적합하다. 그러나 각 사용자의 변경이 충돌하는 경우에는 병합하는 시점에서 해결해야한다. 일반적으로 변경 내용이 충돌 사실을 사용자에게 알리고 내용을 확인, 수정하는 방법이 채택되는 경우가 많다.

버전 번호, 태그 브랜치 편집 ]

버전 관리 시스템을 이용하는 경우, 파일에 버전 (개정판) 번호가 추가된다. RCS와 CVS 의 경우 일반적으로 1.1에서 시작하여 파일의 편집이 이루어지는마다 마지막 수치가 증가된다. 그럼 당신은 아무것도 지정하지 않고 파일을 체크 아웃 한 경우 최신 파일을 검색하게되는데,이 버전 번호를 이용하여 이전에 편집 한 파일을 추출 할 수있게된다. 시스템에 따라 버전 번호뿐만 아니라 날짜, 시간으로 파일을 체크 아웃 할 수있게된다.

태그는 버전 관리 번호와는 별도로 파일에 특정 이름을 부여하기위한 것이다. 특히 저장소에있는 파일에 대해 일괄 태그를 붙이는 (자주 "친다"이라한다)하여 특정 저장소의 상태를 쉽게 검색 할 수있게된다. 베타 릴리스 판 · 포팅 등 프로젝트의 구분이 붙은 시점에서 태그를 붙일 수 잘 이루어지고있다.

브랜치는 저장소를 분기하는 것으로, 프로젝트를 분기시켜 여러 방향으로 개발을 동시에 진행할 수있다. 대규모 개발 프로젝트에서 "개발 버전" "안정"과 프로젝트의 방향성을 나누고 싶다면에는 효과적이다. 버전 관리 시스템에서 여러 방향으로 나누어 한 지점을 정리하는 기능을 가진 것도있다.

네트워크의 이용 편집 ]

그룹에서 버전 관리 시스템을 이용하면 네트워크의 이용이 필수적이다. 시스템은 고유의 방법이 있지만, 대부분은 다른 인증 시스템을 이용하여 사용자 인증을 수행하고, 통신 경로를 암호화하여 통신의 안전성을 도모하게된다. 통신은 ssh 를 이용하여 안전성을 확보하는 것이 일반적이다.

다른 익명의 시스템을 준비하고있는 것도있다. 인터넷에서 프로젝트를 공개하는 경우에 자주 사용되어 있기 때문에, 개발중인 소스 코드를 프로젝트에 참여하지 않는 사람들에 대해서도 공개했다.

주요 버전 관리 시스템 편집 ]

무료 소프트웨어 (무료 오픈 소스) 편집 ]

독점 편집 ]

  • AccuRev - 스트림이라는 개념을 사용하여 프로세스 지향의 구성 관리 도구. 버그 추적 시스템을 내장한다. 분산 개발, 병렬 개발 등 다양한 개발 프로세스를 스트림으로 표현할 수있다.
  • Alienbrain - 디지털 자산 관리 시스템. 버전 관리 기능 이외에, 구성 관리, 상태 관리 등의 기능이있다. 닌텐도 에서 사용되어 유명해진. 바이너리 데이터, CG 데이터를 불문하고 기록을 자동으로 저장할 수있다.
  • BitKeeper - 예전 Linux 커널 개발에 사용 된 유명 해졌다.
  • Rational ClearCase
  • Code Co-op
  • Perforce - 중앙. 록 방식. Perforce Software가 개발했다. 병합 기능도있다.
  • SCCS (Source Code Control System) - 소스 코드 관리 시스템. AT & T가 개발 한 RCS에 대응하는 프로그램.
  • SourceHaven
  • StarTeam
  • Visual SourceSafe - Microsoft Visual Studio 와 세트로 사용되는 경우가 많은 버전 관리 시스템.
  • Team Foundation Server - 버전 관리 기능 이외에, 작업 관리 기능, 작업 관리 기능, 자동 빌드, 보고서 생성 기능도있는 Microsoft 소프트웨어 개발 프로젝트 관리 서버 제품.

관련 항목 편집 ]


'OpenSource > Common' 카테고리의 다른 글

OpenSource 소프트웨어의 개요  (0) 2012.12.29
Git 명령어  (0) 2012.10.31
OSGi - 서비스 개념  (0) 2012.10.08
OSGi - “Getting started with OSGi”의 번역  (0) 2012.10.08
루씬(Lucene) 개요 및 원리  (2) 2012.09.24
Posted by linuxism
,