patch 의 목적이 무엇일까요?
질문 올리는 것이 쑥스럽습니다.
사내 개발 정책 때문에 의견 충돌이 많이 있어서 조언을 구하고자 글을 올립니다.
예를 들어 open source 인 rtsp.1.0.tar.gz 을 가져다가 사용한다고 가정하면
제가 지금까지 사용한 개발 방식은 서브 버전에 등록하여 아래와 같은 방식으로 개발을 해왔습니다.
r1 : rtsp.1.0 등록
r2 : tcp.c 수정하여 commit
r3 : udp.c 수정하여 commit
r4 : connect.c 수정하여 commit
새로 작업할 내용이 있으면 r4 를 check-out 해서 계속 이어가면 되겠지요? (이게 일반적인 방법일듯)
새로운 개발 방식을 적용하자는 강력한 의견이 나왔는데
r1 : rtsp.1.0 등록
r2 : 작업한 내용을 patch 파일로 만들어서 등록(tcp_patch.patch)
r3 : 작업한 내용을 patch 파일로 만들어서 등록(udp_patch.patch)
r4 : 작업한 내용을 patch 파일로 만들어서 등록(connect_patch.patch)
서브 버전을 위와 같이 관리하는게 새로운 방식입니다.
그래서 개발을 하려고 하면 아래와 같이 작업을 해야 합니다.
1. svn co -r1 svn://localhost/project/trunk ./src
2. svn co -r4 svn://localhost/project/patch ./patch
3. cd src
4. patch -p1 (tcp_patch.patch)
5. patch -p1 (udp_patch.patch)
6. patch -p1 (connect_patch.patch)
이런식으로 지금까지 작업한 내용을 원본 소스에 모드 패치로 적용한후 새 작업을 진행합니다.
그리고 새작업이 완료되면 new_patch.patch 를 만들어서 다시 서브버전에 등록을 합니다.
이런 방식으로 개발을 하자고 하는데....
새로 작업을 하려면
1. 원본 받기
2. 단계별 패치 모두 적용
3. 새 작업
이럴거면 굳이 서브버전을 사용할 필요가 있을까요?
참 고민이 많습니다. 이런 개발 방법은 처음 봤네요.
새로운 개발 방식을 적용하자는 분들의 이유가 뭔가요?
새로운 개발 방식을 적용하자는 분들의 이유가 뭔가요? 왜 굳이 저렇게..
..
어짜피 subversion이면 구형 리비전을 체크아웃할 수 있지 않나요?
patch파일을 만들고 싶다면 미리 만들어둘 필요 없이 그냥 동일 버전중 예전 리비전과 마지막 리비전을 diff해버리면 바로 나올텐데..
새로운 방식을 주장하시는 분의 의견은 1. 변경
새로운 방식을 주장하시는 분의 의견은
1. 변경 내용을 모두 패치 파일로 만들면 작업 이력 추적이 쉽다.
2. rtsp1.0 이 rtsp1.5 로 업데이트 될 경우 새 버전을 받아다가 패치만 하면 된다.
입니다.
그에 대한 제 의견은
1. 이력 추적은 서브버전을 사용해서 추적이 가능한다.
2. open source 인 rtsp 가 1.0 에서 1.5 로 버전업된 경우 기존 rtsp1.0 을 기반으로 작업한 패치파일들은 rtsp1.5 에 바로 적용할 수 없기 때문에 우리가 개발한 내용들은 수작업으로 포팅해 주어야 한다.
입니다.
========================
조직 : E.L.D(Embedded Linux Developer/Designer)
블로그 : poplinux@tistory.com
카페 : cafe.naver.com/poplinux
임베디드 리눅스 관련 프리렌서 지향
2번은 충돌이 나면 어떤 버전관리시스템이라도 수작업이
2번은 충돌이 나면 어떤 버전관리시스템이라도 수작업이 필요한거죠. 수작업 포팅이 필요할 정도의 충돌이리면 패치건 서브버전이건 작업이 달라지지 않습니다. 버전관리시스템을 써본 사람이라면 바로 이런 비판이 나올겁니다.
패치파일 모음으로 관리해도 별 상관이 없을 정도로 작은 변경사항이라면 이러나 저러나 상관은 없을 것이고, 작업이력을 중앙관리서버에 기록으로 남긴다는 1번 의미를 강조하지 않는다면 누구나 납득할 수 있는 주장이 되지는 않습니다.
제 생각엔, 패치라는 것의 개념은 내가 메인
제 생각엔, 패치라는 것의 개념은
내가 메인 개발자일때, 불특정 다수에게 새로 수정된 내용을 배포할 때 사용하는 것으로 생각됩니다.
내가 메인 개발자인데 내가 개발하고 있는 코드를 패치로 만들어서 나 자신한테 배포할 필요가 있는지가 의문이네요.
========================
조직 : E.L.D(Embedded Linux Developer/Designer)
블로그 : poplinux@tistory.com
카페 : cafe.naver.com/poplinux
임베디드 리눅스 관련 프리렌서 지향
저도 처음에는 diff 를 버전관리하는게 좋아보였습니다.
오픈소스 프로젝트라고 하셔서요.. 진짜 버전관리는 커미터들이 하는 것이라고 생각해서요..
그런데
patch파일을 만들고 싶다면 미리 만들어둘 필요 없이 그냥 동일 버전중 예전 리비전과 마지막 리비전을 diff해버리면 바로 나올텐데..
open source 인 rtsp 가 1.0 에서 1.5 로 버전업된 경우 기존 rtsp1.0 을 기반으로 작업한 패치파일들은 rtsp1.5 에 바로 적용할 수 없기 때문에 우리가 개발한 내용들은 수작업으로 포팅해 주어야 한다.
위 두 개 답글을 보니 생각이 바뀝니다. 취지는 좋았으나 반박되게 될 것 같아요.. 위의 이유들로요..
저는 Subversion 사용법을 여기서 또 배웠습니다. ^^;
Thanks for being one of those who care for people and mankind.
I'd like to be one of those as well.
일리있는 의견인 것 같습니다. 일부 차이점이 있는
일리있는 의견인 것 같습니다.
일부 차이점이 있는 부분이라면,
rtsp 라는 오픈 소스의 성능 개선등을 하는 것이 아니라 우리 제품에서만 사용하는 프로토콜을 하나더 en-capsulation 하거나 우리 제품의 특정 HW 를 제어하는 기능을 추가하는 등의 일을 하고 있습니다.
결국 rtsp 오픈 소스를 기반으로 작업을 시작하지만 자체 제품으로 발전하기 때문에 작업 시작하는 순간부터 own-product 의 개념으로 바뀌게 됩니다.
========================
조직 : E.L.D(Embedded Linux Developer/Designer)
블로그 : poplinux@tistory.com
카페 : cafe.naver.com/poplinux
임베디드 리눅스 관련 프리렌서 지향
oosap 님의 댓글이 변경되어서 제가 위에 올린
oosap 님의 댓글이 변경되어서 제가 위에 올린 댓글은 큰 의미가 없어졌습니다. ㅎㅎㅎ 제가 위에 올린 댓글은 무시하셔도 좋을 것 같습니다.
========================
조직 : E.L.D(Embedded Linux Developer/Designer)
블로그 : poplinux@tistory.com
카페 : cafe.naver.com/poplinux
임베디드 리눅스 관련 프리렌서 지향
저랑 같은 순간에 서로의 글들을 보면서 글을 써서 제
저랑 같은 순간에 서로의 글들을 보면서 글을 써서 제 글도 바뀌고 님 글도 바뀐 것 같아요.
제가 글을 썼다가 잘못 쓴 것 같아서 수정했는데... 그 사이에 답글을 하셨었네요... 제가 여기 글에서 배우는게 더 많았습니다.
Thanks for being one of those who care for people and mankind.
I'd like to be one of those as well.
그냥 분산형 버전 관리 시스템을 쓰는게 답인 것
그냥 분산형 버전 관리 시스템을 쓰는게 답인 것 같은데요 = _=)...
JuEUS-U님, 분산형 버전 관리 시스템에 대한
JuEUS-U님, 분산형 버전 관리 시스템에 대한 예를 부탁드려도 될까요?
========================
조직 : E.L.D(Embedded Linux Developer/Designer)
블로그 : poplinux@tistory.com
카페 : cafe.naver.com/poplinux
임베디드 리눅스 관련 프리렌서 지향
음... 위키에 있는걸로 알긴 하는데...대충
음... 위키에 있는걸로 알긴 하는데...
대충 Mercurial(hg), Git, Bazaar(bzr) 같은 놈들을 일컫는 말입니다.
기존의 시스템(Subversion, CVS)하고의 가장 중요한 차이점은
사용자가 직접 중앙 저장소에서 작업을 하는게 아니라
그걸 복사한 로컬 저장소를 가지고 작업을 한다는 점입니다.
뭐 대충
사용자 ←(commit/update)→ 로컬 저장소 ←(push/pull)→ 중앙 저장소
이런 그림이 나온다고 할 수 있습니다.
bazaar의 경우 어째서인지 안좋다고 욕을 더럽게 먹고있고 - _-)
보통 무난하게 쓴다면 hg나 git을 씁니다.
특히 hg의 경우에는 bitbucket이라는 무시무시한 서비스가 있어서 대박이였죠 - ㅅ-)b (최근에는 Git도 지원하지만...)
(덧)
얘기가 좀 산으로 간것 같긴 한데....
제가 알기로는 저런 접근 방식은 잦은 커밋으로 인한 충돌을 최소화 하기위한 방법 중 하나입니다.
변경사항 추적이라던지 패치의 재사용이라는건 사실 말이 좀 이상한지라,
충돌 방지를 위한 거라고 생각하고 분산형 시스템을 거론했습니다.
말씀 중에 사용자 ←(commit/update)→
말씀 중에
사용자 ←(commit/update)→ 로컬 저장소 ←(push/pull)→ 중앙 저장소
이 말씀은 안드로이드 x86 프로젝트의 경우로 빗대면
android-x86 개발자 ←(commit/update)→ android-x86 저장소 ←(push/pull)→ 구글 안드로이드 저장소
와 같을까요?
안드로이드 x86 은 아수스에서 주도하는 x86용 안드로이드 프로젝트 입니다. 물론 구글의 안드로이드로부터 시작한 개발 브랜치(?) 이죠. 그 소스의 관리가 비슷한 개념인가 싶어서 여쭤봅니다. git 을 쓰거든요...
만약 그렇다면 android-x86 프로젝트를 poplinux 님도 참고할만 할 것 같아요...
사내 개발자 ←(commit/update)→ 사내 로컬 저장소 ←(push/pull)→ 오픈소스 저장소
그러려면 git 과 같은 분산 환경을 사용하는 프로젝트여야하겠어요...
제가 영 엉뚱한 생각을 하고 있는지 궁금해서 책을 하나 집었습니다.
http://www.yes24.com/24/goods/3676100
Thanks for being one of those who care for people and mankind.
I'd like to be one of those as well.
android-x86 개발자
android-x86 개발자 ←(commit/update)→ 자기 local 저장소 ←(push/pull)→ android-x86 저장소 ←(push/pull)→ 구글 안드로이드 저장소
감사합니다. 그리고 제가 이 쓰레드를 어지럽힌 것
감사합니다.
그리고 제가 이 쓰레드를 어지럽힌 것 같아 죄송합니다..
Thanks for being one of those who care for people and mankind.
I'd like to be one of those as well.
조언 감사합니다. 참조 하도록 하겠습니다.
조언 감사합니다. 참조 하도록 하겠습니다.
========================
조직 : E.L.D(Embedded Linux Developer/Designer)
블로그 : poplinux@tistory.com
카페 : cafe.naver.com/poplinux
임베디드 리눅스 관련 프리렌서 지향
제가 만든게 아니라서 여기에 이렇게 올려도 되는지
제가 만든게 아니라서 여기에 이렇게 올려도 되는지 몰르겠지만,
얼마전에 '네이버 개발자 센터'에서 'NHN 개발 인프라 세미나 - 분산형 소스코드 저장소 및 지속적인 통합'[1]의
한 세션의 발표 자료에 대한 링크[2]입니다.
[1] http://dev.naver.com/notice/read/1000003380/10000000000024174898
[2] http://keedi.pe.kr/presentations/just_do_git/
keedi 님의 slide는 무엇으로 제작된건가요?
Perl 기반의 뭔가가 있나요? S5는 아닌 것 같아요. 간혹 약간 느린 경우가 있습니다만 정말 멋지네요.
오해하시는 것 같아서 말씀드립니다. 제가
오해하시는 것 같아서 말씀드립니다. 제가 keedi님이 아닙니다.
발표하실 때 펄만 사용하신다는 말씀을 하신 것 같은데 아마 펄로 작성되지 않았나 싶네요.
음 ..
SNV 에서 revision 별로 diff 떠서 patch 를 만들 수 있고, 언제든지 원하는 revision 간의 diff 를 자유롭게 만들 수 있습니다.
물론 빈번하게 revision 이 갱신되어서 불편한 경우라면, 적절한 시점에서 tag 를 떠 놓아도 되구요.
SVN 내에서 모두 할 수 있는 일들을, 힘들여 patch 파일까지 만들어서 버전관리 할 필요는 없어 보입니다.
만약 원본 소스가 빈번하게 업데이트 되어 merge 가 자주 발생하는 상황이라면 ..
원본 소스에 대한 압축 파일 및 버전별 patch 파일을 관리하는 것도 나름 괜찮은 방법이 될 수 있을것입니다만..
위와 같은 경우에는.. 그냥 에너지 낭비로 보여지네요.
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』
버전관리 툴들의 원리를 전혀 모르는 분들의
버전관리 툴들의 원리를 전혀 모르는 분들의 의견같네요.
svn / git 등등의 툴들이 바로 diff delta를 체계적으로 관리하는 툴인데...
간혹 패치세트로만 관리하는것이 편리할 수도
간혹 패치세트로만 관리하는것이 편리할 수도 있습니다.
메인 소스가 별도로 잘 관리되어 있고 이에 대한 변경만 관리하고 싶은 경우
하지만 git같은 버전관리툴을 쓰면 워낙 merge를 잘 해주기때문에 구지 불필요하지 않은 싶더군요.
제 생각도 마찬가지입니다. 서브버전이 diff
제 생각도 마찬가지입니다.
서브버전이 diff data 관리 및 log 관리를 해 주는 툴인데 굳이 patch 형태를 사용할 필요는 없다고 생각되네요.
patch 를 사용하면 공동 개발시에도 어려움이 많습니다.
서브버전 사용하면
svn up 으로 끝날 일이
patch 만들어 달라고 요청하고 만들어진 패치를 가져다가 내 소스에 패치 걸고... 내 소스에서 패치 만들어서 넘겨줘야 하고
정신이 없네요.
========================
조직 : E.L.D(Embedded Linux Developer/Designer)
블로그 : poplinux@tistory.com
카페 : cafe.naver.com/poplinux
임베디드 리눅스 관련 프리렌서 지향
리눅스 커널 개발 방식
패치 제안하는 방식은 리눅스 커널을 포함하여 대부분의 오픈 소스 프로젝트에서 사용하는 방법입니다.
소스 코드 품질 관리를 위하여 커밋 권한을 특정 사람(커미터, 메인테이너)에게 제한을 둡니다.
분산형 버전관리 시스템을 사용하는 경우에는 각 커미터는 각자 저장소를 가지고 있습니다.
커미터가 아닌 개발자는 패치를 만들어서 메일링에 제안해야 합니다. 그러면 담당 커미터가 코드를 리뷰한 뒤에
문제가 없으면 적용하는 방식으로 프로젝트를 진행합니다.
커미터는 자신의 트리의 변경점을 메인 트리를 관리하는 PM(혹은 PL)에서 pull을 요청합니다. PM은 커미터의
트리가 문제가 없으면 merge 합니다.
사내에서도 동일하게 운영할 수 있습니다. 실력있는 몇몇 분을 커미터로 임명하고, 나머지 개발자분들은 패치를
제안하는 방식으로 할 수 있죠. PM이나 PL이 메인 트리를 관리하구요.
오픈 소스 프로젝트와 같이 개발자가 많은 프로젝트에 효율적입니다.
ps. patchwork나 lkml과 같은 툴이 있으면 좀 더 편리합니다.
Just do it!
그러고보니 svn / git 등의 사용방법에 대한
그러고보니 svn / git 등의 사용방법에 대한 문제가 아니라 개발 방식에 대한 의견같기도 하고...
패치 자체를 patch 디렉토리 따로 만들어 소스관리를 할 필요는 없어보입니다만,
패치 리뷰 프로세스를 적용하여서 "패치로 svn/git을 관리하자"는 의견을 수용할 수는 있겠네요.
1. 이슈 열림
2. 해당 이슈에 대한 패치를 첨부
3. 패치를 리뷰
4. 리뷰 완료. 패치 커밋.
이런 변경이력을 단순히 svn/git 레포지터리에만 남기면 과거의 이슈추적을 하기 조금 불편한 난점이 있습니다.
svn/git 레포지터러 + 이슈트래커의 조합을 고려해보시기 바랍니다.
그리고 이 방식을 제안하신 분은 약간의 패치 강박증이
그리고 이 방식을 제안하신 분은 약간의 패치 강박증이 있어보입니다.
패치 그 자체가 하나의 완벽한 것이면 좋겠지만 리눅스 커널과 같은 프로젝트에서 조차도 조그마한 실수가 보이기 마련입니다.
패치를 좀 더 잘 만드려면 git같은 분산환경을 고려해보시는게 어떨까 합니다.
local로 패치 만들어 이슈트레커에 올리고, 이게 마음에 안든다면 이걸 다시 수정해서 다시 올리고... 이슈 트래커에서 최종 승인된 패치를 커밋/푸시하고
해당 패치는 git format-patch를 이용해서 이슈트래커에 최종 등록하면 그만이게 되겠지요. (마치 리눅스 커널 메일링리스트처럼)
나쁘지 않아 보이는데요?
방법 자체는
내가 바꿀 수 없거나 바꾸기 힘들고, 자주 업데이트되는 upstream 소스가 있는 경우 흔히 하는 방식입니다.
장점은, 패치들 자체가 영구적인 개발 이력으로 히스토리에 남지 않고
패치들중에 일부를 적용 안하거나, 순서를 바꾸기가 쉽습니다.
patch 자체를 나중에 개선하기도 쉽죠.
뭐 원할때마다 diff 를 떠서 적용할 수도 있지만 어쩌면 불필요한 히스토리를 많이 남기게 되고 실수하기 쉽죠.
Mercurial 같은 경우는 이걸 공식적으로 지원합니다. (mq extension)
단,
svn 과 어울리는 방식인지는 잘 모르겠습니다.
svn 은 single trunk 이외의 뭔가 다른 걸 하는순간 재앙의 시작이죠. :-)
공감입니다. SVN 가지고 브랜치 시작하면 재앙이
공감입니다. SVN 가지고 브랜치 시작하면 재앙이 시작됩니다. :)
브랜치를 시작하면 복잡하다는 건
브랜치를 시작하면 복잡하다는 건 동의합니다만,
다른 버전 관리 시스템에서는 브랜치 관리가 좀 쉬운가요? 그다지 svn에 비해 쉬울 것 같지는 않은데 경험해보질 못해서요.
----
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.
위에서 제안 주신것처럼 서브버전 메인 소스
위에서 제안 주신것처럼
서브버전 메인 소스 관리자 : 별도 존재
개발자 : 개발후 패치파일을 메인소스 관리자에 전송하여 메인 관리자가 확인후 서브버전 적용
의 방식으로 진행된다면 잘 융합될 수 있을 것으로 생각됩니다.
현재 적용하고 있는 방식은
서브버전 메인 소스 관리자 : 없음
개발자 : 개발 내용을 패치 파일로 생성후 패치 파일을 서브버전에 등록, 다음 개발시에는 원본에 일일히 패치 파일 적용후 개발
인게 가장 큰 문제점이라고 보이는 군요.
또 한가지는, 공동 개발 진행시에 서로가 작성한 소스의 적용의 문제인데
예를 들어 kernel/new_framework 을 개발중이라고 할때
서브버전 사용시에는
A 개발자가 특정 기능을 완료하여 커밋하면
B 개발자는 snv up 만 하면 A 개발자가 완료한 내용을 자기 소스에 적용하여 개발을 이어 나갈 수 있는데
패치 파일 형태로 개발시에는
A 개발자의 개발 내용을 자기 소스에 적용시키려면 이것 저것 좀 더 해야 한다는 단점이 있습니다.
개발 도중 롤백을 하려면 기존 패치를 단계별로 일일히 적용시켜야 하는 부분도 있지요.
========================
조직 : E.L.D(Embedded Linux Developer/Designer)
블로그 : poplinux@tistory.com
카페 : cafe.naver.com/poplinux
임베디드 리눅스 관련 프리렌서 지향
일단 적응할려면 script는 필수겠군요.
각 patch는 독립적으로 적용되는 것 같군요. 일종의 branch 인데...
Patch 순서도 지켜야할테고...
환장하겠군요.
글쓴 분께서 덧붙인 정보로 보건데, patch
글쓴 분께서 덧붙인 정보로 보건데, patch 방식으로 처리하자는 것은 좋지 않아 보입니다.
만약 patch간 dependency가 있다거나 하는 경우에는 상황만 악화시킬 것 같은데요?
자기 기능을 개발하려면 patch 몇번몇번을 적용해야 하고, 내용 revert하려면 어떻게 하라는 건지..
1. svn co -r1 svn://localhost/project/trunk ./src
2. svn co -r4 svn://localhost/project/patch ./patch
3. cd src
4. patch -p1 (tcp_patch.patch)
5. patch -p1 (udp_patch.patch)
6. patch -p1 (connect_patch.patch)
여기서 6번 과정이 끝난 후에는 저장소가 clean한 상태가 아니고, 변경 사항이 존재하는 상태로 간주되잖아요.
본인 변경 사항과 기존 patch 내용의 명확한 분리도 안 될 뿐더러 실수하기 좋겠네요.
글쓴분 동료께서 실제 개발중인 모듈 특성에 따라 그렇게 제안한 이유가 있을 것 같긴 한데, 그래도 svn에 patch 저렇게 쓰는 방식은 매우 좋지 않네요.
이미 분산버전관리 시스템 이야기가 나왔는데, patch 형태로 따로 관리/적용하면서 개발할 게 아니라 개발자별 branch를 가져가는게 나을 것 같기도 합니다.
현명한 의견은 아닌 듯 합니다.
별도의 커미터가 있는 상황이라면 모르겠으나 그렇지 않다면 패치는 좀 넌센스인 것 같습니다.
svn 매뉴얼에 Why Not Use Patches Instead? 라고 나와있는 부분이 있습니다.
패치 파일만으로 버전 관리를 하는 것에 어떤 단점들이 있는지 설명하고.... 그래서 서브버전을 써야 한다는 얘기죠. (궁금하시면 찾아보시길.)
처음 제안하신 분도 이런 패치의 단점을 모르고 있는 건 아닌 듯 합니다.
그러기에 패치 파일을 다시 서브버전에 등록해서 단점을 보완하자는 거겠지요.
허나, 별로 현명한 의견은 아니라고 봅니다.
패치 만드느라 서브버전의 장점마저 살리지 못하고, 서브버전만으로도 패치로 하고자 하는 바를 모두 할 수 있으니까요.
----
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.
작년에 조언 올렸던 글인데,. 이제 GIT 로
작년에 조언 올렸던 글인데,.
이제 GIT 로 변경할 예정입니다.
문제는 형상관리시스템만 GIT 로 바뀐 것 뿐이지 각 단계별로 patch 만들어서 관리하는 방법론은 그대로 유지될 듯하네요.
연구소의 모든 인원들이 반대하는 일인데 혼자 옳다고 주장하시니 난감할 뿐입니다.
========================
조직 : E.L.D(Embedded Linux Developer/Designer)
블로그 : poplinux@tistory.com
카페 : cafe.naver.com/poplinux
임베디드 리눅스 관련 프리렌서 지향
버전 관리 시스템에 대한 의견이 다르면 참 난감하지요
저도 회사에서 시니어가 git 쓰는 걸 싫어해서 저는 다른 팀원들과 git을 시니어는 혼자 svn 씁니다 -_-
형상 관리 시스템을 각각 따로 쓰신다면 개발상 문제가
형상 관리 시스템을 각각 따로 쓰신다면 개발상 문제가 많이 발생하지 않나요?
========================
조직 : E.L.D(Embedded Linux Developer/Designer)
블로그 : poplinux@tistory.com
카페 : cafe.naver.com/poplinux
임베디드 리눅스 관련 프리렌서 지향
혹시 제 글에 대한 답글이시라면
물론 안 좋죠 -_-a 근데 이 시니어가 고집이 보통이 아니라... 바꿀 수가 없었습니다(물론 저 혼자 git을 원한게 아니라 팀 개발자 5명 중에 3명은 git 한 명은 반/반 시니어 svn 이랬습니다). 그래서 제가 원래 팀에서 빌드 관련 담당하기로 했는데 짜증나서 저 쪽은 제가 안 한다고 해버렸죠 -_-;;
뭐 지금은 그래서 git, svn에서 따로 만든 후에 jenkins에서 합칩니다 -_-;; 이력 관리는 알아서 하는 걸로..