subversion 에서 mercurial(hg)로 옮겨갈만 한가요?
글쓴이: freezm7 / 작성시간: 월, 2009/11/09 - 3:15오후
팀원들이 아무도 버전 관리라는 것을 몰라서 세미나를 하려고 하는 상황입니다.
(IT 전문 기업이 아니라서, 버전 관리 툴 없이도 어떻게 어떻게 개발을 해오셨더군요. 저는 입사한지 얼마 안됨)
저는 subversion 을 4~5년 가까이 써온 탓에 익숙한데요,
세미나를 하려면 아무래도 더 최신의 툴을 소개하고 쓰는 것이 낫지 않을까 싶어서요.
Mercurial을 많이 쓰시는 것 같은데,
Subversion 이랑 비교해서 어떨까요?
제가 일하는 환경은 한 프로젝트에 2~5 명 정도 규모입니다.
그러니까 성능보다는 편의성 위주로만 평가해주시면 될 것 같네요.
조언 좀 부탁드려요.
(TortoiseSVN 과 TortoiseHg 간에 비교라고 생각하시면 될 것 같아요. 코맨드 라인 툴을 쓸일은 없을 것 같습니다.)
Forums:
mercurial에서 svn으로 옮겨간 사람입니다.
svn이 더 좋습니다.
머큐리얼은 지정한 폴더 이외에 st라든지 commit 그외 아무것도 안됩니다.
무조건 commit도 전체적으로 해야되고 업데이트도 전체적으로 해야됩니다.
svn에 한표
--
다 쓰고 보니 맨밑에 코맨드 라인 안쓰신다고 하신걸 못봤습니다.
윈도우즈용은 별반 차이 없는것 같습니다. 제가 자세하게 안써봐서 잘 모르겠네요.
위대한 한글
위대한 한글
말씀하신 대로 svn
말씀하신 대로
svn status는 현재 디렉토리 안쪽의 상태만 체크할 수 있는데 반해,hg status는 리파지토리 루트를 기준으로 모든 변화를 보여줍니다. 하지만 이게 Mercurial로 변경하면 안되는 이유가 되기엔 너무 사소한 것 같고요. (원하면hg status | grep '^...'해서 써도 됩니다.)hg commit이 부분적으로는 안된다는 것은 거짓입니다. 부분 커밋 잘 됩니다. 파일 단위 커밋도 됩니다.svn update와 달리hg update는 리파지토리 전체를 업데이트한다는 말씀은 사실입니다. 하지만svn update가 부분 디렉토리에 한해서 작동하게 되어 있는 것은 기능이라기 보다는 중앙 집중식 형상 관리의 한계 때문에 나온 “해결책”입니다. Subversion에서야 별거 아닌 작업 단위를 위해 브랜치를 찢는게 애매하니, 하나의 워킹 디렉토리 안에서 둘 이상의 작업 단위를 동시에 진행하다보니 그런게 필요해지는 거죠. 작업 단위 각각이 서로 다른 파일만을 건드리면svn update부분적으로 적용하고svn commit도 부분적으로 해서 어떻게든 하면 되지만, 하나의 파일에 대해 작업을 해야 하면 어떡하나요. 이건 근본적인 해결 방법이 아닙니다. Mercurial은 분산형 버전 관리 시스템이므로 작업 단위만큼 리파지토리를 복제해서 작업한 다음, 나중에 한번에 머지하면 됩니다.—홍민희 (VLAAH, LangDev)
서브버전 저장소들이
서브버전 저장소들이 한 저장소에 여러 프로젝트를 몰아 넣고 한 프로젝트씩 커밋해서 쓰는 걸 권장(!)하는 경향이 좀 있습니다만, 개인적으로는 이 모델이 서브버전의 한계(저장소를 넘나드는 명령이 어렵다는 점) 안에서 생겨난 것이므로 분산 버전관리 시스템에서 이 모델을 쓰는 것은 권장하지 않습니다.
만약 한 프로젝트인데도 너무 커서 부디렉토리 하나만을 체크아웃해야 한다거나 하는 상황이라면, 저는 먼저 프로젝트를 여러 개로 쪼개는 것을 고려해 보겠습니다. 그래도 꼭 필요하다면 forest 확장 또는 (머큐리얼 1.3 이상에 시범적으로 추가된) 부저장소(subrepo) 기능을 고려해 보시길 바랍니다. 어느 쪽이든 저장소를 여러 개로 나눈 뒤 이어 붙이는 느낌이라는 건 변하지 않습니다만.
일단 분산형 버전
일단 분산형 버전 관리 시스템이 필요한지를 점검해보세요. 제 생각에 대부분의 경우 크게 필요는 없다고 하더라도 DVCS가 유용하긴 합니다. 이를테면 서비스 개발이라서 여러 작업 단위가 동시에 진행되는 경우가 많다면 충분히 필요하다고 볼 수 있습니다. 만약 필요하지 않다면 쓰시던 Subversion이 더 심플한 해결책입니다.
만약 DVCS가 필요하다면, Subversion에 익숙하다고 하셨으니 Git보다는 Mercurial을 추천합니다. (저 같은 경우 Subversion을 쓰던 사람에게는 Mercurial을 추천하고, 아예 VCS를 처음 써보는 사람에게는 Git이나 Darcs를 권하는 편입니다.)
—홍민희 (VLAAH, LangDev)
그냥 사용자적인
그냥 사용자적인 측면에서 봤을 때 pull 과 push 의 과정이 더 생겼다고 생각하시면, 별 큰 차이 못 느끼실 겁니다.
저같은 경우는 svn 을 잘 사용하고 있다가, 사용하는 네트워크 망에서 svn 포트 및 webdav 를 막아버려서,
어쩔 수 없이 HTTP 로만 사용가능한 mercurial 로 옮긴 케이스인데, 그냥 svn 쓰는 느낌으로 잘 쓰고 있습니다.
tortoiseHg, 커맨드 라인 둘 다 사용하는 데 특별히 애로사항은 없네요.
개인적으로 hg 를 쓰면서 svn 에 비해 commit 의 부담이 적었고..
메인 저장소 서버가 접근이 안되는 상황에서도 버전 관리 시스템의 장점을 이용할 수 있었던 점이 좋았습니다.
---
Emerging the World!
Emerging the World!
한글 GUI를 원하신다면 SVN을...
하지만 작업규모가 커지면 SVN은 좀 짜증나는 듯...
5명이라도 binary 올리면 SVN server & client의 부담이 장난아니게 커지는 느낌이예요.
이건 제 computer 문제인 듯...
회사에서 SVN 쓰는데 TortoiseSVN Cache가 무려 200MB memory를 먹네요... 뭐냐, 이놈은...
저도 subversion 말고
저도 subversion 말고 다른 것을 써볼까 고민중입니다.
특별히 subversion 에 불만이 있어서는 아니구요. 재미 내지는 경험 삼아서^^;
git 는 어떤가요? 리눅스 커널을 관리한다니 쓸만 할 듯해서 말입니다.
git나 mercurial 류의
git나 mercurial 류의 분산 버전 관리 시스템은 두 가지 경우에 유용합니다. 하나는 IDE를 이용하지 않을 때입니다. 로컬 작업 환경에서의 히스토리를 기록할 수 있기 때문이죠. 하지만 이클립스 등의 IDE를 쓴다면 IDE에서 어느 정도 로컬 히스토리를 관리해주기 때문에 이런 필요성이 줄어들죠.
또 하나의 경우는 다시 병합하지 않을 브랜치를 여러 개 만들어야 할 때입니다. set of solution 등의 전략을 취할 때 쓸 수 있죠. 여러 개의 브랜치로 실험을 해보고, 그 중에 하나를 선택하는 전략, 이럴 때 유용합니다.
반대로 말하면, 이런 경우가 아닐 때는 중앙집중식이 좋습니다. 아무래도 알아야 하는 개념이 더 적은 만큼, 더 쉽죠. svn, cvs 등은 보통 commit, update, conflict & merge 세 가지만 정확하게 알면 실수 없이 쓸 수 있습니다.
참고로, LSD에서는 커밋하지 않은 코드, 머지되지 않은 브랜치 등을 재공재고로 분류합니다. 아시다시피, 재고는 적을수록 좋은 것이죠. 이런 관점에서 버전 관리 시스템을 쓴다면 분산 버전 관리 시스템의 필요성이 별로 느껴지지 않을 것입니다. 팀원 간에 자주, 원활하게 소스가 공유되고, Collective Code Ownership이 있는 팀이라면 분산 버전 관리는 거의 필요 없죠.
리눅스 커널에서 git가 유용한 것은 커널 해커들은 커널 소스를 받아서 자신만의 커널도 만들어보고, 다양한 실험을 해보고 싶어하기 때문입니다. 게다가, 대부분 vi, emacs 등으로 개발하기 때문에 이클립스의 로컬 히스토리 같은 지원을 받을 수 없죠. 또, 세계 각국에 개발자가 흩어져 있다보니 소스 저장소의 접속 상태도 들쭉 날쭉 합니다. 이럴 때는 git나 mercurial 같은 방식이 유용할 수 있습니다.
요즘 git, mercurial 등을 쓰는 게 약간 유행을 타는 느낌이 있습니다. 우리 회사, 우리 팀에 잘 맞는지 꼼꼼히 따져보시고 도입하시기 바랍니다.
DVCS의 필요성이 크게
DVCS의 필요성이 크게 없다 하더라도 DVCS를 일반적인 VCS에 비해 선호할 이유는 충분하다고 생각합니다. DVCS는 "분산 모델"을 지원하는 것 뿐이지 "분산 모델"을 요구하는 것이 아니기 때문입니다 --- 비록 현재는 필요하지 않다 하더라도 추후에 필요할 때 훨씬 넓은 개발 모델의 선택을 제공한다는 점에서 "처음부터" DVCS를 익히는 것이 나쁜 선택이라 생각하지는 않습니다.
현실적인 얘기를 하면, git나 hg의 GUI 지원은 아래에서 여러 분이 지적해 주셨듯 약간 모자랍니다. 제가 hg 사용자라서 hg 쪽만 얘기하자면, TortoiseHg는 큰 무리 없이 쓸 수 있긴 하지만 약간 비직관적인 인터페이스가 아직 남아 있고 몇 가지 코너 케이스에서 프로그램이 죽는 경험을 해 봤습니다. (저는 GUI를 많이 쓰지 않기 때문에 요즘도 이런지는 잘 모르겠습니다만) 만약 명령줄 인터페이스로만 한정한다면, hg의 인터페이스는 svn의 그것에 뒤지지 않으며 어떨 때는 오히려 더 직관적이기까지 합니다. 특히 merge의 영역으로 넘어 가면 hg merge의 압승입니다. (저는 svn merge의 옵션을 몇년동안 써 왔는데도 아직도 자주 까먹습니다.) svn과 hg를 비교했을 때 명령이 하나 차이가 난다면 commit과 push의 분리일텐데, 이는 제가 위에서도 언급했던 것 같지만 commit을 자주 하도록 권장하는 게 옳으므로 큰 문제는 되지 않는다고 생각합니다. (커밋 자주 하는 것이 collective code ownership에 배치된다고 보진 않기 때문에)
앞으로 TortoiseHg가 충분히 안정화되어 TortoiseSVN 수준의 평판을 획득한다면 (git의 경우에도 비슷한 얘기를 할 수 있겠습니다) 저는 hg를 무조건적으로 권장해야 한다고 생각합니다. 다만 아직까진 그렇지 않은 것 같으므로 조금 두고 봅니다.
(사족입니다만 git를 .NET만으로 재구현하는 프로젝트가 있다고 들었습니다. 이 프로젝트가 잘 되면 VSS 같은 거 버리고(?) git을 네이티브하게 사용할 수 있을지도 모르겠습니다.)
인용:앞으로
글쎄요. 저랑은 생각이 많이 다르네요. 저는 머큐리얼의 이클립스 플러그인이 CVS 플러그인 수준이 되면 그 때는 머큐리얼 쓰는 걸 안 말려도 된다 정도로 보고 있습니다. Tortoise 시리즈는 좋다고 할 수는 없죠. 그저 GUI로도 쓸 수는 있다 정도? 인터페이스의 직관성은 비교가 안됩니다. 명령줄 인터페이스에서 svn 옵션을 까먹는다는 말씀을 하셨는데, 저는 svn에 무슨 옵션이 있는지도 모릅니다만, svn을 쓰는데는 별다른 문제가 없습니다. 그래서, 전 어떤 소스 저장소를 쓰느냐보다 어떤 클라이언트를 쓰느냐가 훨씬 중요하다고 봅니다.
써드파티 툴도 중요한 변수입니다. 별로 좋아하진 않지만 svn에는 trac이 있죠. cvs, svn 모두 history report를 html로 포매팅해주는 툴이 많구요. 자동 빌드 도구와의 연동도 잘 되어 있습니다. git, mercurial은 아직 이런 부분이 미흡하죠.
분산 모델이 유용한 것은 IDE에 로컬 히스토리 기능이 없거나, 소스 저장소와의 연결이 불안정할 때 뿐입니다. 로컬 히스토리 기능이 있으면 그 자체로 분산 모델의 필요성은 80% 이상 줄어듭니다. 뭐 실제 구현상으로 보면 IDE가 분산 모델의 기능 일부를 대신하고 있는 것이기도 하구요.
경험적으로 봐도 svn이나 cvs는 디자이너, 기획자 등 비개발직군이 포함된 그루벵서 사용해도 별 문제 없이 잘 쓰는 걸 많이 봤습니다. 하지만 git를 쓰는데 팀원이 10명 이상이면 그 중에 몇 명은 꼭 소스 병합할 때마다 다른 사람을 부르더군요. 머큐리얼은 아직까지 10명 이상의 팀에서 쓰는 것은 보지 못해서 잘 모르겠습니다만. 분산 모델이라는 것도 어쨋든 개념 하나가 더 들어가는 만큼 공짜는 아닙니다.
Eclipse 플러그인의
Eclipse 플러그인의 수준이 기준이 되는 것은 Eclipse 사용자에게 있어서만 의미가 있겠죠. 모든 개발자가 Eclipse를 쓰진 않으니까요.
그나저나 Trac은 Mercurial 잘 지원합니다. 그렇게 조합해서 두 개의 Trac을 운영하고 있는데 아무 문제 없습니다.
그리고 아직까지 비개발직군이 git, hg 사용하는데 어려워한다는 점에는 동의합니다. (그런데 사실 Subversion도 마찬가지로 어려워하긴 합니다. 자꾸 “그냥 FTP로 올리면 안되나요?” 이런 소리하고 있어서 답답…)
아, 방금 발견해서 추가: DesignSvn이라는 서비스도 있군요.
—홍민희 (VLAAH, LangDev)
인용:Eclipse
네, 기준점이 다르긴 합니다. 그런데 굳이 "낮은 기준점"을 고수해야할 이유가 있을까요? 혹시, 커맨드라인이나 Tortoise 시리즈가 이클립스보다 더 편하다거나, 그냥 장단점이 다른 도구일 뿐이라고 생각하시는 것인가요?
개발 도구는 다른 걸 쓰더라도 소스 저장소와 싱크할 때만 이클립스를 쓰는 방법도 있습니다. 저는 최근 1년간 실무에서 쓴 개발 툴의 종류만도 여섯 가지입니다. FlashDevelop, Xcode, RubyMine, 드림위버, 비주얼 스튜디오 2005, Vim이죠. RubyMine 빼고는 다 연동 기능이 별로라서 이클립스를 썼습니다. 이클립스에서 소스 저장소 기능만 남기고 다 제거하면 꽤 빠른 느낌으로 쓸 수 있거든요.
"높은 기준점"이 저 멀리 있는 게 아니고 바로 곁에 있습니다.
글쎄요 저는 Emacs
글쎄요 저는 Emacs 20년이상 사용하고 있으며 간혹 Eclipse도 사용했는데, 한번도 Eclipse가 Emacs 보다 낫다고 생각해 본적이 없습니다. 사람마다 기준이 다를 뿐이겠죠. 어떻게 하든지 프로그래밍을 잘하면 되는 것 아니겠습니까?
마치 벤츠냐 포니냐의 문제라기 보다는 평균 정도의 운전자이냐 F1 레이서냐의 문제라고 봅니다. 마이클 슈마허(?)가 택시운전사에게 양해를 구하고 택시를 레이싱 카처럼 몰아서 공항에 늦지않았다는 일화가 떠오르네요. 그나 저나 부럽군요. 그렇게 다양한 툴들을 써보시다니! (저는 개발에 대해서는 매우 보수적이라 정말 다른 방법이 없는 경우 아니면 기존에 검증된 툴을 바꾸는 경우가 전혀 없답니다)
제가 Vim 사용자이긴
제가 Vim 사용자이긴 해도 Eclipse가 Emacs보다 낫다고 생각하진 않아요. 사실 비슷하게 따지자면 Emacs에서 얼마나 편하냐가 좋은 VCS의 기준이 될 수도 있겠지요.
—홍민희 (VLAAH, LangDev)
저 역시 개발툴에
저 역시 개발툴에 대해서는 아주 보수적입니다. 아니, 개발툴 뿐 아니라 모든 신기술에 대해서 보수적인 입장을 취합니다. 내가 직접 검증해보고 예전 도구보다 낫다는 판단이 들지 않으면 절대 안 옮겨타죠. 그래서 이 쓰레드에서도 git나 hg 쓰지 말기를 권하고 있는 중이구요.
하지만 이런 건 있습니다.
도요타는 기술에 대해서 아주 보수적인 입장을 취하는 회사입니다. "완벽하게 검증된 기술만 사용한다"는 게 도요타의 원칙이죠. 그렇지만 자동차 업계에서 신기술을 가장 많이 상품화해내고 있는 회사 역시 도요타입니다. Good to Great에도 비슷한 이야기가 나오구요.
"잘 만든 Makefile 하나,
"잘 만든 Makefile 하나, 열 Eclipse Plugin 부럽지 않다."
저만의 생각인가요?
------------------------------
How many legs does a dog have?
------------------------------
How many legs does a dog have?
eclipse SVN plugin 지랄맞다고 쓰셨던게 기억나는데...
놀라운 변화로군요.
SVN client로만 쓰는 eclipse라니 상상하기가 어렵습니다.
잘 생각해보시면
잘 생각해보시면 별로 놀라울 게 없을 겁니다. 그 때와 정확히 같은 논리입니다. 달라진 것은 svn 플러그인의 품질이 좋아졌다는 거죠. 여전히 버그는 간혹 보이지만, 참고 쓸 정도는 되었습니다. 언제나 그렇듯, 상황은 변하게 마련이죠. Things change...
툴에 대해 애정을 갖거나, 혹은 싫어하는 것도 좋겠지만, 그보다 개발자가 갖춰야 할 자세는 바람직한 원칙을 세우고 그 원칙을 지키면서 상황에 맞게 툴을 선택하는 거겠죠. 저는 좋은 툴을 좋아하고, 나쁜 툴을 싫어하는 것이지, cvs를 좋아하고 svn을 싫어했던 게 아닙니다. git와 hg 역시 마찬가지입니다. 아직 성숙도가 낮기 때문에 싫어하지만 그런 점들이 잘 보완되면 또다시 git나 hg를 권할 수도 있겠지요.
>> DVCS의 필요성이
>> DVCS의 필요성이 크게 없다 하더라도 DVCS를 일반적인 VCS에 비해 선호할 이유는 충분하다고 생각합니다. DVCS는 "분산 모델"을 지원하는 것 뿐이지 "분산 모델"을 요구하는 것이 아니기 때문입니다 --- 비록 현재는 필요하지 않다 하더라도 추후에 필요할 때 훨씬 넓은 개발 모델의 선택을 제공한다는 점에서 "처음부터" DVCS를 익히는 것이 나쁜 선택이라 생각하지는 않습니다.
공감하는 바입니다. 발제하신 분께서 VCS도입 자체가 목적이라면 SVN으로 충분한건 사실이지만, 어느정도 쓰다보면 분산모델이 필요한/아쉬운 시점이 언젠가는 꼭 오는것 같습니다. 언젠가는.
--
Life is short. damn short...
--
Life is short. damn short...
같은 고민을
같은 고민을 하시는군요.
저같은 경우는 SVN을 팀에 도입하였는데, 팀원들이 잘 따라와줬죠. (초기에는 약간의 오버헤드는 있지만) TortoiseSVN이 없었다면 어쩌면 힘들었을지도 모르겠다는 생각이 들정도로 완성도가 높은 SVN Client로 생각됩니다.
문제는 출장이 잦아지면서 DVCS의 필요성을 느끼는데, TortoiseSVN만큼의 완성도를 가지는 윈도우 GUI Client가 머큐리나 GIT등에 없다는겁니다. 혼자쓴다면 command line툴만 지원해도 어떻게 해보겠는데, 그게 아니라 고민입니다.
팀에 VCS를 처음 도입한다면, 확실한 DVCS의 필요성이 없다면 (예를들면 저희같은 잦은 장기 출장지 작업) SVN이면 충분하지 않을까 하는 생각이드네요. 첫 도입이라면, 도입하는 분께서 툴을 확실하게 사용해서 문제점들을 확실하게 해결해줄 기간이 필요합니다. 압도적으로 확실하게...
--
Life is short. damn short...
--
Life is short. damn short...
머큐리얼에서
머큐리얼에서 써야한다면 tortoisehg는 어떨까요? tortoisesvn에서 포크된 tortoisehig는 실망스러웠지만, tortoisehg는 정식 시리즈 답게 크게 나쁘지 않았던 것 같습니다.
문제점 없으면 그냥
문제점 없으면 그냥 잘 아는 툴 사용 하세요. 제 일터에서는 cvs에서 git 이냐 mercurial 이냐 고민하다가 그 당시 mercurial이 Windows를 더 지원해서 그걸로 결정했었습니다(개발자 중 한명이 윈도우즈에서 개발합니다)
svn은 이유는 잊었는데, 후보에서 일찍 제외되었던 것으로 기억합니다(동료중 꼼꼼한 친구가 거의 모든 버전 컨트롤 툴 비교해서 git과 mercurial 이 우리가 일하는 방식에 가장 합당해서 최종 후보가 되었던 것으로 기억합니다).
지금도 git가
지금도 git가 윈도우즈 지원이 문제이더군요. cygwin이냐 msys냐가 문제가 아닌데 git 개발이 좀 답답하게 느껴집니다.
한 2년전 이야기인데
한 2년전 이야기인데 아직도 그런가요? 문제점이 있으면 해결하셔야겠죠. :)
엊그제 http://thebuild.com/blog/2009/11/04/git-vs-mercurial/ 에서 본 글이 생각나네요:
"Mercurial is your smart friend who likes to explain things to you. Git is your genius coworker who sighs and rolls his eyes every time you ask him a question."
네..
네..
LISP 사용자모임
http://cafe.naver.com/lisper
LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr
CVS와 SVN을
CVS와 SVN을 비교하시는 분은 없죠? 저의 경우 SVN를 Mercurial혹은 GIt와 비교하는 것도 비슷하게 느껴집니다. 대부분의 경우 DVCS가 유리합니다. 혼자서 하는 프로젝트 조차 DVCS가 없으면 답답함을 느낍니다.
DVCS를 사용할 때 하나의 액션은 SVN과 같은 툴을 쓸 때의 액션보다 부담이 훨씬 덜 합니다. 새 저장소를 만드는 것도 더 간단해지고, 작업 디렉토리를 복제하거나 나누거나 합치는 일도 훨씬 간단합니다. 인지하기 어려운 리비전을 외울 필요도 없습니다. 변경사항을 확인하거나 통합을 하는 과정의 스트레스가 훨씬 줄어듭니다. 웹과 통합이 훨씬 쉬워집니다. 이전에 SVN과 같은 도구들은 웹 인터페이스가 복잡한 설정의 확장을 통해 얻을 수 있었다면 DVCS는 대게 원래 그러한 기능을 지원합니다.
SVN을 특별한 경우에만 쓰는 도구로 생각하지 않는다면 DVCS를 특별한 경우만 써야하는 도구로 생각하지 마세요. 레거시가 없다면 DVCS로 시작하는게 답입니다.
저처럼 mercurial
저처럼 mercurial 쓰시고 동시에 여러 branch에서 작업하시는 분들께 도움이 될만한 스크립트 하나 첨부합니다.
----------------------
#!/bin/bash BRANCH_DIRS=`ls -d ~/branch*` echo "This will do: " for dir in ${BRANCH_DIRS} do echo " 'hg $@' in $dir" done echo "Are you sure(y/n)?" read answer if [ "$answer" == "y" ]; then for dir in ${BRANCH_DIRS} do echo echo echo echo "*** $dir ***" echo cd $dir; hg $@ done else echo Wise decision! fitortoisehg에 file status
tortoisehg에 file status 창에서 파일 선택 잘못해서 파일을 날렸습니다..-_-
mercurial 참 좋군요.
ㅎㅁㅎ
Mercurial 이랑 Git 는 어떤 차이가 있나요?
리플 보고 나서 Mercurial 을 한번 공부해 봤습니다.
Subversion 과 장단점이 각각 있는 것 같긴 한데, 장점이 더 많은것 같아서 Mercurial 로 결정하려고 합니다.
그런데 Git 도 꽤 유명하고 잘 만들어진 툴 같은데요,
Mercurial 과는 어떤 차이가 있나요? 둘다 DVCS 니, 큰 차이 없나요?
즐겁게 살아 볼까나~*
윈도우즈에서도 써야 되면 git 는 비추라고 합니다
그리고 darcs 도 한번 살펴보세요
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
저도 Darcs 좋아하는데
저도 Darcs 좋아하는데 느려서 주변에 추천하기가 힘들더군요. 요즘에 속도 개선 열심히 하고 있긴 하던데…
—홍민희 (VLAAH, LangDev)
맥가이버 취향이면
맥가이버 취향이면 git, 제임스 본드 취향이면 mercurial.
http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/
와우,, mercurial 은 merge 가 정말 좋군요..
subversion 의 merge... 전 너무 익숙해서 불편하진 않지만,
mercurial 의 merge 는 , 정말 논리적으로 잘 구성되어 있군요.
mergerial 이라 불러야 할듯 ㅋ
근데, TortoiseHg 에 기본 merge tool 인 KDiff3 이거 한글이 깨지고 좀 별론데, 대체할만한 툴 뭐가 좋나요???
즐겁게 살아 볼까나~*
한동안 merge 자주
한동안 merge 자주 사용하다가 hg view로 보기에 복잡해지는 경향이 있어서 hg rebase를 사용하게 되었더니 merge가 좀 뜸해지더군요. 사용하시는 프로세스에 따라 어쩌면 rebase가 더 나을지도 모릅니다.
아,, 근데 왜 TortoiseHg 에는 hg cp 명령에 대응하는 메뉴가 없나요??
tortoiseHg에 커맨드라인 hg cp 명령(파일 복사)에 대응하는 gui 명령이 안 보이네요???
즐겁게 살아 볼까나~*