더 효율적인 버전 관리 방법은 무엇입니까? 체크 아웃 또는 병합?

Question

나는 항상 '병합'방법론을 사용하는 버전 제어를 위해 Subversion 또는 CVS를 사용했습니다.제 친구 중 한 명이 Perforce에 대해 열광하며 변경 목록과 체크 아웃 방법론이 얼마나 뛰어난 지 열광합니다.

많은 것이 경험과 개인적 선호도에 달려 있다고 확신하지만, 어떤 버전 제어 방법이 작업하기에 더 효율적인지에 대한 연구가 수행되었는지 궁금했습니다.

편집 : 명확히하기 위해 Perforce와 SVN 모두 잠금 및 병합을 허용하지만 SVN은 자유로운 편집 및 병합 방법을 '장려'하는 반면 Perforce는 체크 아웃 체크인을 권장합니다.방법.

Answer 1

솔직히 개발자의 규율에 달려 있다고 생각합니다.

저는 개인적인 작업에 Subversion을 사용하고 있으며 몇 가지 작업에 사용했습니다. Subversion에 대해 내가 좋아하는 점은 누군가를 사냥하고 왜 그들이 어떤 일을하고 있는지 그리고 내가 어떤 일을하는 것이 괜찮을지 물어볼 필요가 없다는 것입니다. 문제는 누군가가 작업을 시작하기로 결정하고 잠시 동안 확인하지 않을 때 발생합니다. 체크 아웃과 체크인 사이에 몇 가지 변경 사항이 발생하므로 병합이 어려울 수 있습니다.

저는 지금 Perforce를 사용하고 있으며 어떤 이유로 SVN을 더 좋아합니다. Perforce는 확실히 병합 충돌이있을 것이라는 더 나은 표시를 제공하며 병합을 해결하는 데 도움이되는 기본 제공 도구도 있습니다. 누군가가 오랜 시간에 걸쳐 많은 변경을하면 병합이 더 어려워지는 동일한 문제가 있습니다.

기본적으로 두 모델 모두 변경 사항을 자주 확인해야합니다. 체크인을 여러 번하면 병합이 필요할 가능성이 줄어 듭니다. 나는 너무 자주 물건을 체크 아웃하는 것에 죄책감을 느낍니다. 개인적으로 저는 SVN의 가격표가 Perforce에 비해 부족한 모든 것을 보완한다고 느낍니다. 아직 차이점을 찾지 못했습니다.

Answer 2

병합이 더 효율적입니다.동일한 파일을 동시에 변경하는 것이 일반적인 경향이있는 단순한 이유 때문에 병합을 사용하면 그로부터 복구 할 수 있습니다.대조적으로, 단일 체크 아웃은 약간의 추가 작업을 방지하지만 예약시 엄청난 비 효율성을 희생하면서 그렇게합니다.일반적으로 동일한 파일에 두 가지 변경 사항을 병합하는 데는 짧은 시간 (예 : 몇 분)이 걸리지 만 파일을 변경하는 데는 상당한 시간 (예 : 몇 시간 또는 며칠)이 걸리므로 파일 편집에 대한 액세스가 차단됩니다.엄청난 비효율입니다.

Perforce는 체크 아웃 방법을 강요하지 않고 동시 체크 아웃을 허용합니다 (병합과 동일).

Answer 3

마지막 평가에서 Perforce는 분기 간 변경 및 통합을 지원하는 Subversion을 능가했습니다.이 단점을 해결하기 위해 Subversion에서 작업이 진행 중이었지만 다시 확인하지 않았습니다.

Perforce에서 파일을 분기 할 때 Perforce는 파일의 출처와 두 버전으로 "통합"된 개정을 "기억"합니다.또한 저장소에 몇 가지 저장소 최적화 기능이 있으므로 누군가가 브랜치를 변경할 때까지 브랜치 복사본이 실제로 구체화되지 않고 (내가 올바르게 이해한다면) 기본 복사본에 대한 diff를 사용합니다.가지.

Perforce가 지점 간 관계를 추적하는 것은 엄청난 자산입니다.지금 Subversion이이 기능을 구현했다면 알려 주시기 바랍니다.

Answer 4

Perforce가 아닌 Source Safe를 의미 하셨나요?Perforce는 병합을 지원하고 실제로 명명 된 병합이 추가 된 SVN 1.5까지 SVN보다 더 나은 병합 지원을 제공했습니다 (Perforce가 항상 가지고있는 변경 목록도 포함되어 있고 SVN을 사용하는 상점으로 이동하는 것이 매우 잘못되었지만 우리는 그렇게 할 것입니다.t 1.5까지 업그레이드하는 데 시간이 좀 더 걸립니다.)

SVN과 Perforce 모두 잠금 체크 아웃을 수행 할 수 있으므로 원하는 경우 "병합되지 않은"모델을 수행 할 수 있지만 버전 제어로 바이너리를 관리하는 것 외에는 많이 사용하지 않습니다.이.

어쨌든 귀하의 질문에 대한 간단한 대답은 "두 명 이상의 개발자가 참여할 때마다 모델 병합이 훨씬 낫습니다."입니다.

Answer 5

