SVN에서 개별 파일을 어떻게 분기합니까?

Question

분기의 개념은 개발을 수행 할 전체 저장소의 안정되지 않은 포크를 만드는 데 초점을 맞춘 것으로 보입니다. 개별 파일의 분기를 만드는 메커니즘이 있습니까?

사용 사례의 경우 플랫폼에 특정한 여러 소스 (* .c) 구현이있는 일반적인 헤더 (* .h) 파일을 생각해보십시오. 이 유형의 지점은 영구적 인 지점입니다. 이 모든 지사는 때때로 교차 지회 합병을 통해 지속적인 개발을 보게됩니다. 이것은 일반적으로 유한 수명을 갖는 불안정한 개발/안정 방출 지점과는 현저한 대조를 이룹니다.

트렁크와 모든 가지 사이에서 지속적으로 병합하기 위해 무리한 유지 관리가 발생하므로 저장소 전체를 (저렴하거나 아예없는) 분기하려고합니다. 현재 ClearCase를 사용하고 있습니다. ClearCase는 다른 방식으로 쉽게 분기 할 수있는 개념을 가지고 있습니다. SVN으로 전환하는 것을 고려해 달라는 요청을 받았지만이 패러다임의 차이는 중요합니다. 필자는 안정적인 릴리스 분기를 절단하는 것보다 개별 파일에 대한 대체 버전을 쉽게 만들 수 있다는 것에 훨씬 더 우려하고 있습니다.

Answer 1

를 사용하여 해당 파일을 전환 할 수 있습니다 슬프게도, 나는 진정한 대답은 ClearCase가이 상황을 Subversion보다 훨씬 잘 처리한다는 것입니다. Subversion을 사용하면 을 모두으로 분기해야하지만 ClearCase는 특정 파일 그룹 만 분기된다는 것을 의미하는 일종의 "게으른 분기"아이디어를 허용합니다. 나머지는 여전히 트렁크 (또는 사용자가 지정한 분기)를 따릅니다.

여기 제공된 다른 솔루션은 실제로 의도 한대로 작동하지 않으며 파일을 다른 경로로 복사하는 것입니다. 이제 그 파일을 실제로 사용하려면 이상한 일을해야합니다.

님, 죄송합니다. 그건 정말 좋은 답변이 아니 었습니다. 그러나 Subversion에서는 이와 같은 좋은 해결책이 없습니다. 해당 모델은 분기 및 병합입니다.

편집 : 좋아요, 그래서 crashmstr이 말한 내용을 확장하십시오. 당신은 이것을 할 수 있었다 :

svn cp $REP/trunk/file.h $REP/branched_files/file.h 
svn co $REP/trunk 
svn switch $REP/branched_files/file.h file.h 

그러나 와우!는 오류에 쉽게 걸린다. 당신이 svn st을 할 때마다 이것을 볼 수 있습니다 :

조금 시끄 럽습니다.그리고 커다란 소스 저장소 내에서 몇 개의 파일이나 모듈을 브랜치하고자 할 때 매우 지저분 해지기 시작할 것입니다.

사실, ClearCase의 분기 된 파일을 svn 속성으로 전환하고 전환하는 것과 같은 굉장한 프로젝트가 있습니다. 모든 덤프를 처리하기 위해 늪지 표준 svn 클라이언트 주위에 래퍼를 작성해야합니다.

Answer 2

Subversion "분기"는 저장소의 사본입니다. 따라서 파일을 분기하려는 경우 다음을 수행하십시오.

svn copy myfile.c myfile_branch.c 

Answer 3

SVN의 브랜치는 단지 사본입니다. 필자는 원하는 방식대로 파일의 각 버전을 저장소의 별도 디렉토리에두고 소스 폴더에 체크 아웃해야한다고 생각합니다. I.E. 그 파일을 별도의 프로젝트처럼 취급하십시오.

Answer 4

