• .gitignore 에 아래의 항목을 추가해야 svn의 시스템 파일들이 포함되지 않는다.

*.svn*


  • .svn 밑의 파일들이 git에 포함된 경우 실제파일은 지우지 않고 git내의 색인대상에서만 삭제하는 명령어 ( removing svn system files in git index data instead of doing real data )

$ find . -name "*.svn*" -type f -exec git rm --cached {} \;



XXX is already under version control

분명히 현 repository의 새로운 녀석인데 버전컨트롤대상이라고 한다.

이는 그 디렉토리 밑에 .svn 까지 복사 되었기 때문이다.

따라서 .svn 을 지우고 svn add 를 수행하면 된다.

Tag 생성하기

$ svn copy [source] [target] -m "Message"
   (ex) svn copy http://svn.example.com/project/trunk http://svn.example.com/project/tags/RELEASE-110214 -m "Tag : Release 110214"



참고 사항

  • 특정 태그 이름으로 받은 repository는 해당 tag가 업데이트 하는 내용만 받고 trunk 쪽의 업데이트 내용은 받아오지 않는다. 







간단하게 비교하는거니 
다른 방법으로도 가능하다는 것을 증명하기 위해 성내지 말고
주인장이 이곳에 잘 반영할 수 있게
친절히 커맨트하시기 바랍니다.

  • 마지막 commit 이후 변경된 파일 목록 보기
    • git : git status
    • svn : svn status
    • cvs : cvs diff --brief
  • commit 간 diff 보기
    • git : git diff <commit id>..<commit id> 또는 git diff <commit id>...<commit id>
    • svn : svn diff -r 이전리비전번호:비교할리비전번호

