안녕하세요. trueonot님

개발자가 아니라면 굳이 신경쓰지 않으셔도 됩니다. ^^

제이즈님 안녕하세요.

SVN이냐 Git보다 어떻게 쓰느냐가 더 중요합니다.
제가 본 90% 이상의 회사들이 SVN을 쓰던 Git를 쓰던 엉터리로 쓰면서 제 기능의 5%도 활용 못하고 있습니다.
그만큼 제대로 쓰기는 어렵습니다.

멤피스님 안녕하세요.

mercurial도 좋은 툴임에 틀림없습니다. Git가 사용률이 더 높으므로 대표로 말씀드립니다. mercurial이 편하면 mercurial 쓰시면 됩니다. ^^

yducy님 감사합니다.

안녕하세요. 나지오님

SVN의 속도는 Git와 비교하여 가끔 이슈를 제기합니다. Git는 repository가 개인장비에 있으므로 전광석화같은 속도를 자랑하죠. ^^ 하지만 push, pull 때는 만만치 않죠. 게다가 clone을 만들 때는 많이 기다려야죠.

SVN은 기존의 어떠한 SCM보다 빠릅니다. diff만 왔가 갔다 하므로 네트워크 상에서 속도가 빠르죠. 실제로 수백명의 개발자가 동시에 사용을 해도 성능이 문제가 되지는 않습니다.
단 처음에 대량으로 check out을 받을 때는 좀 기다려야죠.

SVN과 Git는 1:1로 성능 비교를 하기에는 성격이 너무 다릅니다. ^^ 둘다 좋습니다.

안녕하세요. 슬픈멍멍님 ^^

제 결론은 SVN입니다. 엄마가 좋아? 아빠가 좋아? 토론은 하루 종일 할 수도 있죠. ㅎㅎ
SVN은 브랜치, 머지에 있어서 부족함이 없습니다. Git가 브랜치,머지가 직관적이고 쉽지만 SVN은 강력하죠. SVN의 브랜치, 머지가 좀 어렵다면 Git는 기능적으로 풍부하고 다양하지만 경험이 부족하면 어렵습니다.설명이 복잡하지만, 이게 제 결론입니다.

SVN을 쓰던 Git를 쓰던 거의 대부분의 회사들은 제대로 사용을 못하고 있는 것이 현실이죠.

누가 인기를 더 끌지는 저도 궁금하네요. ^^

구차니님 안녕하세요.

SVN 서버 구성은 회사에서 딱 한명만 잘 알면 되잖아요. ^^ 나머지 사람들은 감사하게 그냥 잘 쓰면 되겠죠.

김재호님 반갑습니다. ^^

안녕하세요. 동범님

Git는 서버자체를 각 PC에 두고 서로 복제하고 Merge하는 개념입니다. ^^ SVN을 잘 쓰시면 그냥 쓰시면 됩니다.

Trac, Redmine 등은 프로젝트관리툴이라기보다는 이슈관리시스템입니다.

대부분의 유명한 이슈관리시스템은 거의 Git, SVN 등과 연동이 잘 됩니다.

굳이 필요하지 않은데 Git를 쓰려고 노력할 필요는 없고, 알아봐 놓는 것은 좋을 것 같습니다.

안녕하세요. 자비지기님
SVN은 Merge에 있어서 정말 강한 툴이지요. ^^
하지만 제대로 쓰려면 그 컨셉을 정말 잘 알아야 합니다.

형상관리도 중요하고 스펙의 범위 관리도 중요하지요. 뭐하나 소홀히 얘기하기는 어렵겠네요.

안녕하세요. 우울한딱따구리님
Git을 쓰려면 조금더 역량이 필요한 것은 사실이지요. ^^
언제한번 SVN과 Git를 비교해보도록 하겠습니다.

구차니님 안녕하세요.
코딩 컨벤션을 지키는 것은 아주 기본적이고 당연한 것이고 위 내용은 그보다 한단계 높은 수준의 습관입니다. ^^

