vss 와 cvs 의 장단점에 대해...

zelon의 이미지

제가 아직 CVS 를 많이 다루어 본건 아니구요. VSS 를 많이 쓰다가 이제 CVS 를 이용해서 sourceforge 를 써보려고 하고 있습니다.

근데 제가 관련 문서들을 대충 훑어보니 CVS 는 이름 그대로 버젼을 관리하는 관리하더군요. 그리고 하위버젼이라는 개념과 충돌, 비교 등등이 나오더라구요.

VSS 에서는 간단히 하나의 파일에 대해 배타적인 Lock 을 겁니다. 만약 누군가 a.cpp 파일을 지금 수정 중이라면 다른 누구도 a.cpp 파일을 수정할 수 없습니다. 물론 받아올 수는 있구요.

제 개인적인 생각으로는 VSS 의 장점은 서로의 코드가 꼬일 일이 없다는 겁니다. 물론 하나의 파일을 부득이하게 고쳐야 할 경우가 있을 수 있지만 하나의 코드에 액세스 하는 사람이 여러명이라는 건 클래스가 너무 커졌다던지(제가 주로 C++ 코딩만해서...) 등의 이유로 그건 소스가 나누어지는 게 맞다고 생각합니다. 결국 하나의 파일에 여러명이 접근해서 수정까지 해야할 일은 없다고, 없는 것이 좋다고 생각합니다. CVS 에서 같은 곳, 특히 하나의 함수의 내용을 완전히 다른 두 사람이 고쳤다고 하면 팀원끼리 얘기를 하라더군요 - 마소Jr. 참고 - 조금 그렇지 않나요? VSS 만 쓰던 저한테는 조금 이해가 안 가는 얘기처럼 들리더군요.

그리고 혹시나 CVS 에도 하나의 파일에 배타적인 락을 거는 옵션이 있는지도 궁금하구요. 제가 조금 사용해본 바로는 파일을 수정할 때 특정 체크를 안 하는 걸 봐서는 없을 것도 같은데...

간단히 정리하자면, 하나의 파일에 대해서 배타적인 락을 거는게 소스 관리 및 팀작업의 입장에서 좋을까요? 나쁠까요? :?:

File attachments: 
첨부파일 크기
Image icon diff.png111.99 KB
elecguy의 이미지

배타적인 락을 걸수가 있고..
충돌이 날 경우.. 충돌된 지점을 알려줍니다.
같은 부분을 수정했다면 누가 올바른지 컴퓨터가 알 수 없기 때문에.
당연히 사람들끼리(팀원) 이야기 해서 어느쪽을 포함할 지 결정해야겠죠?

폐인, 노가다 그 끝은..?

eungkyu의 이미지

뭐 vss를 안써봐서 자세한 것은 모르겠지만, 상용 프로그램이고 다들 편하다고 하는 visual studio에 있는 거라서 어떻게 뭔지 궁금해하고 있었는데...

겨우 visudo, vipw의 기능만 하는거였나요? :shock:
그건 아닌거 같은데;;;

