가장 좋아하는 버전 관리 시스템은 무엇입니까? [닫은]

이것은 조직의 요구에 따라 명확하게 변하기 때문에 "최고"를 결정하려는 실제 시도보다 더 많은 토론 문제입니다. 카테고리별로 다른 시스템 (중앙 집중식, 분산 형, 개방형, 독점 형 등)을 선호하는 주장에 대해 더 궁금합니다.

그렇다면 최고의 버전 관리 시스템은 무엇이라고 생각하십니까?

수은제

코드를 분기하고 병합하는 정교한 기능 때문에 내가 사용한 것 중 최고입니다. 전체 DVCS 패러다임은 그다지 의미가 있습니다. 나는 Git을 사용하지 않았지만 자격이 있다고 가정합니다.

힘내

Git은 환상적이며 특히 오픈 소스 프로젝트를 수행하는 모든 사람에게 권장합니다 .Git의 프로젝트에 작은 일회성 변경 사항을 제공하는 것이 특히 GitHub에서 호스팅하는 경우 e- SVN과 관련한 메일 링 패치.

Windows 사용자를위한 하나의 큰 경고 : Git의 Windows 도구는 확실히 사용 가능하지만 처음부터 다루지는 않습니다. 잠시 동안 Windows를 사용해야했을 때 Hg-Git 통합 도구를 사용하여 Mercurial의 Windows 인터페이스를 사용해 보았으므로 Git 리포지토리를 사용할 수있어 훨씬 사용하기 쉬웠습니다.

경고 :이 게시물 이후 나는 Mercurial을 발견했으며 SVN보다 훨씬 더 좋아했습니다. 따라서이 게시물은 Pro SVN 의견과 일반 anti-DVCS와 약간 오래된 내용이지만 git anti-stuff는 여전히 관련이 있습니다.

저는 Git 의 SVN 팬입니다 .

왜? SVN이 단일 개발자 또는 소규모 팀에게는 훨씬 쉬웠 기 때문에 git (특히 msysgit)은 입안에 나쁜 맛을 남겼습니다.

작은 상점에서 인턴을 할 때 Windows에서 git을 소개했습니다. 즉시 Github에서 작업하는 데 소요되는 작업량을 확인했습니다. 먼저 ssh 개인 키를 생성하고 Github에 공개 키를 붙여 넣은 다음 푸시 할 때마다 미인 대회를 불러오고 내 개인 키를 열어야했습니다. 매우 성가신 일이었습니다.

그리고 나는 전체 저장소를 풀고 있다는 것을 정말로 좋아하지 않았습니다. 거대한 작업을 한 적이 없다는 것을 인정하지만 전체 리포지토리와 수정본이 HD에 있으면 Git에 KDE의 저장소를 다운로드하는 것이 두렵습니다.

그런 다음 커밋하는 혼란스러운 프로세스가있었습니다. TMK, 나는 커밋하고자하는 모든 파일을 먼저 "스테이징"해야했습니다 (많은 파일이있을 때 빨려 들었고 모든 것을 스테이징하는 수동 명령을 찾는 데 시간이 걸렸습니다). repo (왜 별도의 작업입니까?!).

not (!) 매우 유용한 커밋 데이터도 있습니다. 이봐, 이것은 커미트 2167a4934d0a4a7db0de와 부모 d7042abb4821d3faf600의 14f74433245ae17aeeaa 부분이다. 대체 그게 무슨 뜻이야? 나는 물건을 꽤 빨리 알아낼 수 있어야하며 이상한 문서를 참고할 필요가 없습니다.

적어도 문서를 사용했을 때 문서에 대해 말하면 모든 것이 Linux man 파일 형식, IE가 혼란스럽고 쓸모없는 것처럼 보였습니다. 나는 문서에서 많은 도움을 얻지 못하고 단순히 Google에 의지했습니다.

그리고 커밋으로, 내가 싫어하는 한 가지 버전 번호가 부족했습니다. 이제 이것이 git 디자인 때문이라는 것을 알고 있지만 모든 소프트웨어에는 버전 번호가 필요합니다. 여전히 "Changed version to 1.8.6"또는 이와 유사한 것으로 표시되는 마커 커밋을 기억하지만 여전히 빌드 번호를 만들 수 없었습니다. 버전이 1.8.6.5164 (마지막 부분은 개정 번호) 인 경우 나에게 단순히 1.8.6 이상을 알려주고 사소한 것이 바뀌 었다는 메모가 있습니다.

