각 파일을 개별적으로 버전 화하는 버전 제어 시스템의 장점은 무엇입니까?

15

지난 몇 년 동안 나는 여러 가지 다른 버전 관리 시스템으로 작업했습니다. 저에게있어 그들 사이의 근본적인 차이점 중 하나는 파일 버전을 개별적으로 (각 파일마다 고유 한 버전 번호 및 기록이 있음) 저장소 전체인지 ( "커밋"또는 버전이 전체 저장소의 스냅 샷을 나타냅니다) .

일부 "파일 별"버전 제어 시스템 :

CVS
클리어 케이스
비주얼 소스 세이프

일부 "전체 리포지토리"버전 제어 시스템 :

SVN
힘내
수은제

필자의 경험에 따르면 파일 별 버전 제어 시스템은 문제를 야기 할뿐 아니라 올바르게 사용하려면 훨씬 더 많은 구성 및 유지 관리가 필요합니다 (예 : ClearCase의 "config specs"). 관련없는 파일을 변경하고 이상적으로 고립 된 개발 라인이되는 것을 깨는 동료의 사례가 많이있었습니다.

이러한 파일 별 버전 제어 시스템 의 장점 은 무엇입니까 ? "전체 리포지토리"버전 제어 시스템의 파일 별 버전 제어 시스템에는 어떤 문제가 있습니까?

version-control

— 마이크 다니엘스
소스

3

나는 주로 역사적으로 그랬고 지금은 파일 지향에서 변경 세트 지향 시스템으로 옮겨 가고 있지만 오늘날의 관점에서 사람들이 왜 파일 당 접근법을 시도했는지 이해하기가 어렵습니다. 훌륭한 질문입니다!

— blubb

이 질문이 논쟁의 여지가 있다면 사과합니다. 최근 좌절의 결과물입니다.

— Mike Daniels

1

@ Mike Daniels : 분명히 장점을 요구할 때 (적어도 나에게는) 그렇지 않습니다.

— blubb

이 두 관점은 다른 규칙입니다. 다른 쪽보다 찬성하는 주장은 상대방의 정당으로부터 반론을 제기 할뿐입니다. 예를 들어 Clearcase에서 "전체 응답"동작을 원하는 경우 날짜별로 구성 스펙을 사용자 정의 할 수 있습니다.

— mouviciel

SVN에는 파일 당 버전이 있거나 마지막 버전에서도 변경 되었습니까?

— Klaim

12

내 경험상, "전체 저장소"VCS는 "파일 당"VCS를 엄격하게 지배합니다.

— 레인 헨리 치
소스

3

파일 당 동일한 저장소에서 제품 라인 (여러 소프트웨어 제품)을 빌드 할 때 이점이 있습니다.

일부 고객 계약 환경에서는 코드 삭제에만 원하는 변경 사항이 있으며 다른 변경 사항은 없다는 증거가 필요합니다. 파일 버전 번호가 모두 동일하면 매우 쉽습니다.

그리고 이것은 내가 얇은 공기에서 뽑은 임의의 예가 아닙니다.

지난번에 고용주로부터 대량 구매 한 시스템에 대해 소프트웨어 업데이트를 미군에 배송 할 때 마지막으로 일어났습니다. 계약의 달러 가치는 약 십억 달러로 측정되었습니다 (미국 달러가 훨씬 더 가치가 있었을 때)

그래서 그것은 때때로 도움이됩니다.

이상하게도 : 내가 지금 일하는 곳에서는 각 고객에게 다른 결과물을 배송합니다 ....

나는 그것이 수축 랩 또는 웹 앱보다 방위 / 항공 우주 공간에서 훨씬 더 일반적이라고 생각합니다.

— 팀 윌리스 크로프트
소스

3

그러나 전체 파일 저장소의 분기도 동일한 요구를 충족시킵니다. 예를 들어, bzr에서 브랜치는 병합 (또는 리포지토리 공유)까지 메인 라인과 완전히 독립적입니다.

— edA-qa mort-ora-y

1

'전체 리포지토리'시스템의 분기가 "파일 별"VCS에서 사용할 파일을 결정하기 위해 VCS 외부의 상태에 의존하는 것보다 필요한 상태를 더 잘 표현하지 못하는 단일 상황을 생각할 수 없습니다. uni 이후의 첫 번째 작업은 RCS, 프로젝트를 버전 화하는 스크립트, 버전 스크립트를 버전 화하는 최상위 스크립트, 절대 악몽, 그리고 군사 프로젝트에도 사용되었습니다. * 8 ')

— Mark Booth

@Mark Booth는 고객 이 원하는 수정 사항에 따라 변경된 파일을 알고있었습니다. 물리적 구성 감사는 버전 관리 번호를 기준으로합니다

— Tim Williscroft

내가 말하는 것은 버전 + 감사 패치 는 다른 장소, VCS 및 감사원에 다른 정보가 필요하다는 것 입니다. '전체 리포지토리'시스템에 지점이 있으면이 두 상태가 별도의 엔터티로 기록됩니다. 이제 VCS와 감사 시스템간에 동일한 정보가 복제되며 항상 일치해야합니다. git패치를 만든 사람 (작성자)과 감사 한 사람 (커미터)을 모두 알고있는 '감사 된'리포지토리를 유지할 수 있습니다. 우리에게 모범적 인 상황을 알려 주시면 -1을 바꾸겠습니다.

— Mark Booth

@ 마크 부스 어떤 패치? 그들은 그들의 소프트웨어가 파일 세트 A 1.01 B 1.05 D 1.55 E 1.44 F 1.01이라는 것을 알고 있었으며 그들이 수용 한 버전의 SVD는 파일 별 변경 정보를 가지고있었습니다. E는 결함 1104, 이전 버전 1.43, 새로운 버전 1.44를 수정하기 위해 변경되었습니다. . F를 1.01 버전에서 변경 한 경우 하늘이 도와줍니다. 실제 버그가 수정되어 변경을 원하지 않았기 때문에 상황이 더 복잡해졌습니다. 이 사람들은 최소한의 변경 세트를 원하여 1 년간의 개발에서 체리 피킹 된 일부 기능 만 선택했습니다. 사후 버그 수정 선택.

— Tim Williscroft 2016 년

3

파일 별 버전 관리에 이점이 없습니다.

단점 다른 한편으로는, 풍부하고 매니페스트입니다.

— 윌리엄 페인
소스

0

"파일 별"버전 제어 시스템에는 VCS 구현 이외의 확실한 이점이 없다고 말할 수 있습니다. VCS의 코더는 "파일 별"버전 관리 일 때 기꺼이 코딩합니다. 나는 그것이 역사적으로 등장했다는 점에 동의합니다.

— 아빈 드 친 니아
소스

0

관련 파일이있을 때 파일 별 접근 방식에는 이점이 없습니다. 개발 환경에서 가장 일반적인 경우는 다음과 같습니다.

몇 가지 특이한 경우-/ etc 또는. 유닉스의 홈 디렉토리에있는 파일은 내가 가지고있는 유일한 파일입니다-당신은 (대부분) 관련없는 파일을 처리하고 있습니다. 그리고 관련없는 변경 사항을 동기화해야하는 시스템을 갖추는 것은 성가신 일이 될 수 있습니다.

— 프로그래머
소스