하여간 lock만 거는 것은 문제가 많아보이는데요...
한 파일의 다른 부분을 같이 "편집"하는 것조차 불가능하다는 건지...
그럼 많이 수정해야 하는 파일이 하나 있고, 많은 사람들이 같이 고쳐야 하는 것이라면 시간을 나눠서 해야겠네요 :(

zelon의 이미지

Quote:
배타적인 락을 걸수가 있고..
충돌이 날 경우.. 충돌된 지점을 알려줍니다

CVS 에서도 배타적인 락을 걸 수 있다는 말씀이신지?.. 그리고 배타적인 락을 건 상태에서도 충돌이 날 수 있단 말씀인가요?.. @.@

Quote:
한 파일의 다른 부분을 같이 "편집"하는 것조차 불가능하다는 건지

네.. 그렇습니다. 하지만 하나의 클래스를 2명 이상이 고칠 필요가 있을 수도 있지만 전 만약 그렇다면 그 클래스는 나뉘어져야한다고 생각합니다. 어떻게 보면 전형적인 Client/Server 방식의 프로그래밍이라 생각할 수 있겠습니다.

클래스를 만드는 사람이 있고(인터페이스 제공), 그 클래스를 쓰는 사람이 있다면 그 클래스를 만드는 사람이 주로 고치고, 업데이트 할 것이며, 클래스를 쓰는 사람은 주로 헤더 부분만 받아서 쓰겠죠.

제가 프로젝트를 진행하면서 VSS 를 쓴지 1년 가까이 되는데, 충돌이 일어났을 때 얘기를 하는 것이, 업데이트 할 때 충돌을 감지해서 얘기하는 것보다 좋다고 생각합니다. 어떻게 보면 같은 함수를 같이 고칠 수 있으니까요. 그러면 누구 하나의 노력은 헛되이 될 것 같은 걸요.

Quote:
당연히 사람들끼리(팀원) 이야기 해서 어느쪽을 포함할 지 결정해야겠죠?

그리고 이 때 2개의 소스가 장단점이 있다면 다시 그 소스를 통합하는 데도 신경을 써야하지 않나요?

-----------------------------------------------------------------------
GPL 오픈소스 윈도우용 이미지 뷰어 ZViewer - http://zviewer.wimy.com
블로그 : http://blog.wimy.com

eungkyu의 이미지

zelon wrote:
Quote:
배타적인 락을 걸수가 있고..
충돌이 날 경우.. 충돌된 지점을 알려줍니다

CVS 에서도 배타적인 락을 걸 수 있다는 말씀이신지?.. 그리고 배타적인 락을 건 상태에서도 충돌이 날 수 있단 말씀인가요?.. @.@

Quote:
한 파일의 다른 부분을 같이 "편집"하는 것조차 불가능하다는 건지

네.. 그렇습니다. 하지만 하나의 클래스를 2명 이상이 고칠 필요가 있을 수도 있지만 전 만약 그렇다면 그 클래스는 나뉘어져야한다고 생각합니다. 어떻게 보면 전형적인 Client/Server 방식의 프로그래밍이라 생각할 수 있겠습니다.
클래스를 만드는 사람이 있고(인터페이스 제공), 그 클래스를 쓰는 사람이 있다면 그 클래스를 만드는 사람이 주로 고치고, 업데이트 할 것이며, 클래스를 쓰는 사람은 주로 헤더 부분만 받아서 쓰겠죠.


프로그래밍 패러다임을 version control system이 제어하는 자체도 마음에 들지 않지만, 설사 그렇다 하더라도 그럼 하나의 모듈은 꼭 한사람이 짜야 되는건가요? 클래스는 두사람이 짜면 안되나요? 파일을 둘로 나누는 거랑 그 파일을 몇 명이 고치느냐는 크게 관계가 없어보이네요.
Quote:

제가 프로젝트를 진행하면서 VSS 를 쓴지 1년 가까이 되는데, 충돌이 일어났을 때 얘기를 하는 것이, 업데이트 할 때 충돌을 감지해서 얘기하는 것보다 좋다고 생각합니다. 어떻게 보면 같은 함수를 같이 고칠 수 있으니까요. 그러면 누구 하나의 노력은 헛되이 될 것 같은 걸요.

충돌이 일어났을 때 얘기하는 거랑 업데이트할 때 충돌을 감지하는 거람 어떻게 다는건가요? 당연히 업데이트를 하려 하니까 충돌이 일어나는건데...
Quote:

Quote:
당연히 사람들끼리(팀원) 이야기 해서 어느쪽을 포함할 지 결정해야겠죠?

그리고 이 때 2개의 소스가 장단점이 있다면 다시 그 소스를 통합하는 데도 신경을 써야하지 않나요?


네. 뭐가 문제죠? 그럼 차례를 정해서 짜야 하나요? 아니면 한 사람이 한 부분을 짜면 다른 사람은 건들지도 말아야 하나요?
fender의 이미지

규모가 큰 프로젝트나 특히 오픈소스 프로젝트를 하다보면 하나의 파일을 두 명 이상이 수정 하는 경우가 발생할 수밖에 없습니다.

근래 유행하는 XP 같은 걸봐도 프로그램 소스는 공동 소유와 같은 개념으로 접근하기 때문에 "이 파일은 내거니까 아무도 손대지마!"하는 식의 태도는 용납하지 않는 경우가 많습니다.

물론 같은 파일을 여럿이 손보더라도 동시에 편집하지만 않는다면 문제는 없겠지만 같은 사무실에서 같은 시간대에 소수의 인원이 얼굴을 맞대고 개발하는 경우가 아니라 큰 규모의 오픈소스 프로젝 같이 다양한 시간대의 개발자들이 메일링과 같은 느슨한 방법으로 의사소통하는 경우에는 VSS 방식 보다는 CVS 방식이 훨씬 유용한 것이 사실입니다. 쉽게말해 어느 얼굴도 모르는 다른 나라 개발자가 중요한 파일에 lock 걸어 놓고 휴가 가버리면 어떻게 되나요? :)

CVS의 유용성은 거의 대부분의 성공적인 오픈소스 프로젝트들이 사용하고 있는 것으로도 어느 정도 증명할 수 있습니다. 더구나 요즘엔 diff와 merge 같은 것도 개발환경에서 워낙 잘 지원해줘서 특별히 어려움은 없다고 봅니다.

그럼~

덧말 : 그런데 왜 이런 내용의 토론에 조차 공격적인 답글이 달려야 하는지 모르겠네요... 제가 좀 민감한 건가요? :?:

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

elecguy의 이미지

제가 알기로는.
VSS(Visual Source Safe) 는 RCS(Revision Control System?) 계열입니다.
한 파일을 여러명이 동시에 수정못하는 단점이 있죠.
CVS(Concurrent Version System?)는 이름에서도 볼 수 있듯이 한파일을 여러명이 동시에 접근할 수 있게 기능을 추가한 것입니다.
CVS도 내부적으로 RCS를 쓰는 것으로 압니다.
따라서 CVS가 RCS의 상위버전이므로 그냥 RCS처럼 써도 아무런 문제가 없을듯한데요?
저는 M$의 VSS보단 CVS가 더 좋은것같은데요.

폐인, 노가다 그 끝은..?

unbalance의 이미지

Open Source 프로젝트 좀더 맞게 되어있는게 아닐지...
회사에서의 프로젝트와는 달리 엄격한 역활분담? 이 있는게 아니니깐,
누구나 고칠수 있게 한 것이 아닐런지요?

zelon의 이미지

Quote:
쉽게말해 어느 얼굴도 모르는 다른 나라 개발자가 중요한 파일에 lock 걸어 놓고 휴가 가버리면 어떻게 되나요?

근데 위의 인용은 update 시에 버젼 충돌 났을 때도 결국 같거든요. ^^;; 그쵸?

대충 이야기를 종합해보니 결국 같은 파일을 써야할 때가 더야할 때가 많고, 충분히 그걸 허용해야 한다는 거네요. 으음... 아직은 3명 밖에 작업을 안하고, 서울, 대구에만 있어서 그런가보네요. 잘 못 느낀 듯...

아마 사람마다의 기본으로 깔린 기준이 틀려서 그런 듯 합니다. 좀 고칠려고 노력해봐야겠습니다 ^^