소프트웨어의 특정 Windows 기반 프로그램은 msysgit이며, 이는 끔찍한 인터페이스입니다. 그것은 나에게 몇 번 잠겨 있었고 끔찍한 인터페이스를 가지고 있었고 CLI-GUI 통합은 기뻤습니다. 내 주변의 명령 행 중독자들은 GUI를 훨씬 더 싫어했다.

이제 SVN을 살펴 보겠습니다. 그리고 Windows에 있고 Google 계정, 특히 TortoiseSVN 및 Google Code가 있습니다.

먼저, 셸 통합을 완료하여 리포지토리의 모든 작업을 수행합니다 (리눅스 사용자의 경우 RabbitVCS는 동일한 작업을 수행함). 기본 GUI는 필요하지 않습니다. 리포지토리를 얻는 것은 체크 아웃, SSH가 필요하지 않고 (Github가 풀에 SSH를 필요로했는지 기억할 수 없음), HD에 앉아있는 모든 이전 커밋 + 전체 저장소가 없습니다.

SSH 또는 스테이징이 필요하지 않기 때문에 커밋은 매우 쉽습니다. msysgit 버전에서 사용할 수 없었던 매우 유용한 모든 선택 옵션을 사용하여 원하는 모든 파일을 확인하고 커밋 메시지를 입력 한 다음 커밋을 누르기 만하면됩니다. 그런 다음 Google 코드에서 로그인 정보 (대부분의 고객이 저장) 및 완료 정보를 묻습니다. 간단하고 쉽고 SSH가 없습니다.

버전 번호? 쉬운 코드를 사용하면 모든 체크 아웃에 버전 번호와 커밋 번호를 추가 할 수있어 훨씬 쉬워집니다. 또한 실제로 변경 사항을 표시하는 사용 가능한 버전 번호가 표시됩니다 (예 : 1.8.6.5165가 1.8.6.5164보다 최신 버전 임).

문서? 글쎄, 말하기 어렵다. 거북이는 문서화되었지만 실제로 판단 할 수없는 공식 문서를 오랫동안 언급하지 않았습니다. 간단한 소개 안내서를 읽는 것으로 충분했습니다.

병합은 내가 비교할 수없는 다른 것입니다. 다른 누군가가 내가 작업중 인 파일을 변경했지만 SVN에서는 결코 변경하지 않았을 때 Git에서 한 번 수행해야했습니다.

어느 것을 추천 하시겠습니까? 큰 팀에서 git은 주로 비선형 개발주기에서 장점을 가지고 있습니다. 다른 프로젝트에서 4 명의 프로그래머가 별도의 지점에서 시작한 다음 모든 코드를 매우 이상한 방식으로 병합하여 최종 마스터 지점으로 변형했습니다. Github와 msysgit은 내가 좋아했던 전체 프로젝트를위한 멋진 시각화 도구를 가지고있었습니다.

단일 개발자 또는 소규모 팀 프로젝트의 경우 대부분의 Gits 기능이 사용되지 않고 부정적인 부분 만 가져 오기 때문에 SVN이 가장 좋습니다. 단순함은 좋은 것입니다

Q4TD 의 다음 인용문은 저에게 거의 요약되어 있습니다.

“내가 시도 할 때까지 Git을 좋아했다. 이제 나는 Mercurial을 좋아합니다.”

        — 토르 노비, 자바 팟 캐스트

또한 hgsubversion 은 Linux에서 꽤 좋은 Subversion 클라이언트를 만듭니다 (일반적으로 TortoiseSVN을 사용하는 Windows와 달리 일반적으로 명령 줄을 사용합니다). 가장 큰 장점 .svn은 모든 폴더에 하위 폴더가 없고 .hg최상위 수준 일뿐 입니다.

업데이트 : Alex의 요청에서 "git이 왜 작동하지 않는지, Mercurial이 어떻게 더 잘 작동했는지에 대한 자세한 내용"에 대한 의견에 따라 :

나는 Git 이 나를 위해 작동 하지 않는다고 말하지는 않지만 Murcurial은 더 나은 IMO를 사용합니다.

간단히 말해서, 이것은 Mercurial입니다.

그리고 이것은 힘내입니다 :