전체 저장소를 브랜치 할 필요는 없습니다. 프로젝트에서 폴더의 분기를 만들 수 있습니다 (예 : 포함 폴더). 다른 사람들이 언급했듯이 하나의 파일 만 "복사"할 수 있습니다. 파일이나 폴더의 사본이 있으면 분기 된 파일이나 폴더로 "전환"하여 지점 버전에서 작업 할 수 있습니다. 당신이 저장소에 폴더를 별도의 지점을 만드는 경우

, 당신은 서버 측 명령을 통해 거기 분기 파일을 복사 할 수 있습니다 :

 
svn copy svn://server/project/header.h svn://server/branched_files/header.h 

는 그런 다음 branches_files 저장소 경로

Answer 5

단일 파일을 분기 할 때 많은 부분이 있다고 생각하지 않습니까? 트렁크 코드로 테스트 할 방법이 없습니까?

변경 사항을 취소하고 나중에 적용하려면 패치를 대신 수행 할 수 있습니다.

Answer 6

VCS에 이 정말로 필요합니까?

왜 필요하지 않은 코드를 C 프리 프로세서와 #ifdef로 사용하지 않을까요? 아니면 비슷한 도구. 같은

뭔가 : 때때로

// foo.h: 
void Foo(); 

// foo_win32.c 
#ifdef _WIN32 
void Foo() 
{ 
    ... 
} 
#endif 

// foo_linux.c 
#ifdef _GNUC 
void Foo() 
{ 
    ... 
} 
#endif 

이 잘 맞지 않는 경우는, 다음은 올바른 해결책이 아니다.

Answer 7

다음은 귀하의 문제를 이해하는 방법입니다. 다음과 같은 트리가 있습니다

 
time.h 
time.c 

및 여러 아키텍처를 감소해야합니다 필요에 따라 time.c에서 많은 가지를 작성하여이 작업을 수행 할 수 있습니다 또한

 
time.h is comon 
time.c (for x386), time.c (for ia64), time.c (for alpha),... 

을 현재 VCS에 VCS에서 파일을 체크 아웃하면 공통 트렁크의 최신 time.h와 작업중인 지점의 최신 time.c가 자동으로 검사됩니다.

당신이 염려하는 문제는 브랜치를 체크 아웃 할 때 SVN을 사용하면 트렁크의 time.h를 매우 자주 병합하거나 (트렁크에 비해) 오래된 파일에서 작업 할 위험이 있다는 것입니다 오버 헤드가 허용되지 않습니다.

소스 코드의 구조에 따라 해결책이있을 수 있습니다. 당신이 그럼 당신은/분기 수

 
/
/headers/ 
/headers/test.h 
/source/ 
/source/test.c 

을 상상하고, 트렁크의 머리에 헤더를 연결하는 svn:externals 기능을 사용합니다. 디렉토리에서만 작동하며 test.h로 돌아가는 것과 관련하여 몇 가지 제한 사항이 있습니다 (작동하려면 헤더 디렉토리에 있어야합니다).

Answer 8

Subversion의 브랜치 (branch)가 당신이 말하는 것입니다. 모든 파일은 사용자가 변경 한 파일을 제외한 트렁크의 정확한 사본입니다. 이것은 SVN Book에서 언급 된 "저렴한 사본"방법론입니다. 유일한주의 사항은 트렁크를 지점으로 병합해야 할 필요가 있다는 것입니다. 변경 사항이 지점에 반영되도록하기 위해서입니다. 물론 이러한 변경이 필요하지 않으면 트렁크 -> 분기 병합을 수행 할 필요가 없습니다.

트렁크 변경 사항을 자동으로 병합 (Clear Case 패러다임을 시뮬레이트 함) 할 수있는 쉬운 방법 중 하나는 커밋하기 전에 트렁크 변경 사항을 병합하기 위해 사전 커밋 (pre-commit) 훅 스크립트를 사용하는 것입니다. 이것은 항상 코드 드리프트를 방지하는 좋은 전략입니다).