Quote:
제가 알기로는.
VSS(Visual Source Safe) 는 RCS(Revision Control System?) 계열입니다.
한 파일을 여러명이 동시에 수정못하는 단점이 있죠.
CVS(Concurrent Version System?)는 이름에서도 볼 수 있듯이 한파일을 여러명이 동시에 접근할 수 있게 기능을 추가한 것입니다.
CVS도 내부적으로 RCS를 쓰는 것으로 압니다.
따라서 CVS가 RCS의 상위버전이므로 그냥 RCS처럼 써도 아무런 문제가 없을듯한데요?
저는 M$의 VSS보단 CVS가 더 좋은것같은데요.

그리고 elecguy 님 CVS 도 VSS 처럼 RCS 를 써서 배타적으로 하실 수 있다고 적으셨는데, 맞나요? 그렇다면 혹시 그렇게 세팅하는 관련 문서 같은 거라도 얻을 수 없을까요. 아직 익숙하지 않아서인지 일단 그런식으로라도 CVS 를 써보고 싶네요.

-----------------------------------------------------------------------
GPL 오픈소스 윈도우용 이미지 뷰어 ZViewer - http://zviewer.wimy.com
블로그 : http://blog.wimy.com

cjh의 이미지

원래 CVS의 기반 프로그램인 RCS는 파일에 락을
걸면 다른 사람이 열지 못했던 걸로 압니다. 그거랑
같은 것으로 생각되는데 CVS에서는 그렇지가 않네요.
RCS에서는 그게 당연했던게 같은 호스트에 모든
사용자가 로그인해서 써야 했으므로... 하지만 CVS에
그런 기능을 넣으려면 지금 하는 것 이외에 lock관리가
들어가야 하므로 문제가 더 생길지도 모르겠습니다.

제 의견으로는 소규모 개발이 아닌 이상 락을 건다는 건
소스 관리 서버쪽에서도 부하로 작용할테고, 충돌
처리가 제대로 되는 상황이라면 나중에 해결하는 것도
그리 나쁘지는 않아 보이네요.

--
익스펙토 페트로눔

fender의 이미지

zelon wrote:
Quote:
쉽게말해 어느 얼굴도 모르는 다른 나라 개발자가 중요한 파일에 lock 걸어 놓고 휴가 가버리면 어떻게 되나요?

근데 위의 인용은 update 시에 버젼 충돌 났을 때도 결국 같거든요. ^^;; 그쵸?

아... 아뇨, 그런 경우는 그냥 병합(merge)하면 되지요 :)

물론 정말 해당 코드가 엄청 복잡해서 당사자만 이해할 수 있다던지, 서로 다른 구현이 되서 뭔가 협의가 필요한 경우라면 문제가 다르지만 대부분의 경우 그런 식의 충돌은 간단한 버그 수정이나 코드 클린업 시에 발생하기 때문에 그렇게 복잡한 처리는 필요 없습니다.

그리고 간과해서는 안되는 게, 실제로는 같은 파일의 같은 부분이 아니라 서로 다른 부분을 수정하거나 하는 경우가 훨씬 많다는 점입니다.

예를들어 모듈을 나누어 개발하고 있지만 공통으로 사용하는 클래스가 있다고 할 때, 자신의 모듈작업에 필요한 메소드를 공통 클래스에 추가하거나 변경하는 작업이 꼭 전체 공통 클래스 소스에 대해 배타적인 락을 걸 필요가 없이 가능하다는 건 분명히 큰 장점이거든요.

그럼~

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

zelon의 이미지

Quote:
아... 아뇨, 그런 경우는 그냥 병합(merge)하면 되지요

아... 그렇군요. 그게 가능하네요. 하핫... ; 아직 CVS 에 대한 이해가 많이 떨어져서.... 여튼 둘다, 충돌이 안 나면 비슷하다는 생각만 하고 있어서... ^^ 죄송

그리고 저도 같은 파일의 다른 함수를 많이 건드린다면(제 생각엔 C 프로그램이 주로 그럴것 같다는 생각도 해봅니다) 무조건 CVS 의 손을 들겁니다. 락이라는 게 짜증나긴 하거든요. ㅋㅋ 그래서 저도 CVS 를 쓸려고 하지만 찝찝한게 버젼 충돌이라서 여러분들의 의견을 물어본 겁니다. 대략 보니 아무 문제 없다고 하시니뭐... ; 그래도 일단은 써볼렵니다.. :D

간단한 개인 의견을 덧붙인다면... 업데이트 시에 병합은 주로 프로젝트에서 제일 실력 좋은 사람이 해야겠군요? ^^;;; 아무래도 경험 많은 사람이 소스를 합치면 보다 방어적인 프로그램이 되니까요.

-----------------------------------------------------------------------
GPL 오픈소스 윈도우용 이미지 뷰어 ZViewer - http://zviewer.wimy.com
블로그 : http://blog.wimy.com

charsyam의 이미지

음... 제가 지금까지 VSS를 잘못 써온것이 아니라면,

VSS도 락을 걸어놓아도, 남이 수정할 수 있습니다. Check Out 이라고 하는데,

이걸 해 놓으면, 현재 이 사람이 이 파일을 수정하고 있다는 표시가 되게 되고,

그 수정 중에도 다른 사람이 다시 이 파일을 Check Out 받아서 수정할 수 있습

니다. 그리고 먼저 Check In 한것이 적용이 되죠. 단, 뒤에 사람이 다시 Check

In 을 했을 때, 충돌이 일어난다면, 현재 충돌이 일어난 부분을 보여주게 됩니

다. 그리고 그 부분만 고쳐서 다시 Check In 하게 되면 되는거죠. 음... 그럼

고운 하루되시길... 저 같은 경우는 VSS가 CVS 보다 편하더군요.

