조엘 스폴스키의 Mercurial 튜토리얼

권순선의 이미지

http://hginit.com/

굉장히 깔끔하네요. 분산형 버전관리에 관심있는 분들께 좋은 참고가 될 듯...

p.s. git과 hg 중에 어떤 것을 더 선호하시나요?

madman93의 이미지

왜냐하면 hg는 아직 써 보질 않았습니다. ;)
---------------------------------------------
git init
git add .
git commit -am "project init"
---------------------------------------------

---------------------------------------------
git init
git add .
git commit -am "project init"
---------------------------------------------

feanor의 이미지

hg를 선호합니다. 둘 다 써봤지만 먼저 써본게 익숙해서 그런 것 같습니다.

magingax의 이미지

감사합니다.
좋은글입니다..

LISP 사용자모임
http://cafe.naver.com/lisper

LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr

이응준의 이미지

hg가 git보다 쓰기 편하더군요.

좋은 점
* 리비전을 숫자로(도) 지정할 수 있다는 점
* rollback 기능

별로 안 좋은 점
* mv로 파일을 옮겼을 때 히스토리가 매끄럽게 이어지지 않음. (SVN보다) 예를 들어 파일을 옮기기 전의 change log를 보려면 -f옵션을 줘야합니다.

lacovnk의 이미지

깔끔하네요. 그러나 전 git을 쓰고 있습니다 :)
rails 개발하다보니 이 바닥은 git이 대세... (rails 자체도 git 이용)

auditory의 이미지


정말 깔끔한 소개네요.. ^^
그런데 윈도기반이라 좀 헷갈리는 면이 있네요.. (dir, type...)

그런데 central repostiroy의 directory structure는 어떻게 구성하는게 보통인가요?

svn같은 경우라면 trunk,branch,tag가 있고,
trunk밑에 여러개의 directory를 만들어서 관리했는데,
hg에서는 그런 개념 자체가 없는건가요?

그냥 작업디렉토리에서 init, add, commit하라고하니,
그런 디렉토리를 정하는 기회가 없어보이는데요...

이미 제가 "brain damaged"된 상태인건가요...

bushi의 이미지

svn 엔 branch 도 없고 tag 도 없다고 생각하시면 정확합니다.

OTL

auditory의 이미지

그러면, client쪽에서 central repo에 새로운 디렉토리를 만드려면 어떻게 해야할까요?

현재 svn에서는 하나의 큰 repo에 여러개의 프로젝트를 올려서 쓰고 있는데요..

현재 구조를 유지하고 싶은데요..

main repo
 - dir1
 - dir2
 - dir3 - subdir1
        - subdir2

client쪽에서 subdir을 만들어서 share하고 싶은데,

hg push http://server/repo/newdir
처럼 push하려고 하는데, 잘 안되네요..

나는오리의 이미지

trunk,branch,tag는 CVS에서 쓰던 개념이고
SVN은 그런 개념은 없어졌다고 보시고 편의상 그렇게 만들어 쓴다고 생각하시면 됩니다.
필요하다면 trunk,branch,tag를 만들어서 구분지어 쓰시면 됩니다.

저도 SVN쓰는데 그냥 trunk,branch,tag디렉토리를 root바로 아래에 만들어서
각자 구분해서 씁니다.

lagendia의 이미지

github때문에 git를 선호해요.

ageldama의 이미지

http://bitbucket.org/

용량도 더 많이줘서 좋더라구요. ^^;

아참... hg써요.

git은 복잡해서 저한텐 힘들어효...;

----
The future is here. It's just not widely distributed yet.
- William Gibson

----
The future is here. It's just not widely distributed yet.
- William Gibson

johan의 이미지

Hg view와 hg strip 정도만 더 있으면 툴 사용법은 충분하겠고 다만 개발 프로세스에 대한 부분이 나와주었으면 거의 완벽할 뻔 했네요.
저라면 그런 것을 더 중시할 것 갔네요. 프로세스 문맥을 중심으로 한 툴 사용법.
(얼마전 회사에서 나눠준 아이폰으로 글을 적다보니 좀 이상하네요)

totohero의 이미지

hg를 선호합니다. 먼저 써본 탓도 있겠고, 윈도우즈 환경에서도 쉽게 쓸 수 있어서요. 리눅스라면 속도면에서 git이 낫지 않을까 예상합니다만...

hongminhee의 이미지

Subversion에서 쓰던 명령어랑 비슷해서 저한테는 hg가 더 편한 것 같습니다. 근데 git의 GitHub는 확실히 부럽습니다.

홍민희 (VLAAH, LangDev)

lacovnk의 이미지

git의 경우 http://gitorious.org/ 와 같이 git 기반 개발 포탈(?)을 자체 구축할 수 있습니다 (gitorious가 오픈소스..)

trac+svn 에서 벗어나려고 생각 중인데, hg 쪽에도 이런 툴이 있다면 함께 고려해보려고 하는데 잘 못찾겠네요.

혹시 아는 분 부탁드립니다 :)

hongminhee의 이미지

Gitorious가 오픈소스인 점은 정말 대단하지만, 개인이나 팀 수준에서 쓰는데 그런 포털 규모까지 필요할까요? 대충 Trac 같은 걸 잘 쓰셔도…

홍민희 (VLAAH, LangDev)

lacovnk의 이미지

안그래도 git+svn 쓰면서 개인 로컬 용으로 git, 공동 작업용으로 svn+trac을 쓰는 것을 고려하고 있긴 합니다.
gitorious에 issue/ticket system이 없는 것도 좀 망설여지고요..
하지만 여러 프로젝트 모아서 관리할 수 있고 git 지원이 좋다는 점도 무시할 수 없더군요.

양쪽에 일장일단이 있어서 고민이 되네요 -_-

jinserk의 이미지

redmine 좋아요.
debian 의 경우 패키지까지 있어 한큐에 설치되지요.
현존하는 모든 CVS 를 다 쓸수 있구요.

Leo.

Leo.