안녕하세요. 피스티스님
맞습니다. 팀의 규모가 매우 커지고 프로젝트가 복잡해지면 update를 하는데도 나름 계획이 필요합니다. 파일이 너무 자주 바뀌기 때문에 적절한 시점에 update를 하지 않으면 상당히 복잡해집니다.

오산돌구님 안녕하세요.
그렇게 생각해주시니 고맙습니다. 개발자분들이 좀더 좋은 환경에서 일하게 되는 것이 제 바람입니다.

안녕하세요. 이승철님
반갑습니다.

안녕하세요. 구차니님
SVN 서버를 구성하는 방법은 간단하기도 하지만, 제대로 하려면 매우 복잡합니다.

1. 말씀하신 것과 같이 Protocol을 정해야 합니다.
2. Repository를 어떻게 나눌 것인지 정해야 합니다.
3. Repository 내의 디렉터리를 어떻게 구축해야 하는지 정해야 합니다.
4. 각 Repository내의 디렉터리에서 권한을 어떻게 부여해야 할지 정해야 합니다.

이 중에서 가장 어려운 것이 2,3번입니다. 특히 3번은 잘못 구축하는 경우가 태반이고, 한번 잘못 구축하면 다시 복구하는 것은 대단히 어렵습니다.
디렉터리의 구조는 빌드 스크립트와 연관이 있어서 다시 고치는데는 대단히 노력과 비용이 듭니다.
디렉터리 구조는 회사마다 다르며 잘못 구축하면 비효율성이 계속되며 비용을 지불해야 합니다.
제대로 디렉터리를 구축하려면 SVN의 사용방법도 제대로 알아야 하고 회사의 미래 개발 전략도 어느정도 이해를 해야 가능합니다.

이중에서 1번인 프로토콜은 꽤 쉬운 편입니다. 왜냐하면 나중에 요구사항이 바뀌면 바꾸기가 쉽기 때문입니다.
SVN은 기본적으로 자체서버에서 svn://을 지원합니다. 그리고 웹서버와 연동해서 http:// https://를 지원합니다.
그리고 ssh에 svn을 얹어서 쓸 수도 있습니다.

웹브라우저로 보기도 원하는지? 철저한 보안을 원하는지? 편리하고 간단하게 쓰고 싶은지? 속도가 매우 중요한지?에 따라서 정하면 됩니다.

안녕하세요. csj님
맞습니다. 기본적인 시스템을 갖추지 않고 개발을 하는 것은 사냥을 맨몸으로 하는 것과 같습니다. 창이나 활, 총을 갖춰야죠.
이제 무기는 생겼습니다. 무기를 갖추는 것은 시간이 얼마 안걸립니다. 하지만 무기를 잘 쓰는데는 시간이 좀 걸립니다.
또한 사냥을 더 잘하려면 무기를 잘 쓰는 방법 뿐만 아니라 자연을 이해야 하고 동물의 습성등 다른 기술들도 필요하고 팀웍도 필요합니다.

이제 기초를 갖추신 겁니다. 비록 요소기술이 뛰어나다고 해도 소프트웨어 공학에서 다루는 프로세스, 툴, 분석, 리뷰, 설계 등의 실력을 갖추지 않으면 소프트웨어를 개발하기가 점점 어려워 집니다.

앞으로 좋은 정보를 많이 공유하도록 하죠.

오산돌구님 안녕하세요.
제가 쓴 "소프트웨어 개발의 모든 것"의 개정판에 중앙집중식SCM과 분산SCM의 비교가 있으니 참조하시면 좋을 것 같습니다.
특별히 분산 관리의 목적이 아니라면 SVN이 더 관리하기 편합니다.
서로 연동도 되니 필요에 따라서 연동해서 사용하는 방법도 있습니다.

그렇군요.
지금까지도 최고의 SCM으로 생각됩니다.

오산돌구님 반갑습니다.
오산돌구님도 건강하세요.