=========================
CharSyam ^^ --- 고운 하루
=========================

fender의 이미지

요즘엔 개발환경이 너무 좋아져서 diff도 아래와 같이 할 수 있습니다.

이클립스에서 CVS 버전과 작업 중인 버전을 비교하는 그림인데, 단순히 라인 단위 비교가 아니라 메소드별로도 관리가 되고, 충돌이 있을 경우 마우스만 가지고 병합이 됩니다. 스샷 자랑 겸 해서 올려 봅니다 :)

댓글 첨부 파일: 
첨부파일 크기
Image icon 0바이트

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

ux의 이미지

이건 cvs 메뉴얼 2.2.6 CVS locks in the repository 부분을 참고하세요

전에 왜 CVS에서 lock 지원을 고려하지 않았는지에 대한 내용을 메뉴얼에서 읽은 기억이 있는데 지금은 찾지 못 하겠네요 -_-;;;

그 때 읽은 기억으로는 개발의 효율성 때문이었습니다. CVS는 적은 규모의 하나의 장소에서 얼굴을 맞대며 개발하는 환경보다는 현재 Open source의 개발 환경을 고려했기 때문이라고 설명했었던거 같습니다.

얼굴을 맞대고 있으면 언제나 근무시간에 그 파일에 대해서 어떠한 요청을 담당자에게 해서 바로 적용한 결과를 받을 수 있지만, 여러 지역에 퍼져 있는 사람들과 공동 개발을 하면 요청의 결과를 언제 받을 수 있을지 보장을 하지 못 하고 개발 일정 자체가 미루어 지는 결과를 초래 할 수 있기 때문에 누구든지 수정할 수 있고 나중에 merge할 수 있는 hint를 제공하는 방법을 제공하게 되었다고....

그래도 메뉴얼 보시면, 개발자들 간의 communication을 강조하고 있습니다...^^;; 메뉴얼의 1.2 What is CVS not을 보시면 ....:)

@UX... Vnn~

zelon의 이미지

Quote:
VSS도 락을 걸어놓아도, 남이 수정할 수 있습니다.

VSS 에서도 그런 작업이 되었었나요?

처음 듣는 얘기네요. 제가 서버 설치부터 VC++ 6.0 ~ .NET 2003 까지 공동작업을 1년간 하면서 써봤는데 다른 사람이 CheckOut 했으면 그 사람이 체크아웃했으니 수정 못한다고 뜨던데요. 물론 거의 기본 세팅만 썼지만요. 혹시 옵션이 있다면 한수 부탁드립니다^^

저도 얼른 CVS 를 제대로 써봐서 효율성 많이 비교해보고 싶네요. 곧 간단한 문서하나 만들어보고 싶다는... 호홋

ps : kldp 에 처음 글써보는데 여러분들 너무 답변 잘 해주시네요. 감사~ ^^/

-----------------------------------------------------------------------
GPL 오픈소스 윈도우용 이미지 뷰어 ZViewer - http://zviewer.wimy.com
블로그 : http://blog.wimy.com

antz의 이미지

CVS의 경우 Lock 모드가 있기는 합니다. 하지만, 충돌로 비교해가며 소스를 수정하는걸 기본으로 하고 있지요.

전에 제가 Lock에 관련해서 사용해본것은

Quote:
cvs admin -L [file]
cvs edit [file]

이정도 인데, 다른사람이 Lock을 걸면, cvs edit [file]에서 Lock이 걸렸다고 메세지를 보냅니다.
또한 checkout 하려고 하면, Lock이 걸린 파일이라고 checkout 이 안됩니다.
(예전에 사용해봤던거라 틀릴 수 도 있습니다.)

사용자가 쓰기 편한걸로 사용하면 될것같습니다.
RCS, SCCS 는 lock이 기본적으로 사용되기 때문에 초보자 들이나 복잡한 툴에 관심이 없는 분들이 쉽게 사용하는것 같습니다.

crimsoncream의 이미지

기능상으로는 cvs나 vss나 거의 유사합니다. vss가 열심히 따라왔다고 봐야하는 건가요 :)
하여간 레퍼런스로 본 신뢰도 면에서는 cvs가 좀 앞서지 싶고 vss-visual studio vs cvs-non emacs user 라면 통합에 따른 편리함에서는 vss가 앞서지 싶은데요.
근데 항상 이런 비교에서 언급되지 않는데 제가 개인적으로 중요하게 생각하는게 있는데 cvs는 repository가 디렉토리로 구성되고 vss는 db로 구성됩니다. 취향의 차이인지는 모르겠지만 cvs 쪽이 백업받고 관리하기 편하더군요. 소스db가 커지면 vss는 좀 느려졌었다는 기억도 있고요.

오늘 우리는 동지를 땅에 묻었습니다. 그러나 땅은 이제 우리들의 것입니다.
아직도 우리의 적은 강합니다. 그러나 우리는 그들보다 많습니다.
항상 많을 것입니다.

zelon의 이미지

간단히 vss 의 단점을 얘기하자면 아무래도 vendor 에 종속적이면서 좀 더 자료를 구하기 힘든 감이 있습니다. 지금 제가 CVS 로 옮기려고 하는 이유 중의 하나이기도 하죠. 이상하게(바로 윗분의 말씀처럼) DB 가 꼬여서 인 것 같기도 하구요. 백업할려고 하니까... 조금은 난감하더군요. 일단 그 폴더째로 백업해놓고, 최신으로 업데이트를 다 시킨후, 새로 설치하고, 다시 연결시켜준다는....;

조금 유용하다 싶은 프로그램은 한가지 이유만으로 선택받는게 아닌가봅니다 :)

