내 SVN 디렉토리를 정렬하는 방법?

Question

내 그룹에 3 명의 개발자가 있으며 모두 .NET VB 시스템과 동일한 프로젝트에서 작업하고 있습니다. 그들은 일반적으로 다른 기능을 수행하지만 종종 동일한 파일을 변경하기 때문에 충돌합니다. 소스 파일은 네트워크 장치에서 공유되지만 물론 모든 사람이 자체적으로 작업 복사본 (WC)을 가지고 있습니다. 질문 : SVN 저장소를 설정하는 가장 좋은 해결책은 무엇입니까? :

1) 트렁크 디렉토리의 주요 소스 파일을 가져온 다음 로컬 컴퓨터의 특정 사용자에 대해 각각 다른 WC에서 체크 아웃 한 다음 해당 단일 Repos에서 모든 충돌/병합/커밋/업데이트를 처리합니다. 분기.
2) 트렁크 디렉터리의 주 원본 파일을 가져온 다음 단일 "분기"디렉터리로 복사 한 다음 거기에서 모든 작업을 처리합니다. 일단 모든 것이 설정되면 나는 트렁크와 가지 사이의 합병을 처리한다.
3) 트렁크 디렉터리에있는 주 원본 파일을 가져온 다음 3 개의 다른 "지점"디렉터리로 복사하십시오.

svn copy trunk -> branches/user1; svn copy trunk -> branches/user2; svn 복사 트렁크 -> 지점/user3

그리고 나서 내가 좀 복잡하다고 생각하는 모든 병합을 처리합니다.
4) 다른 솔루션?

많이 들었습니다.

Answer 1

각 개발자가 개인 기록을 유지할 수 있으므로 옵션 # 3을 선호합니다. 분기 및 병합은보다 자주 수행되기 때문에 쉽기 때문에 단기간에이를 실행할 수 있습니다. 이 워크 플로는 또한 feature branching으로 잘 매핑되며, 이는 우수 사례로 간주됩니다.

장기적으로이 팀을 확장하려는 경우 SVN은이 워크 플로우에 적합하지 않습니다. DVCS를 Git 또는 Mercurial과 같이 생각하면 브랜치 및 병합이 크게 단순 해 지므로 이렇게하면됩니다.

Answer 2

초기 분기 모델을 채택해야하는 것처럼 들립니다. 주 소스를 trunk으로 가져온 다음 분기하여 팀에서 작업하십시오. 정상적인 개발 과정에서 한 사람의 변경 사항이 다른 사람과 충돌하지만 버전 제어 시스템에서 예상되는 경우가있을 수 있습니다. 사전 대책을 세우고 학습 경험으로 생각하십시오. 지점의 업무에 만족하면 trunk으로 병합하십시오.

몇 포인터 :

• trunk 왕이다. 실제로이 무엇을하는지 알지 못한다면, trunk은 항상 "황금색"상태 여야합니다. 즉, 빌드를 손상시키는 커밋이 없어야 함을 의미합니다.
• 브랜치의 이름을 적절하게 지정하십시오. 일주일 동안 몇 가지 관련 개발 작업을 선택하고 적당한 이름의 트렁크를 분기하고 작업 한 다음 주말에 다시 병합하십시오. 그런 다음 분기를 삭제하고 새 이름으로 트렁크에서 새 분기를 만들 수 있습니다. 시간이 지남에 따라 트렁크에서 릴리스에 태그를 지정할 수 있습니다 (v1.0, v1.1, ... 등).
• 의미있는 커밋 메시지와 함께 작은 커밋을 만듭니다. 그것은 3, 6, 12 개월 동안 당신을 도울 것입니다.

자세한 정보 here 및 here.

Answer 3

첫째로, "소스 파일이 네트워크 장치에서 공유되었습니다" "입니다. 그게 무슨 뜻 이니? 일부 사이트의 경우 공유 네트워크 드라이브가 있으며 체크 아웃 및 체크 인을 수행하려면 file://을 사용하십시오. 네가 그렇게한다면 그렇게하지 마라. 대신 svnserve 또는 Apache HTTPD를 사용하십시오. svnserve은 Windows에서 설치하기가 쉽고 svnserve을 Windows 서비스로 설정하는 방법에 대한 지침이 많으므로 자동으로 시작되어 다시 시작됩니다. 주된 문제는 포트 3690이 네트워크에서 차단되었는지 여부입니다. 또한 아파치 웹 서버와 서브 버전을 이미 설치 한 Windows 패키지가 여러 개 있습니다. 일부는 완전히 오픈 소스 솔루션이지만 대부분 무료입니다.

파일 충돌이 자주 발생하지 않아야합니다. Subversion은 매우 정상적인 방식으로 충돌을 처리 할 수 ​​있습니다. 개발자 은 작업 복사본을 체크 아웃하므로 개발자는 B입니다. 개발자 및 모두 foo.vbs가 변경됩니다. 개발자 B이 먼저 복사본을 작성합니다. 개발자 시도가 자신의 변경 사항을 적용 할 때, Subversion은 개발자 B 개발자 의 변화를 포함하는 자신의 작업 복사본을 업데이트 할 때까지 커밋 개발자 B을 허용하지 않습니다. 개발자 이이를 수행하고 변경 사항을 테스트하면 조합 된 변경 사항 집합을 커밋 할 수 있습니다. 이것이 첫 번째 시나리오입니다. 두 개발자 및 B 각각의 지점에서 트렁크 체크 아웃에서 지점을 만듭니다

별도의 지점에 각 개발자의 작업을함으로써, 시나리오 # 3를 사용하면 정말 시나리오 1과 같은 일을한다. 병합하지 않고 자신의 사업장에 자신의 업무를 맡길 수 있지만 조만간 그들은 코드를 다시 병합해야합니다. 그런 다음 첫 번째 개발자가 쉽게 병합을 수행 할 수있는 문제와 동일한 문제가 발생하지만 두 번째 개발자는 병합 충돌을 처리해야합니다.

유일한 차이점은 병합 충돌을 처리해야한다는 것입니다. 시나리오 # 3을 사용하면 개발자가 게임 후반부까지 병합 충돌을 무시할 수 있으므로 병합 처리가 훨씬 어려워집니다. 시나리오 # 1은 개발자가 문제가 아직 작을 때 즉시 문제를 처리하도록합니다. 저는 수십 명의 개발자가 모두 동일한 지사에서 아무런 문제없이 작업했습니다.