git와는 다르게 svn에서 반복적인 ignore 를 하는 방법은 아래와 같다.

  1. 각 디렉토리마다 ignore pattern을 property로 등록. (Don't forget the last dot)
    • command : svn -R propset svn:ignore [pattern] .
      $ svn -R svn:ignore *.obj .

  2. svn configuration파일에 global-ignores 패턴 등록

svn의 또다른 어메이징한 것은 global ignores로 지정하지 않을 경우 새로운 디렉토리가 생길때마다 저 패턴을 등록해줘야 한다는 것이다. 

어떤 것을 선택하든 번거롭고 깔끔하지 못하다.

역시 svn 은 cvs가 git로 가는 도중의 중간산출물 같다.

결론 : git가 좋다.
  1. 명현 2011.01.25 09:05

    ㅋㅋㅋ git svn 찾다가 이게 나오네요

  1. apr 및 apr-util 컴파일 및 설치http://archive.apache.org/dist/apr/
    • apr configure 설정(default설정 이용)
      $ ./configure
    • apr-util configure 설정(설치경로 : /usr/local/apr-util) :
      $ ./configure --with-apr=/usr/local/apr --prefix=/usr/local/apr-util

  2. neon 컴파일 및 설치http://www.webdav.org/neon/
    • neon configure 설정 (설치경로 : /usr/local/neon) :
      $ ./configure --prefix=/usr/local/neon

  3. subversion 컴파일 및 설치http://subversion.tigris.org/
    • subversion configure 설정
      $ ./configure --with-apr=/usr/local/apr --with-apr-util=/usr/local/apr-util --with-neon=/usr/local/neon


Errors


  • git clone 시 fatal: remote end hung up 발생한 경우 : remote end hung up에는 여러가지 요인이 있을 수 있다. 대부분 remote server의 ssh 포트(20)로의 접근이 불가능 하거나 서버에 public_key를 제대로 등록하지 않아서 발생한 이슈들이 대부분이다. 하지만 본인의 경우에는 scp, ssh 로 remote server로 접속하는데 아무런 문제가 없었다. 오랜시간동안의 사투끝에, 윈도우용 git (msysgit) 를 설치하고, cygwin 패키지를 설치할때도 git 를 설치하였는데 그 둘이 충돌이 나는 거였다. 윈도우용 git를 uninstall 하고 나서 문제가 간단히 해결되었다. 
오역이나 오탈자에 대한 것은 덧글활용을 부탁드리며, 내용수정은 허락하지 않습니다.


각자 나름대로 git의 branch을 개성있게 사용하고 있겠지만, 아래 링크된 곳에서는 저자가 여러 프로젝트를 진행하면서 사용했던 브렌치들을  하나의 모델로 정형화하여 잘 설명하고 있다. 그 중에 branch활용방안에 대한 내용들을 번역 및 요약해본다. 







  • The main branches

    • master
      • 기본적으로 git에서 생성되는 branch.
      • 운용 기준
        • HEAD부분은 제품으로 나갈만큼 안정화되어 있어야 한다.

    • develop
      • 개발시 이용하는 branch
      • 운용 기준
        • 최근 개발 현황이 HEAD에 담겨야 한다.
        • 다음 release를 위한 기능 추가가 이루어 진다.
        • auto build 및 test 대상이 된다.
        • 안정화가 끝나면 master 와 merging되고 release tag 번호가 부여된다.
  • Supporting branches : 수시로 생성과 삭제가 반복되는 branch

    • feature
      • 새로운 기능을 추가할때마다 생성하는 branch
      • Naming : master, develop, release-*, hotfix-* 을 제외한 어떠한 이름도 허용가능
      • 운용 기준
        • develop 에서 branching 하며 완성되고 나면 다시 develop branch로 merging 한다.
        • 새로 추가한 기능이 이점을 줄 수 있을때에만 develop branch로 merging한다.
        • merging을 완료하고 나서 생성된 feature branch를 삭제한다.
        • merging 시 "--no-ff" 옵션을 사용한다. 이 옵션은 merging할때 fast-forward와 함께진행될 때에도 항상 새로운 commit을 생성한다. 이로 인해 feature branch에서 저장했던 예전 작업들에 대한 정보들에 대한 손실을 막을 수 있다. 아래의 그림을 보면 그 차이가 드러난다. 오른쪽의 일반적인 merging은 feature에서 merging된 commit들이 기존에 develop에 있던 commit들과 구분이 안된다.



    • release
      • 새로운 release를 내기위해 준비하는 branch
      • Naming : release-* (*는 니 맘대로 문자열을 의미한다.)
      • 운용 방안
        • develop branch로 부터 가져오고 develop와 master로 merging을 실시한다.
        • release branch 생성후 먼저 버전 올려주는 것을 잊지 말자.
        • minor bugs나 meta-data(버전정보, 빌드날짜 등등) 추가는 허용된다.
        • 해당 번호 release시에 목표했던 feature들이 추가되어 만족할만한 기능이 나올때(develop branch가 다음release를 준비할 만한 상태일 때에...)에 release branch를 생성한다. 다음 릴리즈에서 포함되어야 되는 기능들은 절대로 포함시켜서는 안된다. 네이밍을 할때는 next-release같은 것은 피해야 한다. 그 대신 0.5, 1.2.3 같은 구체적인 수치와 그에 해당하는 기준들을 마련한다.
        • 작업이 완료되면 master로 merging한다.merging 후에는 release정보로 바로 tagging한다. master로의 작업이 완료된 후에는 반드시 develop에도 merging을 실시 한다. merging시에 발생하는 conflict는 해결후 commit 한다.
        • merging이 완료되면 해당 release branch를 삭제한다.

    • hotfix
      • 출시된 제품에서 오류가 발견되어 즉시 해결해야 하는경우 이용하는 branch
      • Naming : hotfix-*
      • 운용 방안
        • master의 해당 태그로부터 가져오고 develop과 master로 merging을 실시한다.
        • hotfix branch생성후 먼저 버전 올려주는 것을 잊지 말자.
        • 완료된 후에는 master 적용후 develop에도 적용해야 한다. 이때, release branch가 있는 경우 develop에 merging 하지 말고 release에 한다. 왜냐하면 release시에 테스트가 수반되고, release작업이 완료된 경우 release branch가 다시 develop에 적용되기 때문이다.
        • merging이 완료되면 해당 hotfix branch를 삭제한다.

+ Recent posts