구차니님 안녕하세요.
ㅎㅎ 하나만 제대로 써도 충분합니다. 기본 원리는 다 같거든요.
여러개를 써봤어어도 엉터리로 써보는 것이 더 문제죠.

2년전과 비교하여 통계를 다시 내보려고 합니다.

Subversion을 제대로 쓰는 것만 해도 보통일이 아닙니다.
브랜치와 머지가 책에 나온 것을 읽기만 해서는 익히는 것이 거의 불가능 할 정도입니다.
제가 쓴 책과 블로그에 가이드가 나오니 참고하세요.

Google Code(Hosting Service)에서도 SVN과 더불어 Mercurial을 기본으로 제공하고 있죠. 최근 분산 소스코드관리에 대한 관심이 많이 높아졌습니다. 모두 훌륭한 툴임에는 의심이 없습니다.
조만간에 중앙집중식 소스코드관리시스템과 분산 소스코드관리시스템을 비교하는 글을 올려보도록 하겠습니다.

구차니님 안녕하세요.
누구는 "소스코드를 주석처럼 자세히 작성해라", "주석은 필요없다.", "있다" 말들이 많지만, 어느것도 정답이 아닙니다. 회사에 알맞게 규칙을 스스로 정하면 됩니다. 그리고 따라야지요.

규칙을 정한데로 따른다라. 그렇군요.

제가 달 곳은 아닌듯 하지만 주제넘게 리플을 달아봅니다.

개인적으로 doxygen 등의 comment documenting application의 문법대로 생성해주는 것이 가장 무난하지 않을까 생각을 해봅니다. 프로그램 작동원리와 같은 세부 주석은 headrer 파일쪽으로 몰아주는 식으로 말이죠.

라고는 하지만.. 저도 생각만 해봤지 직접 실행을 안해봐서 잘 모르겠어요 ㅠ.ㅠ

Commit할 때 코멘트는 "Commit message"라고 통일해서 부르면 됩니다. 정확한 용어를 사용하는 것도 자신의 내보이는 중요한 요소가 됩니다. ^^

Commit Message에서 빠지지 않고 꼭 입력하기를 권장하는 2가지가 있습니다.
바로 BugID(Issue ID)와 Reviewer입니다.

BugID가 꼭 포함되는 이유는 버그관리시스템에 등록되지 않은 변경은 없다는 전제하에 작업을 해야 하기 때문에 물론 알파 이전에는 예외이지만, 이후에는 소스코드 한줄을 수정해도 버그관리시스템에 등록을 해야 합니다. 그래서 엑셀에 버그를 관리하는 회사에서는 불가능한 것이지요.

그리고 누가 리뷰를 했는지 꼭 적게 합니다. 이는 Peer Desk Check을 한다는 전제하에 시행할 수 있습니다. Peer Desk Check은 Commit전에 간단히 동료와 리뷰를 하는 것으로 가장 효과적인 방법중 하나입니다. 이를 도와주는 툴도 있기는 하지만 툴 없이도 할 수 있습니다. Review를 하지 않았으면, None이라고 적고 소스코드를 책임지면 됩니다. 추후 여기서 버그가 나오면 진짜 민망해집니다.

그리고는 간단한 Message를 포함하면 됩니다. 이미 버그관리시스템에 많은 정보가 있으므로 간단히 적으면 됩니다.

Commit Message는 절대로 빼먹으면 안됩니다. 버그 등록하지 않고 마음대로 고치면 안됩니다. 이러한 작은 것들이 큰 차이로 나타나게 됩니다.

나중에는 여기에 관련된 Post로 해야 겠네요.

감사합니다.

와, 바로 제가 알고싶던 것들이에요.

엄청 많이 배웠습니다.

윤연식님 반갑습니다.
좋은 인연이 되길 바랍니다.

