Subversion을 신뢰할 수 없다는데 어찌하면 좋습니까
글쓴이: roylory / 작성시간: 화, 2009/08/18 - 6:38오후
회사 내 소스 코드 버전 관리가 전혀 안되서 Subversion 사용을 건의했더니,
Flash 개발자가 한다는 소리가, 자신의 경험상 Subversion을 신뢰할수 없다는군요.
Subversion이 완전무결한 것은 아니며 Open source란 것은 상용 프로그램과는 달리 문제가 터져도 책임을 지지 않기 때문에 신뢰할 수 없다는 주장을 하는데요.
어찌나 구구절절 얘기를 해대는지, 회사의 윗분들은 테크니칼한 것은 모르시는 분들이라, 정말 그런줄 아시겠더라구요.
이런 주장에 대해서 어찌하면 좋을까요...
Forums:
몇 주 전 KDE 서브버전
몇 주 전 KDE 서브버전 저장소 리비전이 백만 찍었습니다. 단일 저장소 중에서는 최대규모죠. 이 정도면 충분할까요?
아니면 상용 SCM(제가 아는 건 퍼포스 하나 뿐이지만) 사용을 건의하셔도 됩니다. :p
---- 절취선 ----
http://blog.peremen.name
Perforce, Bitkeeper, Clear
Perforce, Bitkeeper, Clear Case 같은 비싼 거 사달라고 하세요~
---
Emerging the World!
Emerging the World!
그 의견에 적극 동감!
버전관리 도구는 필수적이니까요...
설마 그 플래시 개발자가 Adobe Version Que 를 사용해야 한다고 하진 않겠죠?
====
하나는 전부, 전부는 하나
그렇게 말하면
당연히 안사주고, 기존대로 FTP 쓰라고 할 것 같은데요-_-;
윗분들한테도 합리적으로 설명하면서, 말도안되는 플래시 개발자의 주장을 반박해야하는 상황이라서요...
FTP를 쓰고 계시는
FTP를 쓰고 계시는 중이라면 Subversion 안정성을 논할 수 있는 상황이 아닌 것 같습니다만;;;;
저장소가 깨지는 문제가 염려스러우시면 주기적으로 저장소를 dump해서 백업하시는 것도 괜찮을 듯 합니다.
음... 얼마나
음... 얼마나 구구절절하게 예기를 했는진 모르지만....
scm 잘 못쓰니까 또는 귀찮아서 쓰기 싫어서 그런게 아닐지 .....
서브버전으로 돌아가는 대형 프로젝트, 상용프로젝트 예를 들어보면 알겠지요....
제일 궁금한 것중에 하나가... 오픈소스는 책임지는 사람이 없어서 못믿는다라고 들은것 만으로 예기하는사람이 많은데...
그럼 사서쓰는 상용프로그램은 문제 생겨서 소스코드 다 날아갔다고 치면 무슨 책임을 져주나요... 기술지원말고 날아간 소스코드 다 자기들이 새로 짜 주기라도..??;;;
그런 프로그램들도 다 백업은 필수권장 사항 아닌가요..?
그 플래쉬 하는사람한테 어떤 경험을 했길래 신뢰할 수 없는건지 확인이 필요한것 같습니다. 실수로 저장소 깨먹고 이래서 신뢰 못하겠다 ... 이런거면 뭐 그냥 웃지요......
신뢰할 수 없다면 그러면 상용툴을 쓰자는거냐 물어보고 무슨툴을 쓰고싶고 그 툴이 어떤어떤 문제일때 어떤어떤 책임과 보상을 해주는지 말해보라고 해야죠.... 문제 생겼을때 책임질 곳이 없다는 그 말이 참 들을때 마다 궁금하네요 ㅎㅎ 얼마나 더 좋은툴이 있고 그 툴들은 어떻게 책임지고 보상해주는지....
위 문제에 제대로 대답 못한다면 scm 쓰기 싫어서 그런거같은데.. 그다음에는 구구절절히 scm사용 상의 장점을 어필하시는겁니다....
저희는 최근에 svn이랑 trac 갖추었는데... 회사 정책상 외부에서 접속은안되지만(뭐 외부접속이 크게 필요는 없지만 가끔 아쉬운정도...) 천국같아요 =333
3년전에 개발완료된 프로젝트 소스코드가 없어서 인수인계받고 초기버전 소스코드랑 디자인 캡쳐한 스샷한장 들고 죽어라 압박감느끼면서 새로만들어 보지 않는한(경험담... ㅠㅠ 회사에서 보면 안되는데 ㅋㅋㅋㅋ 그래도 디자인 비슷하게 하느라 픽셀단위로 좌표옮겨가면서 디자인맞춘거빼고는 뭐 할만했어요... (먼산..) )...
아니면 작업하던 파일이 갑자기 흔적도없이... 복구 툴 돌려도 존재조차 없는 상황에 맞닥드리지 않으면(이것도 진짜로...)..
소스 수정했는데 문제가생겨서 돌아가고싶은데 백없이 없을때... 등등
scm이 쓰기 싫어도 할수없죠.... 당해보면 안다는거... -_-^
부럽네요
부럽군요. trac까진 아니더라도 제발 svn이라도 썼으면 좋겠네요.
다음은 그 플래시 개발자가 보낸 메일의 일부입니다.
라고 하는데 전 사실 이게 뭔소린지 이해도 안되더군요. 이런 심각한 문제는 공론화 할테니 저한테 자세히 알려달라고 한 상태입니다.-_-;
이건 조심하셔야 됩니다
이건 그 개발자 분 말이 맞습니다. 서브버전이 개행문자 변환을 하기 때문에 \n이 \r\n으로 바뀌어서 .fla 같은 바이너리 파일이 깨질 수 있습니다.
이를 막기 위해서는 바이너리 파일은 svn:mime-type 속성을 application/octet-stream 으로 설정하여 개행문자 변환을 하지 않도록 해야 합니다. 이것만 하면 문제 없습니다.
ㅋㅋ
그게 그말이었군요 ㅋㅋ
binary파일을 엉하게 commit해놓고 subversion을 신뢰할수 없다니 ㅋㅋ
그리고 eol style도 지정할수 있는데 말이죠...
그리고 대부분의 svn client가 .fla의 mime-type를 자동으로 application/octet-stream으로 잡을텐데...
그 플래시 개발자는
그 플래시 개발자는 저런 이슈가 나왔을 때 구글 검색 한 번만 했어도
해결 방법을 알고 계속 잘 사용했었을텐데..
새로운 거 배우기 싫어하는 사람들이 꽤나 있습니다.
잘 배우면 생산성에서 엄청난 향상이 있을텐데도..
...
제가 알기로는 ftp로 전송해도 파일타입을 text로 설정하면 똑같은 문제 생길 수 있습니다.
자, 이제 ftp도 같은 문제가 있으니 ftp를 쓰지 말고 우리 모두 USB에 복사해서 중앙서버에 들고가서 물리적으로 카피하자고 주장을 하심이... (퍼억...)
동감입니다...
SVN을 제대로 사용하지 못해서 신뢰를 못하는듯 합니다..
인용 : // 신뢰할 수 없다면 그러면 상용툴을 쓰자는거냐 물어보고 무슨툴을 쓰고싶고 그 툴이 어떤어떤 문제일때 어떤어떤 책임과 보상을 해주는지 말해보라고 해야죠.... //
간단 명료하네요..
그 플래쉬 개발자 분께서 그나마 써보신 형상관리가 SVN밖에 없을듯합니다.
고통이 지천에 있다한들 어이해 멈출수있더냐
상용은 문제가
상용은 문제가 생기면 판매사에서 책임지나요?
책임안지는건 둘다 똑같다고 알고 있었는데...
+++ 여기부터는 서명입니다. +++
국가 기구의 존속을 위한 최소한의 세금만을 내고, 전체 인민들이 균등한 삶을
영위할 수 있는 착취가 없는 혁명의 그날은 언제나 올 것인가!
-- 조정래, <태백산맥> 중에서, 1986년
+++ 여기부터는 서명입니다. +++
국가 기구의 존속을 위한 최소한의 세금만을 내고, 전체 인민들이 균등한 삶을
영위할 수 있는 착취가 없는 혁명의 그날은 언제나 올 것인가!
-- 조정래, <태백산맥> 중에서, 1986년
그렇죠. 상용사가
그렇죠. 상용사가 책임을 지려면, 그 문제에 대한 다른 client에 대해서도 책임을 져야 하는데, 상용사는 책임을 지는 것이 아니라, 책임을 회피하려고 하는 족속임을 이해 시키는 것이 좋은 방향일듯 싶습니다.
Clear Case는
Clear Case는
Word 문서도 해주는 것 같던데.. 자세한건 모르겠습니다.
예전에 윈도우용 CVS를 쓴적이 있는데..
소스가 옛날껄로 뒤집어 지는 현상이 생겨서..
엄청 당황했죠.. 어디까지 뒤집어 졌는지.. 알수도 없고..
대충 눈에 보이는 것만 찾아서 고쳤었는데..
돈많으면.. 사달라고 하세요. 플래쉬 개발자 말도.. 1%로 정도는 일리 있는것 같네요..
============================================================
선한 인간이냐 악한 인간이냐는 그사람의 의지에 달렸다. -에픽테토스-
의지 노력 기다림은 성공의 주춧돌이다. -파스퇴르-
============================================================
============================================================
선한 인간이냐 악한 인간이냐는 그사람의 의지에 달렸다. -에픽테토스-
의지 노력 기다림은 성공의 주춧돌이다. -파스퇴르-
============================================================
svn은 cvs와는 달리
svn은 cvs와는 달리 데이터를 이진파일로 관리한다고 알고있는데, 아닌가요?
CollabNet
아니면 CollabNet 같은 회사에서 Subversion 지원 계약을 사시는 방법도 있습니다. 문제가 터지면 100% 책임져 줄 겁니다.
CollabNet은 Subversion 개발자들을 고용하고 오픈 소스에 투자하는 회사입니다.
CollabNet 한국 지사 전화번호는 02-722-8271이라고 하니 책임져주는 상용프로그램 벤더가 필요하시다면 전화해 보십시오.
플래시 개발자
플래시 개발자 입장에서는 직접 겪어본 일인데 무조건 아니라고 하면
당연히 받아들일 수 없겠죠. 상용 버전관리툴 사용할 때에도 바이너리
파일은 브랜칭을 하거나 머징을 할 때 문제가 생긴 적이 종종 있습니다.
(바이너리 파일은 머지기 큰 의미가 없기도 하죠.. -.-) 관리자가
수정하기 전까지는 딱히 방법이 없는 경우가 많았고요.
글쓰신 분도 동일한 플래시 개발자라면 작업하는 방식을 보여주면서
반대하는 사람을 납득을 시켜야 하고 아니라면 '내가 책임질테니 가자.'
라고 하는 수밖에 없겠죠.
저는 플래시 개발자가 아니고요.
저는 해외에 있고 그 사람은 한국에 있는데, 이메일을 하나하나 트랙해가면서 소스 버전 관리해야할 상황입니다.
물론 설득시키는 것도 이메일. 그것을 반박하는 것도 이메일. 악순환으로 이메일만 산더미처럼 쌓이네요.
이래저래 코드보는 시간보다 Outlook보는 시간이 3배쯤 많은듯. ㅠㅠ
SVN을 쓰면 FTP보다 용량을 많이 잡아먹어서 안좋고, 오픈소스라 안좋고, 자기 경험상 확신이 안선다는 등...
제 성격에 옛날 같으면 코메디하냐고 욕했을텐데, 새 직장 와서 잘 모르는 사람한테 그러기도 뭐하네요...
잘 말해야죠;;
한두번의 이메일로
한두번의 이메일로 안될때는 전화를 사용하는 것이 더 효과적입니다. 정 안되면 혼자라도 버전 컨트롤 시스템 사용해도 됩니다. 전 mercurial 사용하는데, svn도 그렇겠지만 아무 디렉토리나 그냥 init 해버리면 되기 때문에 왠지 부담이 없더군요. 조만간 /etc/ 도 init 하려 합니다.
직접 만나기
직접 만나기 어렵다면 메일로 이야기하지 말고 전화로 잘 이야기해 보세요. 이미 감정이 안좋아진 것 같은데 그렇다면 아무리 메일로 치고박고 해봐야 소용 없을 겁니다. 상대방이 인식하고 있는 문제점이나 좋지 않았던 경험에 먼저 공감을 하시고 그것을 어떻게 해결할지를 상대방 입장에서 생각해 보시는게 필요할 것 같네요. 물론 저도 말은 이렇게 하지만 절대 쉽지 않지요.
어쨌거나 메일로 계속 핑퐁쳐가면서 가게 되면 절대 쉽게 해결되지 않을 것입니다.
개인적으로는 FTP나
개인적으로는
FTP나 하드 백업은 돼지 저금통이고
버전 관리 시스템은 은행이라 생각 합니다.
어디가 더 안전하고 효율적일지는 잘 따져 봐야겠죠.
은행도 언제나 털릴 위험이 있기는 하지만...
개인적으로는 "FTP로
개인적으로는 "FTP로 관리한다"를 돼지 저금통이라고 하기 보다..
멍멍이가 흙파서 땅에다 묻어 두는 수준이라고 보겠습니다.
여친이 길르는 용..
어떠한 이유에서건 -
어떠한 이유에서건 - 그러니깐 그게 사용자가 잘못 다루었던 것이든, 설정을 잘못했던 것이든, 프로그램 자체의 문제였든 ... 등등 .. - 한번 밉보인 제품은 ... 그러니깐 찍힌 제품을 다시 쓰게 되는 것은 메우 어려운 일입니다.
남이 아무리 옆에서 설득을 하려고 해도 아주 획기적인 것을 보여주지 않고서는 그 문제를 당했던 당사자로서는 그 제품을 다시 사용하기가 꺼려질 수 밖에는 없습니다.
제가 예전에 넥x 타이어를 장착하고 길가다가 앞뒤바퀴가 한꺼번에 펑크가 나서 도로에서 반바퀴 빙 ... 돈 다음에는 그 회사 제품 타이어는 쳐다도 안 보는 것과 같은 이유가 될 겁니다. - 이게 무슨 넥슨의 카트라이더에서 드리프트 하는 것도 아니고 ...
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
http://akpil.egloos.com
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
인용:제가 알기로는
그렇지 않습니다. 대부분의 FTP 클라이언트들은 사용자가 일부러 뭔가 설정을 해주지 않는 이상 정상적으로 파일을 전송해서 아무 문제도 생기지 않습니다. 하지만 svn은 일부러 설정을 해줘야 문제가 안 생기죠. 기술적으로 보면야 설정 하나 차이지만 UX 관점에서 본다면 svn은 실수를 유발할 가능성을 높은 반면 FTP는 그런 실수의 가능성이 거의 차단되어 있죠.
사실 svn에는 이런 종류의 실수 가능성이 꽤 많습니다. 한 예로, rename이나 delete, move 등을 할 때도 svn 명령을 이용해서 해야 하고 그냥 file system으로 조작하게 되면 꼬이는 경우가 생깁니다. 이 점이 CVS랑 다른 점이죠. tortoisesvn 등에서도 아무 생각 없이 삭제나 rename을 하면 꼬이는 상황이 생깁니다. 그래서 svn의 rename 지원이 오히려 UX적으로는 CVS보다 퇴보한 결과를 낳았다고 보는 사람도 많죠.
수년 간 CVS, SVN, SourceSafe 등의 SCM을 개발자, 디자이너, 기획자, 팀장들에게 쓰도록 해온 경험으로 볼 때, SCM을 자유자재로 쓰게 만드는 일이 더럽게 어려운 것임은 틀림 없습니다. 차라리 컴맹에게 자바를 가르치는 게 더 쉬웠던 듯.
어쨋든 그 플래시 개발자를 무지한 고집불통으로 몰아가는 분위기는 참 맘에 안 드는군요. 그런 식으로 접근하는 것은 옳은 일도 아닐 뿐더러, 문제 해결에 아무 도움도 안될 겁니다.
그정도면 무지한 고집불통 맞습니다
FTP는 히스토리 기록이 안되기 때문에 SVN에서 할 수 있는 모든 실수를 합친 겁소다 더한 실수를 한방에 할 수 있으니까요.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
히스토리
뭐 날짜별로 yyyymmdd 디렉토리 만들어서 관리하는 거 아닐까요.
FTP를 쓴다고
FTP를 쓴다고 히스토리 기록이 안된다는 것은 고정 관념입니다. 다양한 workaround가 있죠. 약간만 보완해주면 FTP도 충분히 SCM으로 기능할 수 있습니다.
디자이너, 플래셔들과 수도 없이 협업해본 경험상, 그들에게 svn을 교육해서 쓰게 하는 것보다 FTP 그냥 쓰게 하고 약간 보완만 해주는 것이 훨씬 생산성이 높습니다.
개발자 입장에서야 SCM이 어렵든 말든 익혀야 하는 것이지만 바이너리 파일 다루는 사람들에게는 diff도 안되는 SCM은 별 메리트가 없습니다. 차라리 원시적으로 파일명에 날짜 붙이는 게 디자이너들에게는 더 쉽고 편하면서 SCM의 목적은 다 달성할 수 있는 방법입니다.
SCM은 교조적으로 접근할 문제가 아닙니다. 디자이너/플래셔들과 협업할 때는 좀더 실용적인 대안을 찾아야 할 겁니다.
바이너리 관리를
바이너리와 텍스트 관리를 이원화하는 것이야 충분히 가능한 일이죠.
어플리케이션이나 웹개발에서도 보통 이미지나 그런 리소스는 따로 빼서 관리하는 경우가 많으니까요. 특히 웹 쪽이라면 실제 서비스 자체에서 html 서버랑 이미지나 리소스 서버를 따로 구성하는 경우도 있고요.
그런데 문제는 원글에서는 소스코드 관리위해 도입한다는 상황으로 나와 있으니까 하는 말입니다.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
저는 원 글의 주장
저는 원 글의 주장 자체에 대해서 가타부타 말하고 있는 것도 아니고, 그 플래시 개발자의 주장이 옳다고 이야기를 하려는 것도 아닙니다.
제가 왜 위와 같은 글을 썼을까요? 한 번 생각해봐주시기 바랍니다.
인용:제가 왜 위와
그러지시 말고 직접 이유를 말씀해 주시면 안될까요? 독자가 글쓴이의 의도까지 짐작하리라고 생각하신다면 곤란합니다. 다른 분들은 모르겠는데요, 저는 그런 능력까지는 없습니다.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
>> SCM은 교조적으로
>> SCM은 교조적으로 접근할 문제가 아닙니다. 디자이너/플래셔들과 협업할 때는 좀더 실용적인 대안을 찾아야 할 겁니다.
이미 말을 했는데도 모르겠다니, 다시 생각해봐달랄수밖에요..
여기서 교조적으로 접근하는 사람은 없는데
누가 어떤 주장을 하는 것이 교조적이라는 것입니까? 무슨 말씀을 하시는지 모르겠군요. 소스코드 관리하는 데 SCM 쓰자는 건 당연한 건데, 혹시 그걸 교조적이라고 말씀하시는 거라면 FTP 계속 쓰겠다는 사람은 그럼 광신도라 불러야 하겠군요 -_-;;
단순히 소스코드를 버전관리하겠다는 걸 바이너리를 SVN에 잘못 집어넣었다 삽질한 미숙한 경험을 바탕으로 제대로 잘 알지도 못하면서 소스관리에 버전관리툴을 도입하지 말자는 무식해서 용감한 주장을 하는 사람이 잘못된 거지, 여기서 SCM이 교조적이니 하는 말이 왜 나오는지 알 수가 없습니다.
이렇게까지 말씀하셔 놓고서 왜 엉뚱한 방향으로 논의가 전개되는지 전 잘 이해를 못하겠네요.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
지금까지 SCM 안쓰던
지금까지 SCM 안쓰던 사람입장에서는,
"소스코드관리하는데 SCM쓰자는건 당연한거다" 라는 주장은 교조적으로 들릴 수 있습니다.
특히나 문제를 더 복잡하게하는건 "디자이너, 플래셔"에게는 바이너리 파일도 소스코드라는거구요.
저는 SCM쓰고 있고 그게 당연한건줄은 압니다만, 상대방의 입장에서 생각하자는겁니다.
그만큼 변화는 어렵다는겁니다.
환경이 변하길 원한다면 (그게 진실로 옳든 그르든) "내 말이 옳으니 따르라"라고 주장하기보다는
보다 현실적인 접근법을 찾자는게 요지입니다.
인용:특히나 문제를
어느 디자이너랑 플래셔가 이미지 파일이랑 fla 파일을 "소스코드"라고 부릅니까? 개발자가 "소스코드"라고 하면 당연히 텍스트 파일 이야기하는 건 줄은 IT회사에서 같이 일하는 다지이너면 대강 다 안다고 봅니다. 그런데 개발자가 "소스코드" 관리하자는데 엉뚱하게 이미지랑 fla 파일 이야기하면서 딴지 걸고 있는 건 남의 글도 제대로 안 읽고 달려들어 깽판 놓는 거로 들리거든요 개발자 입장에서는요. 개발자가 "소스코드" 관리하자는데 싫으면 자기 파일들은 등록하지 말고 개발자 소스만 SVN에서 checkout 하고 update만 받으면 될 거 아닙니까? 그런데 도입하면 안된다는 식으로 이야기하는 건 무식하고 용감한데다 쓸데없이 오지랍까지 넓은 거라고밖에 안보여서 세 성격으론 아무리 해도 저런 소리를 하면 되면 상대방 입장에서 이해해 줄 수가 없습니다. 자기만 FTP 쓰겠다고 우기는 거라면 몰라도 다른 사람도 그냥 FTP 계속 써야 한다는 말이잖아요.
"내가 FTP 쓰니까 너도 FTP 계속 써라" 그런 걸 바로 교조적이라고 해야 하지 않나 생각합니다. 거기다 이번 경우는 SVN에 대한 잘못된 지식으로 우기는 괘씸죄까지 추가군요.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
이제 별로 생산적인
이제 별로 생산적인 토론은 못 될 것 같습니다만, 한가지만 더 붙이죠..
"내가 FTP 쓰니까 너도 FTP 계속 써라"
이게 아니라,,
"지금까지 FTP 썼으니깐 앞으로도 FTP 쓰자" 라는 주장입니다.
변화를 할것인지 말것인지의 문제인거고, 보통 변화를 주장하는쪽이 좀 더 큰 책임을 지게 마련이죠.
넵.
넵. 그러겠습니다.
우선, 저는 svn 사용의 찬반 논쟁, 혹은 svn vs ftp 논쟁 따위를 할 생각은 추호도 없습니다. 제가 보는 관점은 "이 문제의 해결을 위해서 roylory님이 어떻게 접근해야 하는가"이고 그런 관점에서 볼 때, svn을 도입하자고 하는 주장 자체의 옳고 그름을 떠나서 접근법에 심각한 문제가 있다는 것입니다. 제가 쓴 글들은 그 문제를 드러내기 위한 글들이었습니다.
그럼 어떤 문제들이 있고, 어떻게 드러내려고 했는가.
가장 결정적인 문제는 상대방(플래시 개발자)를 무지한 고집불통 취급을 했다는 것입니다.
여기에는 두 가지 문제가 있습니다. 하나는 그것이 사실이 아니라는 것입니다. 지금까지 나온 인용만을 봤을 때, 그 사람이 open source에 대해 잘 모른다는 점만 드러날 뿐 지적 능력에 문제가 있다고 추정할 만한 근거는 전혀 없습니다. 그 사람의 경험과 관점을 생각해보면 나름대로 일리 있는 주장이라는 것입니다. 일리 있다는 것과 옳다는 혼동하지 말아주십시오. 제가 말하고 싶은 것은 그 사람은 정상적인 판단력을 가진 사람이라는 것입니다. 이 점을 의심할 만한 근거는 제가 보기에 전혀 없습니다.
반대로, roylory님은 정상적인 판단을 하고 있는가...라고 질문을 해본다면, 저는 의문입니다. 자기 팀에서의 논쟁에서 져서 다른 커뮤니티에 가서 상대방을 까대는 상황. 블로그나 트위터에서 그냥 투덜대는 것도 아니고 공개적인 곳에서 자기 팀원에 망신을 주는 행동을 하고 있습니다. 팀웍을 크게 해치는 행동이죠. SCM의 또 하나의 중요한 목적은 협업인데 SCM을 도입하느라 협업을 깨뜨린다면 본말이 전도되는 것이죠.
또 하나의 문제는, 그게 사실이든 아니든 그런 식으로 접근한다면 문제를 해결할 수 없다는 것입니다. 이건 굳이 설명하지 않아도 다들 아실 것입니다. 상대방을 고집불통으로 취급하는 순간 생산적인 해결책은 물 건너 갑니다.
물론 문제는 여기가 끝이 아닙니다. 더 큰 문제는 이 글에 답글을 다는 사람들의 분위기일지도 모릅니다. 그저 SCM 사용 찬반으로만 이해를 하고 SCM 사용에 찬성이면 우리편, 반대면 나쁜편으로 편가르기를 해서 답글을 달고 있죠. 구체적으로 그 회사 안에서 어떤 논쟁이 오갔는지, 회사 사정이 어떤지도 잘 모르면서 말입니다. 이래서는 roylory님은 자신의 잘못을 깨닫기보다, 아 나는 역시 잘했고 그 플래시 개발자가 나쁜 놈이군 하는 생각을 가질지도 모릅니다.
사실, 그 동안의 행적(?)으로 볼 때, 예진님도 이런 종류의 논쟁을 편가르기로 이해하는 경우가 많아보였습니다. 이쪽 편, 저쪽 편 나누고 약간이라도 저쪽 편을 도와주는 발언이 섞인 글을 쓰면 마치 그 사람이 저쪽 편의 주장을 전부 지지하는 것처럼 반론을 하곤 하셨죠. 이것은 그냥 감으로 드리는 말씀이 아니고 근거를 5건 이상 찾아서 보여드릴 수도 있습니다.
주장의 옳고 그름을 판별하는 것도 중요하지만 그 주장을 올바르게 전개해 나가는지, 그 과정도 중요합니다. 그런 과정에서 이 쓰레드의 원 글과, 몇몇 답글은 심히 유감입니다.
글 잘 쓰시네요.. ^^
글 잘 쓰시네요.. ^^
무슨 말씀인지 이제 대강 알겠습니다.
제 생각을 정리하자면 원글이 거짓이 아니라는 가정 하에 플래시 개발자는 "무지한 고집불통"이 맞다고 생각합니다. 무지하다는 것이 단지 어떤 기술적인 것을 모른다는 뜻이 아니라 "내가 전에 이런이런 문제가 있었는데 이런 점을 피해갈 수 있느냐?"고 이야기하는 것이 아니 그냥 "믿을 수 없다"고 단정해 버리는 것입니다. 이런 논리라면 플래쉬도 가끔 삑사리 나서 죽으니까 믿을 수 없으니까 아예 쓰지 말아야죠? 고집불통이라고 생각하는 이유는 SCM의 장점은 무시하고 단점만 부각시켜서 FTP만을 고수하는 태도 때문이라고 보고요. 최소한 FTP 저장소는 일단 유지하고 한번 SCM 도입을 주장한 사람이 별도로 테스트 서버를 만들어 운영해 보게 하자 이정도로는 나와야 정상적인 태도라고 보지 않으시나요?
저는 사실을 확인하는 것이 가장 기본적인 태도고 그 다음이 협업이라고 생각하기 때문에 저런 경우 상식적이고 정석적인 방법으로는 협업이 가능하다고 생각하지 않습니다. 사실을 기반으로 의견을 주고받지 않고 자신의 편의를 위해서 사실을 왜곡하는 사람과는 협업이 사실상 불가능하다고 생각하거든요. 제 기준에서 볼 때는 잘못한 건 플래시 개발자지 roylory님이 아니라고 봅니다. 이런 경우는 다른 정치적 방법, 즉 (1) 다른 내부자나 윗사람을 설득하거나 (2) 외부에 공론화해서 더 많은 사람의 지지와 의견을 모으고 최소한 심정적인 위안이라도 얻는다. roylory 님은 불행히도 (1) 번이 여의치 않아서 (2) 번을 시도하고 있는 것으로 봅니다. 물론 이것이 가장 현명한 방법이라고 주장하는 것은 아닙니다만 최소한 저 글에 나오는 플래시 개발자보다는 나은 태도라고 생각합니다. (물론 원글의 내용이 왜곡 없는 사실이라는 가정 하에서요.)
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
우리가 알 수 있는
우리가 알 수 있는 정보는 roylory님이 인용한 부분 밖에 없는데, 그 내용만 봐서는 플래시 개발자가 svn의 단점을 이야기하면서 믿을 수 없다라고 하긴 했으나, 제대로된 반론을 듣고도 계속 고집을 피울지 아닐지는 알 수 없습니다. warpdory님의 비유를 드신 상황과 비슷한 상황이죠. 그 사람은 그냥 "내가 svn 써봤는데 못 믿겠더라"까지만 이야기했을지도 모릅니다. 그 사람이 정당한 반론을 듣고도 고집을 피웠을 것이라는 것은 추측입니다.
사실을 확인하는 것도 그 사람 입장에서 생각해보세요. 아마 이렇게 생각할 겁니다. "아니, 내가 깨지는 거 다 경험해봤는데 또 무슨 확인!" 그 사람의 경험 한계 내에서는 합리적인 추론을 하고 있는 것입니다. svn에 대해 모를 뿐이고 알려주면 되는 문제지요. 사실 관계를 확인해야 하는 문제가 아니라, 제대로된 정보를 그 사람에게 제공해야 하는 문제죠. 그런데, 위의 답글들로 미뤄볼 때, 바이너리 깨지는 문제가 왜 발생하는지, 어떻게 피할 수 있는지를 제대로 알려줬을 가능성은 0입니다.
이왕 추측을 하는 거라면 지금 상황에서는 이런 추측이 더 가능성이 높지 않을까요?
1. roylory님이 svn을 쓰자고 주장한다.
2. 플래시 개발자, "그거 내가 써보니까 바이너리 깨지고 불안정하더라. 못 쓰겠다."
3. roylory님, "아니 개발자가 SCM 쓰는 게 당연하지! 불안정하긴 ftp가 훨씬 불안정하다. svn 얼마나 많은 사람들이 쓰는데!"
4. 플래시 개발자, "?!?!?"
물론, 이것도 추측에 불과합니다.
그래서, 이처럼 플래시 개발자와 roylory님 사이에 정확하게 어떤 토론이 오고갔는지 모르는 상황에서 일방적으로 한쪽을 비난하는 것은 옳지 않다는 것입니다. 다른 사람이 SVN에 대해서 제대로 설명하고 설득했으면 한 번에 납득했을 사람인지도 모르지요.
두 사람 사이에 오간 논쟁의 전문이 공개된다면 그 때는 판단을 할 수 있겠지요.
음 처음부터
음 처음부터 누구를 까달라고 한 것은 아니고, 이런 난감한 상태에서 어떻게하면 좋을지 물어본 거였는데...
SCM이 절실히 요구되는 환경에서 플래시 개발자가 말도 안되는 몇가지 이유로 SVN 사용을 반대하는 상황이었거든요.
물론 저로선 너무 어처구니가 없는데다가 제 편도 없어서 사실 이곳에서 위로받고 싶은 심정이 아주 없는 것은 아니었습니다만,
어떻게 하면 Subversion 자체를 신뢰할 수 없다는 사람을 설득할 수 있을 지 자체를 물어본 것입니다.
네, 그 심정은 저도
네, 그 심정은 저도 이해합니다. 그저, 글 쓰실 때 어처구니 없다는 식의 표현들만 좀 자제했어도 상황이 달랐을 것입니다. 원 글을 비롯해서 답글들을 보면 뭔가 책임을 상대방에게 넘기는 듯한 뉘앙스가 보이죠. 그런 점만 조심해주길 바라는 것입니다.
저는 지금까지 사람 수로 따지면 100명 이상, 횟수로 따지면 10회 이상 Subversion, CVS, SourceSafe 등을 개발자, 디자이너, 플래셔, 기획자, 매니저 등 다양한 직군에 쓰도록 교육/유도해왔습니다. 그 과정에서 당연히 많은 반발을 경험했죠. roylory님이 지금 경험하고 있는 것보다 훨씬 심한 상황도 많았습니다. 그 반발을 제가 그냥 말도 안되는 것으로 치부해버렸다면, 어처구니 없는 것으로 치부해버렸다면 저는 SCM 도입에 성공하지 못했을 겁니다.
그런 반발을 주의 깊게 들어야 합니다. 열심히 듣다보면 다 저마다의 일리 있는 이유가 있습니다. 나름대로 자신의 경험 한계 안에서 합리적으로들 행동하고 있구요. 그래서, 오히려 더 그들의 반발을 쉽게 접게 만들 수 있습니다.
사실 이건 SCM의 문제라기보다 갈등 해결의 문제입니다. 회사에서는 늘 갈등이 발생하는데 상대방이 비이성적으로 행동한다고 가정해버리면 갈등은 해결되지 않습니다. 상대방도 뭔가 합리적인 이유가 있기 때문이라고 생각하고 이해하려고 하다보면 어느 순간 답이 보이죠.
지금 상황도 마찬가지일 겁니다. 이 쓰레드에서도 하나 드러난 것처럼, 그 사람이 Subversion을 신뢰하지 못하는 이유는 바이너리가 깨진 경험이 있기 때문입니다. 그게 간단한 설정으로 해소할 수 있는 문제라는 점을 알려주고 시연도 보여주면 신뢰도 문제는 해결할 수 있을 겁니다. 물론, 신뢰도만 해결한다고 문제가 다 해결되는 것은 아니겠지만요.
또, 신뢰도가 정 문제가 된다면 위에 다른 분들이 언급한 것처럼 다른 상용 SCM을 도입하자고 할 수도 있고, 아니면 긴 역사 속에서 검증된 CVS를 쓰자고 할 수도 있겠죠.
제가 SCM을 도입하면서 가장 많이 받은 반발은 "어렵다"라는 것이었습니다. 그나마 FTP라도 쓰던 경우라면 좀 낫지만 윈도우 파일 공유로 하던 경우에는 난이도가 대폭 상승하는 걸로 느낍니다. 더 큰 문제는 개발자들이 자존심상 어렵다는 말로 반발하기보다는 다른 말로 반발을 한다는 것입니다. 그래서, 이 문제에도 신경을 많이 써야 할 겁니다.
아무쪼록 건투를 빕니다.
상대방에게..
상대방에게 어처구니 없다라고 반박 이메일을 했다면 모를까,회사의 공론의 장에서 그리 말했다면 모를까
그저 자유게시판인 이 곳을 통해서, 그 정도 느낌이나 감정은 말 할 수 있다고 생각 합니다.
그런 것까지 조심해야 한다라고 하면, 일반적인 게시판 글쓰기가 쉽지 않을 듯 싶군요.
어떻게 그런 능력이...
전 아무리 읽어봐도 이렇게 단언할 만한 정보를 얻지 못하겠습니다.
전 점쟁이가 아니라서 글만 보고, 사실관계의 실체가 무엇인지, 그 상대방이 어떤 사람인지 잘 모르겠네요.
그 사람이 고집불통인지 아닌 지, 지적 능력에 문제가 있는 지 아닌 지, 또는 그 사람이 정상적인 판단력이 있는 지 없는지도요.
지금 글쓴이가 겪고 있는 오해와 분쟁의 재판을 보는 듯 해서 글 달아 봅니다.
...
"svn은 문제의 소지가 있으니 다른 scm을 도입하자"라면 상관이 없겠지만, "svn은 문제의 소지가 있으니 ftp를 쓰자"는 좀 심하지 않습니까?
제 경험이나 여기저기서 주워들은 이야기를 보면, scm 도입에 저항하는 사람들 중 적지 않은 수가 scm 이전부터 문제를 일으키던 사람들이더군요. scm이 없을 때는 자기가 일으킨 문제를 누군가 (성실한/재수없게 걸린) 사람이 (인정도 못받고 밤새면서 -.-) 해결해 줘서 본인은 아무 불편을 못느끼는데, 커밋 로그가 남으면 그때부턴 빼도박도 못하지요.
그 플래시 개발자가 말하길,
이 정도면 무식한게 장땡이고 고집불통 맞지 않을까요?ㅎ
그런데 메일로만 커뮤니케이션을 하니, 윗분들한테는, 메일을 길게 쓰는 사람이 하는 말이 맞는 소리처럼 들리겠더군요.
이미 회사에서 완전히 찍혀버린것 같습니다 -_-;
메일로 반론을
메일로 반론을 조목조목 하세요. 그래도 윗사람들이 그 플래시 개발자 말만 듣는다면 조용히 이직 준비를 시작하시길 권합니다. IT 회사인데 버전관리 아직도 도입 못하고 저런 무개념이고 목소리 큰 사람 말 따라가는 윗사람들이 좌지우지하는 회사면 싹수가 노랗습니다. 사실 저런 사람은 진작에 짤렸어야 할 사람인데 ...
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
SCM이 바이너리
SCM이 바이너리 파일의 버전관리에서 딱히 큰 장점이 없는 것은 사실입니다. diff도 merge도 못하고 단순 히스토리 밖에 안되죠. 단순 히스토리를 관리하는 방법은 SCM 말고도 수십 가지는 있습니다.
open source에 대한 것은 단순한 무지가 아니라 아주 널리 퍼져 있는 편견입니다. 널리 퍼져 있는 편견이라는 것은 보통 사람은 잘 모르면 그렇게 생각하기 쉽다는 거죠. roylory님의 부모님은 open source에 대해 잘 알고 있으신가요?
SCM이 바이너리 파일의 경우는 용량이 늘어나는 게 사실이고 브랜치 만들 때마다 전체가 카피되는 것도 사실입니다. 디자이너나 플래셔들의 관점에서는 히스토리는 자기 컴퓨터에 다 보관이 되어 있으니까 FTP에는 최종 파일만 올리면 된다고 생각하기 쉽죠.
님이 인용한 글만 봐서는 open source에 대해 잘 모른다는 점은 드러나지만 고집불통의 증거는 전혀 안 보입니다. 이쯤에서 roylory님이 얼마나 설득력 있게 논지를 전개했는지도 봐야하지 않을까요?
어쨋거나, 함께 일하는 팀 동료를 이렇게 다른 곳에서 까대고 있으니 본인은 까댈 자격은 있는지 어디 한 번 보여주시죠.
원글에서 소스코드 버전 관리를 위해서 도입한다고 하지 않았나요?
지금 바이너리 파일 관리 이야기를 하는 것 같진 않은데요.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
저 플래시 개발자의
저 플래시 개발자의 관점에 대한 이야기입니다. 그 플래시 개발자는 바이너리 파일의 관점에서 svn을 보기 때문에 그닥 장점이 없어 보여서 반대 의견을 펴고 있는 것이기 때문에 svn에 반대한다고 해서 무지한 고집불통이라고 봐서는 안된다는 뜻입니다.
아니 플래시
아니 플래시 개발자들은 보통 소스코드랑 이미지 같은 바이너리랑 개념이 없어서 구분을 못하나요? 음 제생각엔, 그렇진 않을 거 같은데. 플래시 개발자에게는 소스코드 관리하자고 이야기해도 바이너리 파일로밖에 못알아듣는다고 하는 이야기처럼 들리는데요, 그런 거라면 지금 플래시 개발자 직업군의 수준을 낮춰 보는 위험한 발언이 아닌가 걱정됩니다 -_-;;
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
같은 문제인
같은 문제인 듯하군요. 위에서 제가 단 답글을 읽어보시기 바랍니다.
디자인 파트하고
디자인 파트하고 일 해보지 않으셨으면 말을 하지 마세요. (김병만 버전)
회사 다닐때 어쩌다보니 극과극의 일을 하게 되었습니다 - UI하고 디바이스 드라이버.
가끔 디자인 연구소(제가 다니던 회사는 연구소가 따로 있었죠)에서 오신분들하고 이야기하다보면,
기술적인 면에 있어서는 엄청 보수적이고 단순하게 가고싶어합니다.
"더 이상 복잡한건 싫다"라는 생각들이 많죠.
한편으로는 이해가 되기도 합니다. 다른거 하기도 바빠 죽겠는데, 프레임 레이트가 안 받혀주느니,
팔레트(색상)관리를 해야하느니, 그런거 이야기하면 짜증부터 나겠죠. 그래도 제 카운터 파트로
일하시던 분은 워낙 오래 같이 일한 분이고, 그분 바로 밑에 엔지니어 출신이 있어서 이야기가
비교적 쉽게 통하는 편이었습니다.
여담인데, 플래시 관련 컨퍼런스에서 SS전자 디자인 연구소에서 오신 분의 발표를 들었는데,
"오, 저 분은 디자인 파트치고 기술적인 면을 잘 아네"라는 생각이 들 정도로 인상적이었습니다.
이름도 약간 특이해서 기억하고 있었는데, 몇달전에 햅틱UI개발의 주역으로 신문에 나오더군요.
그런 '선'을 넘냐 못넘느냐가 결국 한 디자이너/엔지니어의 역량의 차이가 되겠죠.
얼굴도
얼굴도 모르고 엄밀히 말하면 팀동료도 아닌 아주 미묘한 관계인데...
구구절절 설명하기가 힘든데, 현재는 SCM이 아예 없는 상태입니다. 물론 저 자신은 로컬에 SVN server를 깔아놓고 쓰죠. 그렇지만 시시각각 나오는 고객의 요구사항을 한국팀과 계속 같이 반영해야 하는 상태입니다.
도저히 안되겠어서 SVN을 건의했는데, 플래셔의 반발이 있었던 것입니다.
지금도 당장 제가 바꾼 소스를 다시 이메일로 한국에 전달해야할 형편입니다. 이 업무 패턴이 다들 익숙한 것인지...
플래시 수정 사항에 대해서는 최신 .as 파일을 구할 수가 없어서 제가 고칠수 있는 간단한 것도 일일이 이메일로 요청해야하는 상황입니다.
이런 상태에서 Subversion을 신뢰할 수 없다고 하는 주장은 어처구니가 없더군요.
지금은 그나마 한 수위 낮춰서, 검토해보고 안전하다고 파악되면 조심스럽게 접근을 했으면 한다고 하네요;;
모두들 많이 조언 주셔서 감사합니다.
아 fla 도 아니고 as
아 fla 도 아니고 as 였군요. 액션스크립트 파일이면 그냥 플레인 텍스트 아닌가요?
그럼 지금까지 바이너리 어쩌고 이 글타래에서 논의가 더더욱 허무해지는군요 헐 ...
어쨌든 좋은 방향으로 검토중에 있다니 다행입니다.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
그 플래시
그 플래시 개발자 말은 FLA 파일이 안되서 문제가 있었던 경험이 있으므로 Subversion은 신뢰할수 없다는 거였죠;;
바이너리 이야기는
바이너리 이야기는 도입 여부와 관련이 있는 것이 아니고, 그 플래시 개발자가 svn에 거부감을 갖게 된 경험을 설명해주는 것이기 때문에 허무해하실 필요까지는 없습니다.
둘다 사용하는 방법도 제안해 볼수 있을것 같습니다.
시스템의 하드 공간의 제약이 없다면, svn, ftp를 둘다 사용하는 방안을 제안해 봅니다.
1. ftp 등록, svn 등록
2. ftp 사용시 svn에는 자동등록하는 방안(플래시 개발자를 위해서).
그럼 관리만 복잡해 질 뿐입니다
왜 무개념한 플래시 개발자 한명 때문에 다른 사람들이 모두 고생해야 합니까?
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
그런것도 일종의
그런것도 일종의 하위호환성 아닐까요?
내가 변화를 바란다면, 내 손해를 감수하고서라도,
변화를 거부하는 사람들에게 편의를 제공할 필요도 있다고 봅니다.
물론 능력과 여건이 된다면, 그사람을 자르거나, 내가 옮기거나 하는게 더 편한 해결책이겠죠.
@ 그리고 현재로서는 다른 사람 모두가 고생하는건 아니죠..
앞으로 그 사람을 뺀 나머지가 모두 새로운 방식을 문제없이 쓴다면,
그때는 변화를 더 당당하게 요구할 수 있겠지요.
방법은 정도 뿐입니다.
2005년도에 저도 비슷한 고민을 하고 있었습니다. 아래 URL참조
(http://kldp.org/node/61592)
당시 회사의 SCM tool이 워낙 느리고 문제인지라.
개인적으로 그리고 몇몇 의식(?)있는 분들은 subversion을 쓰고 싶어 했었죠.
지금은 회사의 공식 tool이 subversion입니다만.. 이렇게 되기 까지.. 제 경험상..
준비기간 1년, 제대로 셋팅되기 까지 1년이 걸렸습니다.
준비기간이란 subversion을 꼭 써야하는 분위기를 만드는데 걸린 시간입니다.
이 기간동안 제가 맘대로 control할 수 있는 project안에서는 subversion을 사용하고.
이 인원 바깥으로는 회사에서 요구하는대로 행동을 했었습니다.
제 경우는 일은 subversion으로 하고 1일 혹은 몇일 주기로 subversion의 변경사항을 한꺼번에 제가 혼자 PVCS에 commit하고 그 중간의 로그를 한번에 쓰는 방법을 사용했었지요..
개발경력 10년차 되는 사람들도 처음에는 subversion의 diff auto merge기능을 신뢰하지 않았습니다.
자기가 소스를 잘못 control해서 conflict가 나는데 이해를 못하고 뭐 이런 tool이 있냐고.. 소스를 올리지도 못하게 한다고 불평불만을 늘어놓고는 했지요...
1년 정도의 기간이 지난후에 개발에 관련된 사람들이 어느정도 공감대를 가졌습니다만.
여전히 회사에서 공식적으로 사용하는 데 까지... 오랜 시간이 걸렸습니다.
처음 글을 쓰신 분의 생각처럼 PVCS Full function을 구매해주지도 않으면서 개발자들이 신뢰하는 tool을 사용하지 못하게 하는 상황이였지요...
그리고 알고봤더니 사내의 모든 개발자들이 PVCS도 제대로 사용하지 못하고 새로운 tool은 무조건 거부하는 분들도 있었구요...
포기하지 마십시오. 다만.. 원하시는 대로 하시려면 힘들고 엄청 오래 걸릴꺼에요. ^^...
그럼 힘내십시오. ^^
PS : 옆에서 일하시는 개발자분중에도 그 플래쉬 개발자 같이 생각하시는 분들이 많으실 것입니다. ^^
?
참고로 trac도입에도 거의 2~3년이 걸린듯 합니다. ^^..
trac은 좀 다른 길을 걸었지요..
1단계 : trac을 보고 맘에 들어한다.
2단계 : 좀 공부해보더니.. 회사에서는 이런 툴 쓰면 안된단다.
3단계 : 좀더 공부하더니 토탈솔류션을 써야한다면서.. trac금지.
4단계 : 금지된 상황에서 업무 능률은 하강곡선......
다른 상용 토탈솔류션은 거의 무용지물....
5단꼐 : 상용 토탈솔류션 1년 사용후 결국.. trac으로 컴백...
이거 subversion이랑 trac도입 시나리오 나중에 정리하면 재미있고 좋은 글이 될것 같은 느낌이 드네요. ^^.
?
단순히 SVN 이
단순히 SVN 이 오픈소스라 신뢰할 수 없다는 게 아니라 뭔가 복잡한 문제(Flash 개발자의 경험)가 있는 것 같군요.
Flash 라는 특수한 환경 때문에 생기는 것 같은데..
일단 Flash 에서 소스 파일이라고 함은 fla 파일을 의미합니다. 그리고 이 fla 파일은 바이너리 파일이죠.. -_-;
물론 순수 텍스트로 구성된 ActionScript 를 이용해서 작성을 할 수도 있지만, 지금 말하고 있는 경우는 아닌 것 같구요.
그리고 fla 로 작성했다면, 순수 텍스트로만 되어 있는 코드를 따로 만드는 경우는 없을 거라 생각합니다.
as 라면 텍스트 파일이기에 SCM 에서 관리되는 게 당연히 맞지만..
fla 는 (소스 코드를 포함하고 있는) 바이너리이기에.. Flash 개발자의 말도 어느 정도 일리가 있다고 봅니다.
분명 fla 에는 소스 코드도 들어가지만, diff/merge 등의 SVN 의 핵심 기능들을 쓰지 못하고..
바이너리로 관리가 되고 예전에 안 좋은 경험이 있다면.. 저도 주저할지도 모르겠습니다.
--
Emerging the World!
Emerging the World!
그런데 FTP를 계속
그런데 FTP를 계속 쓴다고 해도 diff/merge가 안되는 것은 마찬가지잖습니까?
게다가 혹시 공동작업을 할 때 체크아웃 변경시에 FTP는 락을 걸어 주지도 못하고요.
SCM을 사용하면 최소한 체크아웃할 때 락을 걸어 보기라도 할 수는 있죠.
http://www.lookmumimontheinternet.com/blog/?p=54
게다가 Adobe 공식 사이트에서조차 플래시 버전을 관리하는 방법 중 하나로 버전 컨트롤 시스템을 권장하고 있습니다. 특히 아래 문서 맨 끝부분에는 플래시와 다른 파일을 같이 관리할 때는 버전관리시스템을 사용하는 것이 좋다고 친절하게 설명하고 있군요.
http://www.adobe.com/devnet/flash/articles/flash8_bestpractices_02.html
물론 예로 드는 버전 관리 툴의 목록 중에는 당연히 Subversion도 포함되어 있고요.
@ 원글 쓰신 분이 메일로 구구절절히 반론하는 것보다 위에 관리자한테 어도비 사이트 링크 보내주는 게 더 효과가 있을지도 모른다는 생각이 드는군요. 플래시 소프트웨어 만드는 애들도 이렇게 권장한다!!! (논쟁에서 권위에의 호소, 이 경우는 잘못된 권위가 아니라 충분히 연관성 있는 권위죠.)
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
안그랬으면 좋겠지만
안그랬으면 좋겠지만 사람은 경험을 토대로 판단을 하게 됩니다.
저 같아서도 과거에 문제가 생긴 툴은 꺼려지는게 당연할 것 같네요.
자의던 타의던 문제는 있었고 그걸 해결 할 방법을 알고 있고 툴의 장점이 더 크다면
사용하겠지만 나름 자신이 잘 쓰고 있는 방법이 있다면 굳이 바꾸고 싶어하진 않을겁니다.
방법은 단 한가지입니다. 직접적인 피해를 봐야지 그때야 깨닫죠.
누가 더 똑똑하고 누가 더 무지하지는 않습니다. 단순히 경험의 차이니까요.
잘 쓰던 사람도 운이 좋아 문제가 안생겼다가 문제가 생겨서 날려먹으면 차라리 안쓰고
다른 방법을 쓰던 것이 더 좋은 방법이 되니까요.
과거에 근무하던 회사에서는 들어가보니 소스관리 툴이 없었습니다. ftp같은 백업이나
있으면 말도 안하겠습니다. 소스는 개인이 압축해서 관리하고 협업이 필요하면 손으로
일일이 디렉토리 찾아가며 머징 하고 있더군요. 그래서 소스관리 툴의 장점에 대해서
보고서 작성해서 올렸지만 가볍게 무시 당했습니다. 그리고 한 1년 정도 지나고 회사 내에서
사고로 인해 소스를 거의 홀랑 날려먹게 되는 상황에 비슷한 상황이 와서야 저를 회의실로 부르더군요.
"너 svn 써봤냐?"
그렇게 해서 도입했습니다.
-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.
-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.
플래시 개발자의
플래시 개발자의 경험은 충분히 이해되고 svn 측의 잘못이라 생각됩니다.
등록된 확장자가 아니면 일단 무조건 바이너리 취급해 주는게 맞는거라 생각되네요.
설마 .fla 가 텍스트 형식으로 등록되어 있지는 않겠죠.
ftp 에서도 기본이 ascii 로 동작한다면 ftp 클라이언트 프로그램의 잘못입니다.
emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇 개 안돼요~
http://xenosi.de/
https://xenosi.de/
변종 ftp 서버는 없을까요?
죽어도 svn을 못쓰겠다면...
ftp 기반 버전관리 시스템이라도 도입해보는 것도 괜찮을 것 같네요.
찾아보니 http://www.prestosoft.com/fvc_ftpvc.asp 이런 제품도 있는 것 같네요.
한번 날려먹어봐야... 정신을 차림...
한번 제대로 날려먹어봐야... 사용하자고 합니다.
형상관리는 프로젝트에서는 기본일 뿐더러, 형상관리중에 가장 기본이 소스 관리라는 것을 왜들 모를까... - -;
음...
전체적으로 creativeidler 님의 의견에 공감합니다.
새로운 시스템을 도입하는 것은 어찌하였든 꽤 큰 비용을 지출하게 됩니다.
사용법을 숙지하고, 프로세스를 정의하고, 모두가 일정 수준에 도달할 때 까지..
교육과 연습, 시행착오를 겪어야 합니다.
특히나 빠듯하게 돌아가는 일정 속에서, 내 일 처리하기도 바쁜 상황에서..
learning curve 를 극복하는 동안에 겪게될 지연이나 시행착오들로 인해 피해가 돌아오게 된다면..
그 시스템의 도입에 더더욱 부정적인 입장을 보일 수 밖에 없습니다.
(대부분의 그게 충분히 예상되는 상황일 수도 있습니다.)
더군다나 과거의 안 좋은 추억이 있는 상태라면, 더더욱 그 각인을 해제하기가 어렵습니다.
그 담당자의 주장에 대해 일일이 반박하기 보다는.. 그 상황을 일단 받아들이시고..
적어도 소스 코드에 대해서는 SCM 의 효용성에 대해 충분히 납득시킬 수 있으실 테니..
전체적으로 관리/설정/운영/교육 방안 및 담당자.. 시행착오라던가 문제 상황 발생시 대응 프로세스..
사원들이 일정 수준에 이를 때까지의 주기적인 교육/지도 방안 등의 절차를 미리 마련해 두고..
우선적으로 소스 코드라던가, 필요한 파트에 먼저 도입을 하여..
그 효용성을 충분히 보여 준 후에, 스스로 사용 여부를 결정하게 하면 낫지 않을까 생각됩니다.
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』
딴 말
딴 말 필요없고...
Intel하고 AMD도 쓴다고 하십시오...
그 회사가 얼마나 대단한 회사인 지 모르겠으나 Intel과 AMD가 신뢰성이 부족한 버전 관리 툴을 쓰지는 않을 겁니다.
물론, 기능이 떨어지기는 합니다만, 신뢰성이 떨어지는 건 아닙니다.
Subversion을 신뢰할 수
Subversion을 신뢰할 수 없다고 하면 조금 방향을 돌려서 다른 VCS라도 써보자고 해보면 어떨까요. 요즘 Git, Mercurial, Darcs 등등 좋은 버전 관리 시스템이 많습니다. 예전에 많이 쓰이던 CVS라도 쓰는게 안 쓰는 것보다는 훨씬 나을 것 같습니다.
—홍민희 (VLAAH, LangDev)
음... 무지한
음... 무지한 고집불통 예기 까지 나오던데....고집불통이라 하기에는 조금... 아닌것 같네요...
플래쉬 개발자가 격은 상황정도면 충분히 동감은 갑니다...
예를들면 처음 쓰는 툴인데 사장님앞에서 데모한다고 커밋했던걸 체크아웃했는데 제대로 안돌아가서 죽어라 욕먹고 깨졌다거나 하면 누구나 이거 못쓰겠다 생각할 만 합니다... 사장님얼굴 붉어지는데 구글링하면 해결할수 있다라고 말하실분이.... 많진 않겠죠 =333 (실제로 이런 전개는 아니었으리라 생각됩니다만..)
설득이 도저히 안된다면 그냥 그 플래쉬 개발자 분만 ftp쓰시고 다른분들은 충분히 svn사용을 동감하신다면
동감하시는 분들끼리 사용하시면서 천천히 장점을 보여주면서 svn사용자 대열에 포함되도록 하는건 어떤가 합니다.
아니면 바이너리 파일들은 ftp로 소스코드만 svn으로 하자고 하시던가요 즉 문제가 생긴다고 하는부분만 따로 관리하면되니까요....
어차피 당장 무조건 전격적으로 도입하자는것도아니고 한두달 시험운용 해보고 도저히 아니다 싶으면 빼자 라고 하고 추진할테니까요...
p.s.
이건 몰랐던 문제네요... 구글링 해보면 알 수 있는 문제지만 그래도 갑자기 당하면 당황스럽겠죠...;
플래쉬 개발자분에게 해당문제였는데 svn 관리자한테 문의 안해봤는지 물어보시던지 하시고... 그문제 해결된 버전이니 테스트 해보라 하시는게 어떨까 싶습니다.
p.s2
근데 몇번씩 당했으면 관리자에게 안물어봤단 예긴가요...; 관리자한테 계속 이런문제 생기는데 해결해달라고 하면 될것을 ;;;;