그리고 Mercurial은 일상적인 작업을 수행하는 방법을 알아 내기 위해 매뉴얼을 찾을 필요없이 대부분의 개발자가 필요로하는 모든 것을 할 것이라고 주장합니다.

분명히, 나는 가끔 Git을 사용했지만 프로그래밍 커뮤니티는 루비와 파이썬과 같은 언어를 간결하고 우아하게 사용하고 있지만 Git은 낙타위원회가 디자인 한 낙타처럼 느낍니다.

바, 이제 네가 한 짓을 봐? 모든 곳에서 소리가 난다. 따라가, 볼 것도없고 ... 볼 것도 없다 ...

업데이트 2 : 그리고 방금 또 다른 제안 트윗 이 나타났습니다.

"분지가 힐버트 공간의 하위 매니 폴드를 매핑하는 동종 이형 endofunctors라는 기본 아이디어를 얻으면 Git이 더 쉬워집니다."

하나의 "최고의"버전 제어 시스템이 아니라 하나의 최고의 VCS 패러다임이 있습니다.

여러 개의 다른 중앙 집중식 버전 제어 시스템과 여러 개의 다른 분산 버전 제어 시스템을 사용했습니다. 그리고 누구도 CVCS를 스스로에게 가해서는 안된다는 것을 망설이지 않고 말할 수 있습니다.

어떤 DVCS를 선택하든 상관 없지만 (내가 가장 좋아하는 것은 Git입니다.) DVCS를 사용하십시오. 하나 : 당신은 훨씬 더 유연합니다. DVCS는 CVCS 워크 플로우를 간단하게 에뮬레이트 할 수 있습니다 (저장소를 포크하지 않고 로컬 저장소를 독립 포크 대신 차체로만 처리). 그러나 대화는 불가능합니다. 그리고 논리적으로 동안이 에뮬레이션을하는 것은 해야 약간의 오버 헤드를 가지고 (실제로는 않습니다), 나는 여전히 쉽게 사용에 내가 사용한 CVCSs들보다 (훨씬 더 확대됨으로 인해 로컬 캐싱을 언급하지 않기 위하여) 찾을 수 있습니다.

최고의 버전 제어 소프트웨어를 만났다고 말할 수는 없지만 VSS 및 MKS에서 멀리 떨어져 있다고 말할 수는 있습니다. 둘 다 모든 비용을 피해야하는 개입니다.

나는 최고라고 말하지는 않지만 매우 흥미로운 기능과 개념을 가진 것을 말합니다.

Fossil 은 SQLite 데이터베이스를 기반으로 구축 된 분산 버전 제어, 버그 추적 및 위키 프로젝트입니다.

팀 파운데이션 서버

때문에:

1. 그것은이다 좋은, 고체 VCS . (어쨌든 최선이라고 생각하지는 않지만 멋진 추가 기능이 있습니다.)
2. Visual Studio에 통합 된 기본 제공 작업 및 버그 추적 기능을 통해 한곳에서 모든 작업을 처리하고 버그를 파악할 수 있습니다. 다른 시스템 / 이클립스 등을위한 플러그인을 얻으십시오.)
3. 작업 / 버그 추적 / 프로젝트를 Project Server에 직접 통합하므로 프로젝트 계획이나 작업 표를 최신 상태로 유지할 필요가 거의 없습니다. Project Server에서 프로젝트를 업데이트하면 자동으로 볼 수 있도록 TFS 및 Visual Studio의 작업으로 자동 필터링됩니다.

오랜 역사에서 수많은 버전 제어 시스템을 사용했습니다.

• RPPT-(펀칭 된 종이 테이프 롤). 신발 상자에. 농담이 아냐.
• PVCS-(Polytron 버전 제어 시스템). 내가 사용한 최초의 실제 VCS.
• SCCS-너무 오래 전에, 나는 그것에 대해 예외적으로 좋은 점이나 나쁜 점을 기억하지 못합니다.
• RCS-다른 사람들이 지적했듯이 오히려 땀이 나는 당나귀 공을 빨아들입니다.
• CVS-2 명 이상의 프로그래머와 함께 사용하면 고통 스러웠습니다. 최고의 기능 : rcs2cvs.
• VSS-전체 저장소를 손상시키는 화요일을 제외하고 작동합니다.
• 퍼 포스-내 차보다 더 비싸다. VCS 자체는 수용 가능하지만 VCS를 사용하는 모든 측면을 제어하는 ​​IT 전문가는 "선호"목록에 포함시키지 않습니다.
• SVN-분기 및 병합은 나쁜 일이지만 일반적으로 이전의 것보다 낫습니다. 검토를 기다리는 작은 변경 사항이 많으면 좋지 않습니다.
• Mercurial-내가 경험 한 경험이별로 없습니다. 다음 프로젝트에서 시도해 볼 수 있습니다.
• 힘내-그것을 사용할 기회가 없었습니다.