안녕하세요. 차우차우님
말씀하신 현상은 우리나라 소프트웨어 회사에서 너무나 흔히 볼 수 있는 현상입니다.
또한 우리나라 소프트웨어 회사들이 성장하지 못하는 가장 중요한 요소중 하나입니다.
개발자들이 적당히 설득해서 영업이 바뀌었으면 벌써 잘 되었겠죠. 영업을 설득하는 것은 그렇게 쉽지 않습니다.
특히, 경영자가 Sales oriented되어 있으면 더욱 힘듭니다. 개발자들도 심정적으로는 그렇게 하면 안되는 것을 알지만 좀더 전문적으로 강력하게 설득할 힘이 부족한 것이 현실입니다.
그래서 저같은 전문가가 회사에 가서 경영자와 영업도 교육을 시키고, 시스템, 프로세스, 문화를 바꿔주는 것이지요. ^^
해보다가 난관에 부닥히면 도움을 요청하세요. 감사합니다.

안녕하세요. 루돌님 반갑습니다.
엄청 오래된 블로그를 가지고 계시네요. 대단하십니다. ^^
종종 들려서 좋은 정보를 나눠요.

안녕하세요. 구차니님
viewvc같은 이슈는 전체 소스코드관리 이슈에서 너무나 미미한 이슈입니다. 지엽적인 이슈에 크게 좌지우지 되지 않는 것이 좋겠습니다.
사실 시중의 모든 소스코드관리를 다루는 책에서 브랜치, 태그, 머지 등에 대해서 설명이 되어 있지만, 책을 보고 한번에 익히는 것은 대단히 어렵습니다.
그래서 실무를 통해서 배우는 것이 가장 좋은데 제대로 하고 있는 선배들이 별로 없으니 이또한 어렵기는 마찬가지 입니다.
그렇다고 블로그의 글을 통해서 모든 것을 전달하기도 어렵습니다. 어쨋든 나름대로 앞으로도 글을 계속 써보기는 할텐데, 글들을 보고 깨우치는 사람도 있을 것이고 그렇지 못한 사람도 있을 겁니다.
제 Office에 한번 오시면 제가 직접 설명을 해드리면 더 빠를텐데요. ^^

아무튼 앞으로도 계속 관심을 기울이고 실무에 적용을 해보면서 궁금한 것이 있으면 또 물어보고 이렇게 반복을 하다보면 어느새 다 깨우치게 될 겁니다.

질문 중에서 "태그와 브랜치간의 오가는 것"이란 무엇을 말하는 것인가요? 질문이 매우 모호해서 구체적인 답변을 드리기가 어렵네요.

댓글이나 Email을 통해서 자세히 설명을 해주시면 제가 답변을 드리도록 하겠습니다

감사합니다.

안녕하세요. 구차니님
브랜치/머지를 교과서적으로 뭔지 아는 것은 10분이면 됩니다. 하지만 제대로 쓰려고 이해를 하려면 시간이 많이 걸립니다. 그리고 수많은 케이스에서 적절하게 쓰는 방법을 모두 익히려면 1,2년 써보면서 알게 됩니다. 대부분은 시행착오로 배우는데, 시행착오 없이 배우면 더욱 좋지요. 제가 쓴 책에 자세히 적혀 있으니 참고하시고요. 필요한 부분은 구체적으로 물어봐주시면 설명 드리겠습니다. ^^
강좌에 대해서는 한번 생각해 봐야겠네요. 작년에 Bit와 연계를 해서 교육을 실시한 적도 있기는 합니다. 그리고 몇몇 고객은 소스코드관리에 대해서만 세미나 식으로 교육을 실시한 적도 있죠.
필요한신 것이 있으면 요청해주세요. 감사합니다.

안녕하세요. 차우차우님
Hotfix에 대한 용어 정의는 회사마다 조금씩 다르겠지만, 일반적으로 Hotfix는 계획되지 않은 긴급패치를 말하므로 Hotfix가 많아진다는 것 자체가 문제가 될 수 있습니다. 이는 항상 호떡집에 불난 모양으로 FireFighting mode가 될 수 있습니다. 이왕 Hotfix의 버전 관리에 대해서 문의를 하셨는데 설명해야 할 내용이 댓글로 달기는 너무 많으므로 블로그에 포스트를 하도록 하겠습니다.

