체크 아웃 및 잠금 대 업데이트 및 병합 버전 제어 논쟁을 해결하십시오.

Question

나는 몇 년 동안 소스 제어를 사용해 왔지만(소스 안전 기간을 계산하는 경우) 결코 전문가는 아닙니다.현재 우리는 Sourcegear Vault의 이전 버전을 사용하고 있습니다.우리 팀은 현재 체크아웃 및 잠금 모델을 사용합니다.차라리 업데이트 및 병합 모델로 전환하고 싶지만 다른 개발자를 설득해야 합니다.

(제가 아닌) 개발자가 체크아웃 및 잠금 기능을 설정한 이유는 배신 파일 때문이었습니다.우리 회사는 컨설팅 회사와 협력하여 개발 작업의 대부분을 수행합니다.몇 년 전, 제가 여기 오기 훨씬 전에 그들은 업데이트 및 병합을 위한 소스 제어를 설정했습니다.컨설턴트가 체크인하러 갔으나 병합 오류가 발생했습니다.그런 다음 연결이 끊긴 모드에서 작업하기로 결정했습니다. ~을 위한 개월.마침내 프로젝트를 테스트할 시간이 되었을 때 수많은 버그가 나타났고 코드 베이스가 극적으로 다르다는 사실이 발견되었습니다.몇 주간의 작업을 다시 수행해야 했습니다.그래서 그들은 해결책으로 확인하고 잠그러갔습니다.

나는 체크아웃과 잠금을 좋아하지 않습니다. 왜냐하면 2명 이상의 사람이 동시에 같은 프로젝트에서 작업하는 것이 매우 어렵기 때문입니다.모든 유형의 새 파일을 추가하거나 파일 이름을 변경할 때마다 소스 제어는 .csproj 파일을 체크아웃합니다.이는 다른 개발자가 파일을 추가하거나 이름을 바꾸는 것을 방지합니다.

나는 단지 .csproj 파일을 병합할 수 있지만 Sourcegear 사이트에서는 csproj가 IDE 자동 생성이고 두 개의 다른 VS 생성 파일이 동일한 코드를 생성한다고 보장할 수 없기 때문에 이것이 나쁜 생각이라고 말합니다.

내 친구(다른 개발자)는 프로젝트를 즉시 체크인하는 것이 해결책이라고 말했습니다.나에게 있어 문제는 빌드되지 않는 로컬 복사본이 있을 수 있고 빌드를 얻는 데 시간이 걸릴 수 있다는 것입니다.빌드가 작동하려면 몇 시간이 걸릴 수 있습니다. 즉, 그 시간 동안 다른 사람은 파일을 만들고 이름을 바꿀 수 없습니다.

저는 병합 가능한 모델로 전환하는 것이 올바른 해결책이라고 반박합니다."배신자 파일" 문제에 대한 나의 대답은 그것이 열악한 프로그래머 규율의 문제였으며 열악한 규율에 대한 해결책으로 약한 프로그래머 선택을 사용해서는 안된다는 것입니다.대신 프로그래머 규율의 부족을 해결하기 위한 조치를 취해야 합니다.

그럼 누가 맞나요?체크인 - 레니게이드 파일 문제에 대한 합법적인 답변을 확인하시겠습니까?아니면 .csproj 여러 개발자에게 너무 큰 번거로움을 안겨주나요?아니면 Sourcegear가 잘못되었으며 csproj 업데이트하고 병합할 파일을 선택하시겠습니까?

Answer 1

업데이트 및 합병에 대한 문제는 의사 소통의 부족 그룹과 컨설팅 그룹 사이, 그리고 컨설팅 그룹에서 그룹으로의 의사 소통 부족이 문제가 무엇인지에 대한 문제에 대해 반드시 버전 제어 방법 자체에 문제가되지는 않습니다. 이상적으로는 커뮤니케이션 문제를 먼저 해결해야합니다.

두 버전 제어 방법론의 차이점에 대한 기술적 분석은 건전하다고 생각하며 업데이트/병합이 더 좋다는 데 동의합니다. 그러나 실제 문제는 그룹의 사람들과의 의사 소통에 있다고 생각하며, 버전 제어의 사용에서 그것이 어떻게 명백 해지고, 그룹의 사람들이 버전 제어 프로세스와 함께 온 배상/편안한 지 여부 '라고 생각합니다. 선택된 VE. 내가 말한 것처럼, 직장에서 내 자신의 그룹은 VC 대신 민첩한/스크럼만으로 똑같은 일을 통해 어려움을 겪고 있습니다. 그것은 고통스럽고, 성가시고, 실망 스럽지만, 트릭은 근본 문제를 식별하고 고치는 것입니다.

여기서 솔루션은 (VC 방법이 무엇이든) 모든 사람에게 잘 전달되는지 확인하는데, 이것이 복잡한 부분입니다. 특정 VC 기술뿐만 아니라 컨설팅 팀도 타야합니다. . 컨설팅 팀의 누군가가 합병 작업을 수행하는 방법을 확신하지 못하면 교육을 받으십시오. 핵심은 문제가 나타날 때 문제를 해결할 수 있도록 의사 소통을 개방하고 명확하게 유지하는 것입니다.