-----------------------------------------------------------------------
GPL 오픈소스 윈도우용 이미지 뷰어 ZViewer - http://zviewer.wimy.com
블로그 : http://blog.wimy.com

verotas의 이미지

zelon wrote:

그리고 혹시나 CVS 에도 하나의 파일에 배타적인 락을 거는 옵션이 있는지도 궁금하구요. 제가 조금 사용해본 바로는 파일을 수정할 때 특정 체크를 안 하는 걸 봐서는 없을 것도 같은데...

네 가능합니다. (위에 어떤 분이 쓰셨지만) 이걸 위해서 cvs edit 라는 명령을 제공하기도 하고, cvs admin(이건 rcs 명령을 그대로 쓰는 거지요)을 이용해서도 가능합니다.

*하지만* 가능하면, 아니 절대로 락을 걸어놓고 쓰는 일은 하지 마세요. 그건 CVS를 두번 죽이는 일이니까요 :-)

CVS는 불특정 다수 개발자가 동시 참여하는 프로그램 개발 프로젝트에서부터, html 텍스트 + 이미지 파일 범벅 웹사이트 관리, 대규모 텍스트 동시 공동 번역 진행, 몇십개 나라 언어로 리소스 번역을 동시에 진행하는 일까지 모두 가능하게 설계된 저자동-고유연 프로그램입니다.

CVS에서 배타적 락을 지원하는 것은 그게 꼭 필요해서나 좋아서가 아니라 선조격인 RCS가 지원하는 기능을 그대로 지원하다 보니 붙어있는 유물일 뿐입니다.
어떤 파일은 특별히 중요해서 뭔가 변화가 생기면 꼭 알아야겠다면 그땐 cvs watch 를 쓰시면 됩니다. 아니면 특정 모듈에 checkin이 일어날 때 메일로 알려주도록 설정해서 쓰시든가 뭐 하여튼 다른 좋은 대안이 많이 있습니다.

락은 어쨌든 적어도 CVS에서는 백해무익합니다.

Quote:

간단히 정리하자면, 하나의 파일에 대해서 배타적인 락을 거는게 소스 관리 및 팀작업의 입장에서 좋을까요? 나쁠까요? :?:

이건 CVS에 대한 질문이라기 보다는 개발 프로젝트에서 소스관리 정책에 대한 질문이군요.

CVS를 사용한다는 전제하에 락은 쓰지 말아야할 기능이라는 걸 말씀드렸지만, 이 질문에 대해서는 딱 잘라서 좋다 나쁘다로 이야기할 수 있는 건 아닌 것 같습니다.

저 같은 경우 사내에서 2~10명 정도 개발자들이 참여하는 프로젝트에 CVS를 계속 썼는데, 문제는 대체로 개발자들이 자기가 작성한 소스에 대해 애착이 강하고 배타적/독점적 소유권(?)을 원한다는 점입니다. 심지어 팀장이나 선임 개발자라고 하더라도 자기 소스를 건드리면 싫어하는 경우가 많죠. 오픈소스 프로젝트와 달리 사내에서 진행되는 프로젝트는 대개 어떤 모듈이나 소스 파일에 대해 owner 를 정해놓고 시작하는 경우가 많기 때문에, 이런 경우 CVS가 그 진가를 발휘할 수 있는 상황이 애초에 발생하지 않습니다. 그리고 모든 개발자가 CVS에 대해 잘 아는 상황에서 프로젝트를 시작하는게 아니기 때문에 (대개 한 프로젝트 끝날 때 쯤 되면 어쩌다 conflict 생겨도 팀장한테 안 달려가고 알아서 merge 처리할 정도가 되더군요) 혼란이 더 많이 발생하기도 하고요.

제가 하고 싶은 얘기는, 어떤 프로젝트냐, 어떤 팀이냐, 어떤 개발자냐, 어떤 매니저냐, 등등에 따라 답이 달라진다는 겁니다. 제 경험으로는, 심지어, 소스 관리 솔루션(같은 복잡한 물건)을 _전혀_ 쓰지 않는게 _결과적으로_ 훨씬 효율적이게 되는 상황도 실전에서는 심심찮게 맞닥뜨리게 됩니다. :-(

하지만 그런거 다 떠나서, 관련된 사람들이 똑똑하거나 아니면 서로 호흡이 잘 맞는다는 가정하에, 락 같은 거 안 걸고 작업하는게 훨씬 효율적입니다. 출퇴근 시간은 적어도 훨씬 자유로워지지요 ^__^

zelon wrote:
간단히 vss 의 단점을 얘기하자면 아무래도 vendor 에 종속적이면서 좀 더 자료를 구하기 힘든 감이 있습니다. 지금 제가 CVS 로 옮기려고 하는 이유 중의 하나이기도 하죠. 이상하게(바로 윗분의 말씀처럼) DB 가 꼬여서 인 것 같기도 하구요. 백업할려고 하니까... 조금은 난감하더군요. 일단 그 폴더째로 백업해놓고, 최신으로 업데이트를 다 시킨후, 새로 설치하고, 다시 연결시켜준다는....;

조금 유용하다 싶은 프로그램은 한가지 이유만으로 선택받는게 아닌가봅니다 :)

:-) 언급하신 얘기는 굳이 VSS vs CVS 만 아니라 Windows vs Linux 에 일반적으로 적용할 수 있는 얘긴거 같습니다.

Welcome to the Linux World !!

p.s. 1. 여기서 Linux는 (Linux | Unix | *BSD) 입니다. ^^;;
p.s. 2. 광고입니다. ^^;; 마침 제가 http://doc.kldp.org/wiki.php/CVS-FAQ 문서를 요즘 만들고 있는데, 오래된 기억과 메모를 더듬어가며 적다 보니 충분히 많은 *질문*을 확보하기 쉽지 않네요. VSS를 오랫동안 쓰셨다고 하니, 버전 컨트롤 프로그램에는 익숙하지만 CVS에는 생소한 사람 입장에서 생기는 의문이나 질문거리들을 생기는대로 좀 보내주시면 많은 도움이 될 것 같습니다. 미리 감사드립니다. 꾸벅.