답변감사합니다. ^^
역시 Hotfix가 많아진다는것 자체가 문제가 있는 상황인거네요. 릴리즈할때 좀더 완벽하게 준비한다면 hotfix를 남발하지 않아도 될테구요.
나중에 Hotfix의 버전관리에 대해서도 포스팅해주시면 많은 도움이 되겠습니다.

Hotfix에서의 버전관리포스트 올렸습니다.
http://allofsoftware.net/entry/HotfixVersionControl

안녕하세요. Benjamin님
재미있는 글은 아닌데 재미있게 보셨나니 SW개발을 정말 좋아하시는 것 같군요. ^^

안녕하세요. Yarmini님
들려주셔서 감사합니다.

안녕하세요. 알콜알프님
금융쪽이라면 생각할 것이 좀더 많습니다. 물론 금융이라고 해서 소프트웨어자체가 더 복잡하다고 볼 수는 없지만, DB, Middle ware와 인터페이스가 있고, 대외계, 원장 등 연동해야 할 것이 많습니다.
그래서 Merge를 못하는 것이 아니고 개발할 때 Merge를 감안해서 미리 생각하고 구현을 하면 됩니다.
그렇게 하면 일반 Application보다 더 용이하게 Merge가 가능합니다.
흔히 Merge를 하면 모든 것이 끝나는 것으로 생각을 하지만, 소스코드가 잘 Merge가 되었는지 직접 Diff를 이용해서 확인하는 것이 좋고, Merge 후 테스트를 또 해보는 것은 당연합니다.
특히 계정계같은 숫자 하나 까딱 잘못되면 큰일나는 심각한 곳에서는 더 철저히 검증을 해야죠.
그래도 이렇게 Merge를 이용하는 것이 완전 수동으로 하는 것보다 시간도 훨씬 적게 걸리고, 오류 가능성도 더 적습니다.

좋은 정보 감사합니다. 한번 Evaluation 해보도록 하죠.

Beyond J2EE님 안녕하세요.

정말 적절한 비유입니다.
이런 소스코드는 감당하지도 못합니다. 소스코드관리시스템의 브랜치와 머지 기능을 충분히 활용하고 개발 프로세스 상에서 이를 잘 통제하면 부처님 손바닥안의 소스코드죠.

언제 다 같이 모아 놓고 세미나를 한번 하고 싶은 마음은 굴뚝 같은데 여유가 안생기네요. - -;

안녕하세요. 옥수석님

당연한 기초가 현실과 괴리가 있는 현실이 안타깝습니다. 대학생들을 갈쳐도 몇주면 익숙해지는 것을 십수년 경력의 개발자들도 제대로 하지 못하는 것이 현실이기는 하죠.

브랜치와 머지는 보통 개발자가 마음대로 하면 안됩니다. 이에 대한 회사의 정책이 있고 개발자는 이를 따라야죠. 일반적으로 브랜치는 승인하에서 합니다. 머지계획도 미리 작성해야 하고요. 번거로우라고 이렇게 하는 것이 아니고 이렇게 하는 것이 가장 효율적이기 때문입니다.

또 머지는 3-way머지를 해야 합니다. 보통 2-way머지툴을 가지고 머지를 하는데 이는 수십배 더 시간이 많이 들고 잘못 머지가 될 가능성도 대단히 높습니다.

이렇게 해 놓고 개발자들이 계획에 따라서 자유롭게 개발하는 것이 좋지, 대충 해놓고 뭔가 고칠려고 할 때마다 소스코드 공유/통합을 신경써야 한다면 프로젝트 기간 내내 소스관리 비용이 몇백배로 더 많이 들게 됩니다.