부부는 공포 였지만 대부분은 "괜찮 았습니다". 그들은 내 길에 오지 않았다. 도구 가 내 인생을 훨씬 더 어렵게 만들지 않는 한 , 나는 정말로 신경 쓰지 않습니다.

실제로는 각각의 장단점을 이해해야합니다. 대상 환경을 이해하십시오.

• 분산 또는 로컬
• 소규모 팀 또는 대규모
• 호스팅 된 vc 서비스
• 다른 도구에 쉽게 통합

Joel은 또한 중요한 관찰 결과를 얻었습니다. 도구와 실제 사용 모델을 배우십시오. 그는 머큐리얼을 서브 버전처럼 행동 시키려고 힘썼다.

사무실에서 사용하는 최신 시스템 중 하나는 Plastic SCM (http://www.plasticscm.com/)입니다. 소규모 팀에 매우 효과적이며 소스 관리의 모든 측면을 완벽하게 제어 할 수 있습니다.

SCCS .

또는 지난 38 년 동안 동굴에 살지 않았다면 CSSC .

실제로 우리 회사는 SCCS를 기반으로하는 의사 DVCS 인 TeamWare를 사용 하고 있습니다.

아니, 농담이 아니야

썬은 불과 몇 년 전에 TeamWare에서 수은으로 전환했습니다. 이제 왜 Java가 그렇게 느리게 움직이는 것처럼 보 였는지 이해해야합니다.

MPW : 글쎄, 나는 내 노력에도 불구하고 실제로 그것을 검토 할 수 없습니다.

이것은 고등학교에서 프로그래밍을 배우던 시절로 돌아 왔으며, 실제로 무료로 제공되는 유일한 C ++ 컴파일러는 Macintosh Programming Workbench였습니다. Zip 디스크에 보관하고 실험실에서 Performa를 사용할 수있는 어느 곳에서나 나타났습니다.

MPW에는 수십 가지 도구 (둘 중 하나는 재 편집, 별도 다운로드)가 제공되었으며 그 중 하나는 버전 제어 유틸리티였습니다. 한 줄의 텍스트로 작은 창을 열었으므로 프로젝트 또는 파일을 끌어서 놓아야했습니다. 그것은 내가 발견 할 수있는 문서가 없었으며, 다른 모든 것이 훌륭한 문서를 가지고 있다고 생각하면 예외적이므로 사용 방법을 찾지 못했습니다.

그것은 VC를 사용한 첫 번째 브러시였으며 마지막으로 좋은 브러시였습니다. 이제 모든 것에 git을 사용합니다.

RCS-개정 관리 시스템

솔로 코딩이 매우 쉬워졌습니다.

적어도 Unix / Linux 시스템에서는 ClearCase가 아닙니다 (아마도 Windows의 경우 설치 프로그램이 더 쉽습니다). ClearCase 서버를 업그레이드하는 대신 Perforce라는 새로운 도구를 배우는 것이 더 쉬웠습니다.

나는 현재 직장에서 퍼 포스를 사용하고 그것을 좋아하지만 그것이 최고인지 전혀 모른다. 명령 행 환경 및 Perforce Server 설정은 약간 어색하지만 Visual Client를 사용하는 것은 매우 쉽습니다. 나는 사용자가 일상적인 작업에 대해 꽤 쉬운 시간을 가지고 있다고 생각합니다. 초기 설정은 약간의 작업이 필요합니다.

나는 Visual SourceSafe를 사용하고 그것을 미워했지만 아무것도하지 않는 것이 낫지 만 많지는 않았습니다. 지난 몇 년 동안 Qumasoft.com의 QCVS라는 이름을 사용하여 프로그래머 인 Jim Voris가 작성, 소유 및 지원했습니다. 간단한 GUI, 저렴한 가격, 좋은 지원.

그냥 일을 해요.