The good is the enemy of the best.

zelon의 이미지

아래는 제가 위의 분께 드린 메시지... ^^;;;

Quote:

안녕하세요. 님께서 답변 달아주신 CVS 초보인 zelon 이라고 합니다... ;

제가 아직 위키도 제대로 써본 적이 없어서요... 일단 질문하라고 하시는데.. 으음.. 그냥 그 페이지를 고쳐도 되는지 확신이 없어서요.. 편집을 눌렀는데 대뜸 편집화면이 나오길래 놀래서 이렇게 메시지를 보냅니다. ^^;;

저도 막상 생각하려니까 안개처럼만 떠오르고 마땅히 생각이 안나기는하네요. 하핫. 간단히 긁적여볼께요.

  • pserver, ssh 등의 차이점. 이게 늘 궁금하더라구요. 대충은 알지만 좀 명확한 설명이 있으면 부담이 적을 듯하네요.

  • VSS 에서는 CheckIn, CheckOut 이라는 방법을 통해서 배타적인 락을 겁니다(내가 쓰겠다 - CheckOut), (난 다 썼다 - CheckIn) 이거와 매핑되는 동작이 CVS 에는 없다는 걸 잘 설명해주시면 좋을 듯... 각자 작업하다가 일단 update 를 할 때 충돌이 일어나면 병합을 잘(!) 해야한다는 걸 잘 설명해주시면 좋을 듯 하네요.

  • 보통 PPT 발표 때도 그렇지만, 2인 이상이 개발시에 일어날 수 있는 상황을 시나리오처럼 그려보아 주시면 최고죠. ㅋㅋ

  • 주로 쓰는 명령들에 대해서 간결한 표가 하나 있으면 도움이 될 듯.
지금 생각나는 건 대충 이쯤이네요. kldp 는 문서가 좀 많은 듯해서 네비게이션하는데 한번 갔던 곳을 다 저장해놓기도 그렇고 이상하게 다시 거기를 찾기가 쉽지않은듯.. (제가 kldp 초짜라...;)

문서를 제공하시는 분에게는 늘 고맙다는 말을 전하고 싶습니다. 후배 양성을 위해 길을 닦아놓으시는 분들.. ^^ 좋은 문서 기대할께요~~

[/]

-----------------------------------------------------------------------
GPL 오픈소스 윈도우용 이미지 뷰어 ZViewer - http://zviewer.wimy.com
블로그 : http://blog.wimy.com

skysign의 이미지

주제와는 좀 빗나가는 것 같지만...

subversion 은 어떠세요?

기능상으로는 CVS나 VSS 와 비슷합니다.

notexist의 이미지

Rational ClearCase는 어떤가요?

회사에서 써서 암 생각없이 쓰고는 있는데...

솔직히 저는 check in/out, update, compare, merge, label만들기

등 정도밖에 안 써서...뭐가 좋은지도 잘 모르겠습니다.

ClearCase도 배타적 락 걸수 있는데...option에서

reserved/unreserved선택할 수 있더라구요...

There is more than one way to do it...

neocoin의 이미지

skysign wrote:
주제와는 좀 빗나가는 것 같지만...

subversion 은 어떠세요?

기능상으로는 CVS나 VSS 와 비슷합니다.

정말 써보고 싶습니다. Eclipse 로 8명 정도가 cvs를 통해서 프로젝트를 함께 하고 있습니다. 물론, 초반에는 충돌 문제를 겪었지만, commit 인형으로 해결이 되었구요.

문제로 느끼는 점은 File Rename시 삭제후 새로운 파일 생성 개념으로 CVS가 받아 들인다는 점입니다. Eclipse의 Refactoring 기능을 사용하다 보니, 이런 일은 의식하지 못한체, 빈번하게 일어 납니다.

SubVersion 은 Http Protocol 기반에 프로젝트 전체를 하나의 이미지로 본다는 개념이라, Rename이라던지 파일 이동 자체를 수용하는것 같은데, 직접 써보신 분들은 어떤가요?

feanor의 이미지

Subversion 사용자입니다.

아무래도 가장 큰 차이점은 프로젝트 전체에 버전 번호가 붙는다는 점인 것 같습니다. CVS 에서는 각 파일에 버전 번호가 붙죠.

따라서 태그는 그냥 이름과 메타데이타를 가진 한 버전입니다. (따라서 상수 시간 작업입니다.) 브랜치도 비슷합니다.

svn cp, svn rm, svn mv 로 파일 복사/삭제/이동 되고요, 이렇게 복사나 이동을 해도 history 가 그대로 남습니다. svn mkdir, etc. 로 디렉토리 관리 됩니다.

HTTP (정확히는 Web-dav) 프로토콜 외에도 svn 자체 프로토콜이 있고, CVS 처럼 ssh 로도 됩니다.

디렉토리나 파일 별로 접근 권한을 설정할 수 있다는 이야기를 들었는데, 이 기능은 안 써봐서 모르겠습니다.

쓰다 보니 무슨 광고문 같이 됐군요. 하지만 사실인걸요. :-)

ktd2004의 이미지

Subversion을 사용하신다길래 혹시나 해서 질문을 하나 올려봅니다.
아직 리눅스에서는 SubVersion을사용을 못해봤구요..
윈도용 클라이언트 프로그램인 TortoiseSVN을 깔아서 Test해봤습니다.
(Win2000Pro SP3)
서버는 local 서버로 하구요..