산으로 가고 있다면 다시 땅으로 끌어 내려야 겠네요. ^^ 필요하면 제가 세미나 등을 통해서 개발자와 경영진들을 설득시키고 교육도 시켜주곤 합니다.

Repository를 어떻게 나누고 각 Repository안의 프로젝트 별 디렉터리를 어떻게 구성하는지는 회사마다 다릅니다.
일단 revision number는 신경쓰지 않는 것이 좋습니다. revision number에 의미를 부여해서 사용하면 나중에 문제가 발생합니다.
Repository구분은 각 프로젝트가 단 0.1%라도 서로 연관성이 있는지를 봐야 합니다. 공유되는 소스코드가 있는지? 나중에 쓰고 버릴 소스코드인지? 백업은 공통으로 해야 하는지? 이렇게 생각을 해보고 연관이 있으면 한 Repository에 넣는 것이 좋습니다.
Repository안의 디렉터리 구조는 각 프로젝트가 완전히 자동으로 Build가 가능하도록 구성을 해야 하는데 공통모듈이 잘 관리되고 있는 회사가 아니라면 이 말이 무슨 뜻인지 잘 모를겁니다. 하지만 공통모듈이 있다면 디렉터리를 어떻게 구성하냐에 따라서 빌드가 달라집니다.

이렇게 여러가지를 고려하여 처음부터 잘 정해 놓고 시작해야지 나중에 바꾸려고 하면 큰 문제입니다.

리파지터리 주소는 프로젝트 check out할 때 처음에 한번만 입력하면 되는 것이기 때문에 기억하는 것은 문제가 알될 것 같습니다.

안녕하세요. zeous님
일단 SVN과 이슈트래킹(아마 Trac)을 연동해서 잘 쓰고 계시나보네요. 평균 이상은 되시네요. ^^
항상 안되는 것만 있으면 빵점이게요? 그럴리가 있겠습니까? 항상 포스트를 보면서 조금씩 고쳐나가자는 의미입니다.
SVN을 잘 쓰시는 것 같기는 한데 Branch, Merge는 어떻게 하는지 궁금하네요. 사실 SVN의 핵심은 Merge거든요. 나중에 Git나 Mercurial들의 분산소스코드관리시스템을 쓰더라도 Merge를 제대로 하지 못하면 반쪽짜리가 됩니다. 그래서 3-Way Merge를 능수능란하게 다룰 수 있어야 합니다. 어떠신가요?

branch를 전혀 쓰지 않는 것은 아닙니다.
이번에도 새로운 프로젝트를 시작하는데 기존 소스의 서비스도 유지하면서 거기에서 파생되어서 추가적인 작업을 하고 완성후에 합치기 위해서 branch를 생성해서 작업을 하고 있습니다만은

branch를 생성하고 나서 마지막에 합칠때 실수하지 않을까 (자동으로 하게 되면 가끔 한쪽을 날려먹는 경우가 있어서 안볼수는 없더라구요)
챙겨야 할것들이 있기에 이왕이면 안만들어졌으면 하는 바램은 있습니다 ^^

moova님 안녕하세요.
제가 좀 바빴네요. - -;
소스코드시스템을 쓰는 이유가 소스코드를 잃어버릴까봐 백업용도로만 쓰는 곳이 의외로 많습니다.
빠뀌지 않는 이유는
1. 막연히 새로운 것을 배우는 것이 귀찮아서
2. 나아진 다는 확신이 없어서
3. 현재 방법에 익숙해져서
4. 가르쳐 주는 사람에 대한 믿음이 부족해서
5. 소스코드를 감추려고
등등 다양합니다.
산넘어 산입니다.
그래서 카리스마 있는 사람의 도움을 받아서 설득을 하면서 강제화하는 것이 가장 좋은 방법입니다.

현재 SVN의 기본 저장 기능만 쓰고 계신거라고 볼 수 있습니다. 혼자서 개발을 해도 브랜치 요구는 항상 생깁니다.