Answer 2

1. 적절한 소스 제어 시스템 (SVN, Mercurial, Git, ...)을 사용하십시오.
2. 분기를 많이하려는 경우 SVN 1.6보다 최근 덜 사용하지 마십시오. 나는 Mercurial/Git이 더 나은 솔루션이 될 것이라고 생각하지만, 아직 그것들을 사용하는 실습 경험이 너무 많지 않습니다.
3. 사람들이 끊임없이 시스템의 동일한 부분에서 작업하고 있다면 시스템 설계를 고려하십시오. 각 장치에 너무 많은 책임이 있음을 나타냅니다.
4. 결코 하루 종일 사람들을 오프라인으로 받아들이지 마십시오. 이 규칙에 대한 예외는 극히 드물어야합니다.
5. 서로 대화. 다른 개발자들에게 당신이 무엇을하고 있는지 알려주십시오.

개인적으로 나는 저장소에 프로젝트 파일이없는 것을 피할 것입니다. 그러나 다시 한 번, 나는 결코 개발자를 하나의 도구에 잠그지 않을 것입니다. 대신 나는 프로젝트 파일/makefiles/uthing을 생성하는 빌드 시스템을 사용합니다 (cmake는 이것을 수행하기위한 나의 맛입니다).

편집 : 파일 잠금이 질병이 아니라 증상을 고정하고 있다고 생각합니다. 이것이 습관이되면 개발자가 아무것도하지 않게 할 것입니다.

Answer 3

업데이트 및 머지 모델을 사용하여 40 명 이상의 개발자 팀과 함께 성공적인 프로젝트를 수행했습니다. 이 방법을 작동시키는 것은 자주 합쳐진 것입니다. 독립 근로자는 저장소에서 지속적으로 업데이트 (병합) 변경을하고 있으며 모든 사람이 자주 변경 사항을 통합하여 (기본 테스트를 통과하자마자) 자주 변경됩니다.

병합은 종종 각 병합이 작다는 것을 의미하는 경향이있어 많은 도움이됩니다. 개별 코드베이스와 저장소에서 야간 체크 아웃 모두에서 자주 테스트하는 것이 큰 도움이됩니다.

Answer 4

우리는 고도의 병렬 환경에서 모든 파일에 대해 체크인/체크아웃 제한이 없는 Subversion을 사용하고 있습니다.나는 배신자 파일 문제가 규율의 문제라는 데 동의합니다.병합을 사용하지 않으면 근본적인 문제가 해결되지 않습니다. 개발자가 다른 사람의 업데이트 위에 자신의 "고정된" 코드 복사본을 복사하는 것을 방해하는 이유는 무엇입니까?

병합은 피타이지만 로컬 복사본을 조기에 자주 체크인하고 업데이트하면 최소화할 수 있습니다.체크인 위반에 관해 귀하의 의견에 동의합니다. 체크인을 피해야 합니다.반면에 체크인된 변경 사항으로 로컬 복사본을 업데이트하면 변경 사항이 올바르게 병합되어 최종 체크인 시 작업이 원활하게 진행됩니다.

.csproj 파일과 관련하여.그것들은 단지 텍스트일 뿐이고, 파일이 어떻게 구성되어 있는지 알아내는데 시간을 투자한다면 실제로 병합이 가능하며, 유지 관리해야 하는 내부 참조가 있습니다.

나는 프로젝트를 빌드하는 데 필요한 파일이 버전 관리에서 제외되어야 한다고 생각하지 않습니다.프로젝트의 일부가 기록되지 않은 경우 어떻게 안정적으로 변경 사항을 재구축하거나 추적할 수 있습니까?

Answer 5

저는 소규모 회사의 개발 관리자이며 3 명의 프로그래머 만 있습니다. 우리가 일하는 프로젝트는 때때로 몇 주가 걸리며 빅뱅, 충격 및 경외 구현 스타일을 사용합니다. 이것은 우리가 구현하는 밤에 완벽하게 작동 해야하는 많은 데이터베이스 변경과 프로그램 변경이 있음을 의미합니다. 우리는 프로그램을 체크 아웃하고 변경하고 다른 모든 것을 구현하면 다른 20 가지를 날려 버릴 수 있기 때문입니다. 나는 체크 아웃 및 잠금입니다. 그렇지 않으면 다른 사람이 프로그램이 이미 막대한 변화를 겪었다는 것을 깨닫지 못하는 몇 가지를 변경할 수 있습니다. 또한 Merge는 데이터베이스를 변경하지 않았거나 소스 제어가 아닌 다른 시스템을 변경하지 않은 경우에만 도움이됩니다. (Microsoft CRM, 기본적으로 구성을 통해 확장 가능한 모든 패키지 소프트웨어)

Answer 6

IMO, .csproj와 같은 프로젝트 파일은 실제로 소스가 아니기 때문에 버전 관리 시스템의 일부가되어서는 안됩니다.

그들은 또한 거의 확실하지 않습니다.