그런데 문제가 되는게 하나 있더군요.

매뉴얼에는

../SVNRepo/ProjectName/trunk/여기에 실제 프로젝트파일들이 존재
../SVNRepo/ProjectName/branches
../SVNRepo/ProjectName/tags
../SVNRepo/AnotherProject/trunk/여기에 실제 프로젝트파일들이 존재
../SVNRepo/AnotherProject/branches
../SVNRepo/AnotherProject/tags

이런식으로 local 서버에 저장된다고 나오거든요.. 그리고 제가 원하는 방식도 이런 방식이구요..

project에 관련된 디렉토리는 매뉴얼에서 추천한대로

./TestProj/trunk/프로젝트파일들.
./TestProj/branches
./TestProj/tags

이런식으로 만든후에 import했습니다.

그런데 아무리 해도 파일들이 저장된게 보이지 않습니다.
(CVS인 경우에는 ,v 파일로 각 파일이 저장된게 보이잖아요.)
그런데 기본적인 동작(checkout..)을 합니다.

제 생각으로는 내부에 db 파일에 모든 파일이 한꺼번에 저장되는 것 처럼 보입니다.

혹시 이 부분에 대해서 알고 계신분계시면 답변 부탁드리겠습니다.

한번 써보려고 하는데 이부분에서 막혀서 더 이상 나가질 못하겠네요.

monpetit의 이미지

김태동 wrote:
그런데 아무리 해도 파일들이 저장된게 보이지 않습니다.
(CVS인 경우에는 ,v 파일로 각 파일이 저장된게 보이잖아요.)
그런데 기본적인 동작(checkout..)을 합니다.

제 생각으로는 내부에 db 파일에 모든 파일이 한꺼번에 저장되는 것 처럼 보입니다.


맞습니다. db 파일 속에 저장됩니다.
저장소의 파일은 svnlook 명령을 통해 확인할 수 있습니다.
BL의 이미지

subversion 윈도우 버전은 디렉토리쪽에 문제(삭제가 안되고 이름바꾸기도 아마 문제가 있는듯...)가 있더군요. 그래서 아직 도입을 미루고 있습니다. 이슈 트렉킹을 보면 arp문제라는데 아파치쪽에서 아직 해결을 안해줘서 계속 연기되고 있더군요. :?

혹시 대형 바이너리 파일용으로 써도 될만한것이 있을까요? 자동으로 압축저장되고 commit, update, log, mv, cp정도만 잘되면 좋을텐데요.

verotas의 이미지

zelon wrote:

안녕하세요. 님께서 답변 달아주신 CVS 초보인 zelon 이라고 합니다... ;

제가 아직 위키도 제대로 써본 적이 없어서요... 일단 질문하라고 하시는데.. 으음.. 그냥 그 페이지를 고쳐도 되는지 확신이 없어서요.. 편집을 눌렀는데 대뜸 편집화면이 나오길래 놀래서 이렇게 메시지를 보냅니다. ^^;;

그냥 편집하시면 됩니다. ^^ 누구나 처음엔 다 겪는 일이니까 넘 놀라지 마시구요.

Quote:

저도 막상 생각하려니까 안개처럼만 떠오르고 마땅히 생각이 안나기는하네요. 하핫. 간단히 긁적여볼께요.
  • pserver, ssh 등의 차이점. 이게 늘 궁금하더라구요. 대충은 알지만 좀 명확한 설명이 있으면 부담이 적을 듯하네요.

  • VSS 에서는 CheckIn, CheckOut 이라는 방법을 통해서 배타적인 락을 겁니다(내가 쓰겠다 - CheckOut), (난 다 썼다 - CheckIn) 이거와 매핑되는 동작이 CVS 에는 없다는 걸 잘 설명해주시면 좋을 듯... 각자 작업하다가 일단 update 를 할 때 충돌이 일어나면 병합을 잘(!) 해야한다는 걸 잘 설명해주시면 좋을 듯 하네요.

  • 보통 PPT 발표 때도 그렇지만, 2인 이상이 개발시에 일어날 수 있는 상황을 시나리오처럼 그려보아 주시면 최고죠. ㅋㅋ

  • 주로 쓰는 명령들에 대해서 간결한 표가 하나 있으면 도움이 될 듯.
지금 생각나는 건 대충 이쯤이네요. kldp 는 문서가 좀 많은 듯해서 네비게이션하는데 한번 갔던 곳을 다 저장해놓기도 그렇고 이상하게 다시 거기를 찾기가 쉽지않은듯.. (제가 kldp 초짜라...;)

문서를 제공하시는 분에게는 늘 고맙다는 말을 전하고 싶습니다. 후배 양성을 위해 길을 닦아놓으시는 분들.. ^^ 좋은 문서 기대할께요~~

이 질문들은 이왕이면 연습 겸 직접 편집해서 올려주심 더 좋겠구요.
FAQ에 답하기엔 조금 그런 얘기만 여기다 적죠.

