note

git 써보니 좋은 점 하나

git status했을 때 변경된 파일이 현재 기준으로 상대 경로로 출력된다.
mercurial에서는 항상 repository의 홈 기준으로 경로를 출력해서 파일을 열때 귀찮았는데 git은 그런 점은 좋네.

아직 hg outgoing, incoming 에 대응되는 명령어를 잘 몰라서 제대로 사용하지 못하고 있지만…

note

불안불안

알 수 없는 이유로 개발 서버에 만든 mercurial repository에 push가 안되는 문제때문에 그냥 수동으로 파일을 관리하고 있다. 너무 불편하다. 시뮬레이션 서버와 개발 서버간에 소스를 매번 일일이 옮겨야 하고.

빨리 git을 배워서 바꿔봐야겠다.

note

mercurial vs. git

mercurial를 사용하다 git을 사용하니 기존에 mercurial에서 사용하던 명령어가 어떻게 매칭되는 지 잘 모르겠다.

hg incoming 명령어가 아주 유용했는데 git에는 없는 듯하고, hg diff -r revision으로 특정 revision하고 비교하는 기능도 많이 사용했는데 git에서 아직 못 찾겠고. 없을 리가 없는데.

결정적으로 분명히 git push를 했는데 왜 origin repo에 반영이 안되는 걸까?

note

hg serve랑 유사한 git 명령은?

git daemon.

단 차이점이 있는데 hg serve는 mercurial repository에서만 실행할 수 있기 때문에 2개 이상의 repository가 있으면 각각의 위치에서 별도로 실행해야 한다. 덕분에 port 번호도 2개 이상이 필요.

하지만 git daemon 명령은 git repository 가 모여있는 상위 디렉토리에서 한번만 실행하고, 원격 머신에서 clone등의 작업을 할 때 주소에 directory 이름만 추가하면 되기 때문에 하나의 port만을 사용해도 여러 repository를 동시에 서비스 할 수 있다.
git daemon 훨씬 편한 듯한데. 대신 git 프로토콜을 사용. hg serve는 http를 사용하기 때문에 웹 브라우저에서도 보기 쉬운데. git에서 http를 사용하고 싶으면 gitweb같은 걸 써야 한다고

git daemon —reuseaddr —base-path=. —export-all —verbose —port=9000
git clone git://1.1.1.1:9000/project_a/.git project_a
git clone git://1.1.1.1:9000/project_b/.git project_b

study

Workflow with Mercurial named branch

Feature separation through named branches

For Whom?

If you want to develop features collaboratively and you want to be able to see later for which feature a given change was added, then this workflow might be right for you.

Note: If you have a huge number of small features (2000 and upwards), the number of persistent named branches can create certain performance problems. For features which need no collaboration or need only a few commits, this workflow also has much unnecessary overhead. It is best used for features which will be developed side by side with default for some time (and many commits), so tracking the default branch against the feature is relevant. To mark single-commit features as belonging to a feature, just use the commit message.

Note: The difference between Mercurial named branches and git branches is that git branches don’t stay in history. They don’t allow you to find out later in which branch a certain commit was added. If you want git-style branching, just use bookmarks.

What you need

Just vanilla Mercurial.

Workflow

To start a new feature,

1. first start a new branch with the name of the feature starting from default.

hg branch feature-x

# do some changes

hg commit -m “Started implementing feature-x”

 

2. Then commit away and push whenever you finish something which might be of interest to others, regardless how marginal. If you want to hack on a feature started by someone else, or you want to switch between features, just update to the feature.

hg update –check feature-x

# do some changes

hg commit -m “Improved X”

Note: The short form of hg update –check feature-x is hg up -c feature-x.

 

3. Merge default into your feature as often as possible.

hg update feature-x

hg merge default

hg commit -m “merged default into feature-x”

 

4. When your feature is stable, merge it into default.

hg update default

hg merge feature-x

hg commit -m “merged feature-x”

 

5. When the feature is done and needs no more work, close the branch.

hg update default # start from default, automatic when using a fresh clone

hg branch feature-x

# do some changes

hg commit -m “started feature X”

hg push

# commit and push as you want

hg update default

hg merge feature-x

hg ci -m “merged feature X into default”

hg commit –close-branch -m “finished feature X”

 

6. To improve a feature after it was officially closed, first merge default into the feature branch (to get it up to date), then work just as if you had started it.

hg up feature-x

hg merge default

hg ci -m “merged default into feature X”

# commit, push, repeat, finish

Generally merge default into your feature as often as possible.

via Workflows – Mercurial.

note

Archiving with Mercurial

Archiving with Mercurial | Didactic Code.

Merurial에서 meta 정보 없이 소스 코드만 export하기. 옵션을 지정하면 압축 파일 형태로 export됨

hg archive ../release_20120125

등록된 소스 코드를 release_20120125 디렉토리에 export함.

hg archive -t "tbz2" release/abcd_20120125.tgz2

등록된 소스 코드를 tbz2 형태로 release 디렉토리에 abcd_20120125.tgz2 파일로 생성

더 자세한 내용은

hg -v help archive

참고

me2day

Mercurial workflow #2

출처 : http://blogs.sun.com/tor/entry/mercurial_tip_checking_in_regularly

mercurial을 써서 co-worker와 작업을 잘 하고 있는데 가끔은 code를 push하려고 할대 이해할 수 없는 메시지를 만날 때가 있다.
# hg merge
abort : outstanding uncommitted changes

한번은 어찌 어찌해서 처리는 했는데 오늘 또 그걸 당하니 원인도 모르겠고.
그래서 구글링 해서 위 페이지를 찾았다.

요는 코드 수정하는 clone과 sync용 clone을 분리한다는 거.

1. 우선 2개의 clone을 생성한다.
2. 작업용 clone에서 hgrc파일에서 default 항목을 막아서 실수로 직접 push할 수 없게 한다.
3. 작업용 clone 에서 실컷 작업한다.
4. sync용 clone에서 작업용 clone에서 편집한 내용을 가져온다.(pull)
[sync] $ hg pull ../work && hg update
5. sync용 clone에서 main repository의 내용을 pull하여 최선 결합(?) 버전을 만든다.
[sync] $ hg fetch
혹은
[sync] $ hg pull && hg merge && hg ci -m “merged”
6. sync용 clone에서 main repository로 push한다.
7. 작업용 clone에서 sync용 clone 의 최신 내용을 가져온다
[work] $ hg pull ../sync

2가지 질문 점.
1. 왜 이 방법은 문제가 없을까? sync clone에서는 단지 2개의 서로 다른 변경내용을 합치기만 해서???
2. 작업용 clone의 default를 main repository가 아니라 sync용 repository로 변경하면 안되나???