내가 올바르게 이해하면 Perforce는 체크 아웃되지 않은 모든 파일을 읽기 전용으로 만듭니다.이는 Microsoft TFS 및 VSS에서의 동작과 유사합니다.반면에 Subversion은 읽기 전용 속성을 설정하지 않습니다.IMO, Subversion 방법은 파일을 수정하기 위해 소스 제어 클라이언트에 신경 쓸 필요가 없기 때문에 더 쉽습니다. 무모한 포기로 수정 한 다음 준비가되면 디스크에서 변경된 사항을 서버와 비교합니다.체크인합니다.

모든 파일이 읽기 전용 일 때, 저는 계속해서 파일을 변경하고 저장을 시도하며 읽기 전용임을 발견 한 다음 소스 제어 클라이언트로 이동하여 체크 아웃해야합니다.소스 제어 클라이언트가 편집기에 통합되어 있어도 나쁘지는 않지만 버전 제어하에 소스 코드가 아닌 것을 저장하는 경우에는 종종 옵션이 아닙니다.

Answer 6

<인용구>

내가 올바르게 이해하면 Perforce는 체크 아웃되지 않은 모든 파일을 읽기 전용으로 만듭니다.

이것은 기본 동작 일뿐입니다.필요한 경우 자주 변경되는 파일을 대신 읽기-쓰기로 설정할 수 있습니다.파일 수정 자 전체 목록은 여기 에서 확인하세요.

또한 내 환경에서는 Perforce 플러그인 .이 플러그인으로 파일을 편집하면 편집 할 파일이 즉시 열립니다.

Answer 7

연구 내용은 확실하지 않지만 다음과 같은 데이터 포인트가 있습니다.
저희 팀은 대부분 편안함 때문에 PVCS (체크 아웃)를 선택했습니다.병합에 대한 의심과 Subversion과 같은 도구에 대한 인식 부족이 분명히 그 원인이되었습니다.

Answer 8

여기에있는 질문을 이해하지 못합니다. 병합을 완전히 지원하지 않는 최신 소스 제어 시스템 (Visual SourceSafe 제외)을 알지 못합니다.

Answer 9

확실히 병합 방법을 선호합니다.

저는 Visual Sourcesafe (다시는 안되길 바랍니다), CVS, Subversion 및 bzr을 사용했습니다.Visual sourcesafe는 "편집 전 체크 아웃"방법론을 적용하므로 고통 스러울 수 있습니다.CVS와 Subversion은 역사적으로 병합을 잘 받아들이지 못했지만, Subversion 1.5가 개선되었다고 들었습니다.

처음부터 잦은 병합을 염두에두고 설계된 VCS를 사용하는 것이 좋습니다.bzr은 제가이 작업을 수행하는 데 사용한 적이 있지만 다른 주요 분산 vcs 시스템 (git 및 mercurial)도 수행합니다.

하지만 궁극적으로이 특정 분야에 대한 연구 결과는 없습니다.일반적으로 프로그래밍 효율성에 대한 연구는 거의 없습니다. Peopleware 는주목할만한 예외.

Answer 10

솔직히 질문을 잘 모르겠습니다. 하지만 저는 Perforce의 효율성과 여러 사람이 파일을 비동기 적으로 수정하고 편집 내용을 병합하는 것을 처리하는 능력을 보증 할 수 있습니다.

Perforce에서 누군가가 수정중인 파일을 체크인하면 다음에 서버에서 동기화 (즉, 최신 파일 가져 오기) 할 때 해결해야 할 변경 사항이 있다는 알림을받습니다. 이 작업을 수행 할시기에 대한 선택은 귀하에게 달려 있습니다. 파일을 "해결"하면 로컬 버전으로 병합되며 도구가 이에 적합합니다.

언제 할 것인지 선택하는 것이 중요합니다. 동기화 중일 수 있으므로 작업과 직접 관련이없는 일부 업데이트 (예 : 버그 수정)를받을 수 있으며이 단계에서는 작업을 처리하고 싶지 않습니다. 작업중인 동일한 파일을 다른 사람이 변경하면 영향을받을 수 있습니다. 따라서 계속해서 빌드 및 테스트를 수행 한 다음 자신의 시간에 파일을 해결합니다.

다른 경우는 업데이트 된 파일에 먼저 동기화하지 않고 수정 사항을 제출하는 경우입니다. 이 경우 Perforce는 제출을 방지하고 해결할 파일에 플래그를 지정합니다. 이 단계의 현명한 개발자는 병합을 수행 한 다음 변경 사항을 Perforce에 다시 제출하기 전에 다시 컴파일 및 / 또는 테스트합니다.

내가 좋아하는 점은 명시 적으로 처리되지 않은 변경 사항을 중앙 서버에 다시 제출하는 것을 막기 위해 정말 열심히 노력하여 빌드가 중단 될 가능성을 최소화한다는 것입니다. 해결 프로세스는 쉽고 오버 헤드가 매우 적기 때문에 효율성 문제가 전혀 없습니다.

Perforce는 변경 사항 전파 방법에 대한 선택과 제어를 제공하는 데 매우 명시 적이며 편집 병합을 관리하는 훌륭한 도구로이를 백업합니다. 개인적으로 나는 선택과 선택을 쉽게 할 수있는 힘을 좋아합니다. Doubtless Subversion에는 자체 대안도 있습니다.

아마 익숙한 것에 따라 결정될 것 같습니다. 중요하거나 측정 가능한 효율성 문제는 없다고 생각합니다.