"주로 쓰는 명령들에 대해 간결한 표"는 cvs --help-commands 해서 나오는 명령 리스트와 웹에서 구할 수 있는 Quick Reference Card(http://tnerual.eriogerg.free.fr/cvsqrc.pdf) 중간쯤 되는걸 말씀하시는거 같은데, 맞다면 지금 만드는 FAQ 내용이 어느 정도 더 불어나고 나서 한번 정리해볼 생각도 있습니다.

2인 이상 작업할 때 시나리오라면 아쉬운대로 KLDPDoc 에 있는 CVS-Tutorial 을 한번 보시고요. 지금 작업하시는 환경 정도면 그정도로 충분할 겁니다.

[/]

The good is the enemy of the best.

BL의 이미지

subversion 0.33 버전이 apr/apu 0.9.5 버전을 사용하면서 windows계열에서 생긴 디렉토리 문제는 해결된것 같습니다.

linux용 서버는 버클리디비를 리빌드해서 디렉토리를 지정해줘도 어딘가 꼬였는지 디비가 없어서 클라이언트만 만들수 있다고 나오는군요. :| 우선 windows local에서 좀 더 테스트 해보고 다시 서버를 설치해 봐야겠습니다.

simpid의 이미지

zelon wrote:
Quote:
VSS도 락을 걸어놓아도, 남이 수정할 수 있습니다.

VSS 에서도 그런 작업이 되었었나요?

처음 듣는 얘기네요. 제가 서버 설치부터 VC++ 6.0 ~ .NET 2003 까지 공동작업을 1년간 하면서 써봤는데 다른 사람이 CheckOut 했으면 그 사람이 체크아웃했으니 수정 못한다고 뜨던데요. 물론 거의 기본 세팅만 썼지만요. 혹시 옵션이 있다면 한수 부탁드립니다^^

저도 얼른 CVS 를 제대로 써봐서 효율성 많이 비교해보고 싶네요. 곧 간단한 문서하나 만들어보고 싶다는... 호홋

ps : kldp 에 처음 글써보는데 여러분들 너무 답변 잘 해주시네요. 감사~ ^^/

writable option으로 lock을 무시하고 편집할 수 있습니다.
물론 편집한 내용을 올릴때 골치아파지죠... ^^;

kimyj7의 이미지

Quote:
zelon 씀:
인용:
VSS도 락을 걸어놓아도, 남이 수정할 수 있습니다.

VSS 에서도 그런 작업이 되었었나요?

처음 듣는 얘기네요. 제가 서버 설치부터 VC++ 6.0 ~ .NET 2003 까지 공동작업을 1년간 하면서 써봤는데 다른 사람이 CheckOut 했으면 그 사람이 체크아웃했으니 수정 못한다고 뜨던데요. 물론 거의 기본 세팅만 썼지만요. 혹시 옵션이 있다면 한수 부탁드립니다^^

저도 얼른 CVS 를 제대로 써봐서 효율성 많이 비교해보고 싶네요. 곧 간단한 문서하나 만들어보고 싶다는... 호홋

ps : kldp 에 처음 글써보는데 여러분들 너무 답변 잘 해주시네요. 감사~ ^^/

writable option으로 lock을 무시하고 편집할 수 있습니다.
물론 편집한 내용을 올릴때 골치아파지죠...

SourceSafe Administrator에서 메뉴 Tools->Options에 가시면 첫 페이지에 Allow multiple checkouts를 하시면 여러명이 동시에 checkout을 할 수 있으며 checkin시 충돌날 경우에는 merge를 해주는 기능도 있습니다. VSS, CVS랑 둘다 써 봤는데 기능상으로는 많이 차이나지는 않는 것 같습니다. 초보자가 접근하기에는 VSS가 더 좋아보이구 기능은 CVS가 더 많아 보입니다.

익명 사용자의 이미지

국산툴 SoftManager 라는 제품이 있는데 무료 평가판 제공 하고,
깔기도 쉬우니 머~ 함 써보시는 것도 괜찮을 듯 합니다.
엔드유저 배포 관리도 된다고 하니. 패키지나, 웹개발 하시는 분은
좋을듯해요~~

익명 사용자의 이미지

vss는 주로 소규모 팀작업에서 락을 통한 덮어 쓰기 방지를 위해 씁니다. 약간의 히스토리 기능이 있긴하지만, 미미합니다.

cvs는 중,대규모 팀작업에서 진가를 발휘합니다. 락을 통한 덮어 쓰기 방지 목적이 아닌 버젼 관리를 위해 쓰지요.

이는 브랜치와 태그라는 CVS 고유 기능을 통해 VSS와의 차이가 나타납니다. 브랜치와 태그는 소규모 군소 그룹을 형성해 중심 줄기의 프로젝트를 함께 진행할 수 있도록 해줍니다.

그리고, 오류가 발생했을 때 vss는 cvs에 비교가 될 수 없습니다. vss는 파일이 암호화 되서 복구를 할 수 없지만 cvs는 파일명이 그대로 올라가기 때문에 복사만 하면 복구할 수 있습니다. 위기 관리 능력이 더욱 좋습니다.

그럼...

cinsk의 이미지

notexist wrote:
Rational ClearCase는 어떤가요?
회사에서 써서 암 생각없이 쓰고는 있는데...

Domain Server와 연동하여 쓰기 때문에, XP의 경우, CC(Clear Case) 서비스가 동작합니다. 아무리 인트라넷이라 하지만, 이 서비스 정말 느립니다. 덕분에 부팅 시간을 상당히 잡아 먹을 뿐만 아니라, 가끔 segfault도 일으킵니다.

또 CC의 경우, (한국 IBM에서 직접 설명) 소규모의 작업을 위한 것이기 때문에, 다량의 파일을 처리하는 부분이 다른 management system에 비해 현저히 떨어집니다. Linux 용도 있다고 하는데, 이 것으로 recursive하게 여러 파일을 import/add가 불가능합니다. script를 만들어 쓸 수 있다고 하는데, Linux kernel 다 import 시키는데 하루가 넘게 걸립니다. :evil:

그리고 특정 환경에서.. 시티 은행 인터넷 뱅킹 Active X와 충돌을 일으킵니다. 이 것 땜에 왜 안되는지 고생한 것을 생각하면... :?

물론 제가 색안경을 끼고 바라본다고 하실 지도 모르겠지만, 제가 결정할 수 있다면 CC는 절대 쓰지 않겠습니다.

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.