2012-07-25 3 views
0

필자가 진행중인 프로젝트에서 리팩터링이 절실히 필요합니다. 문제는 일반적으로 여러 가지 (유지 관리, 새로운 기능 등)가 있으며 파일과 디렉토리를 쉽게 이동, 이름 바꾸기 및 삭제하고 변경 사항을 병합 할 수 있는지 잘 모르겠습니다. 내 두려움은 누군가가 다른 브랜치에서 파일을 업데이트하는 동안 리팩토링 브랜치에서 파일을 옮기는 것이다. 나는 트렁크에 모든 것이 있고 어떤 지점도 필요하지 않은 작은 창을 원했지만, 비즈니스는 항상 변경 사항을 필요로합니다 (즉각적으로 또는 마이너 릴리스의 일부로).리팩토링 SVN 분기 코드

우리의 소스 컨트롤은 Subversion으로 관리됩니다. 한 지점에서 프로젝트를 대폭 변경하는 것이 쉽고/가능한지, 다른 사람과 동기화하여 변경 사항을 유지할 수 있습니까? 나는 브랜치를 최신 상태로 유지하기 위해 변경 사항을 병합하는 것이 좋으며 한 번에 작은 리펙토링 변경 만하면됩니다. 그렇지 않으면 리팩토링 (예 : 다른 분기 없음)에서만 작동하는 시간을 제쳐두고 실제로이 작업을 수행 할 수 있습니까? 나는 우리가 리팩토링하는 데 시간이 필요하다는 것을 사업자들에게 확신시키기 위해 노력해 왔으며, 동의하는 동안 지금은 불가능 해 보입니다.

리팩터링에서 중요한 점 중 하나는 항상 수행해야한다는 것입니다. 그것은 실제 코드 (함수 분리, 중복 코드 제거 등)로 수행 할 수있는 것 같지만 파일을 적절하게 이름을 바꾸고 그룹화하는 것에 대해서는 확신하지 못합니다.

답변

3

SVN에서는 할 수 있지만 다른 문제가 많이 생길 것입니다. 리팩토링이 모든 지점으로 가고 싶다면 두 번 생각해보십시오. 리팩토링 된 코드를 병합하여 분기를 릴리스하는 것은 합리적이지 않습니다 (프로덕션 버전에 대한 작은 수정 사항을 릴리스하는 유지 관리 지점).

SVN을 사용하면 모든 분기에서 모든 분기로 병합 할 수 있지만 분기와 원래 분기간에 병합하는 것이 더 합리적입니다. 이 같은 경우 따라서 :

Rel-1.0   /----------------> 
Rel-1.1  / /-------------------> 
Trunk  --------------------------------*------> 
FeatureA   \--------> \  \ ^(rev. X) 
FeatureB      \--> \ | 
Refactor        \---> 

대신 팩터에서 리팩토링 작업을 수행하고 다른 모든 지점에 병합은 트렁크에 리팩터링 지점의 변경을 재 통합하는 것이 더 합리적이다 (X 버전에서 가정) 그런 다음 Trunk의 개정 X를이 변경이 필요한 다른 분기로 병합하십시오. Release Branches (Rel-1.0, Rel-1.1)의 경우, 체리 피크가 될 가능성이 큽니다. 기능 브랜치 A/B의 경우 트렁크를 따라 잡을 것입니다 (트렁크의 모든 것을 병합하여).

분기가 트렁크에서 더 벗어나는 경우 병합이 더 어려워집니다. 따라서 분기를 해제하기 위해 리팩토링 된 코드를 병합해야 할 필요가 있다면 두 번 생각하십시오 (트렁크에서 벗어날 가능성이 큽니다).

또한 SVN에서 이름 바꾸기가 잘 구현 된 것은 아닙니다. 예를 들어, 트렁크에서 F라는 파일의 이름을 FNew로 변경했으며, F에서 복사하여 FNew를 추가하고 F를 삭제하는 것은 SVN으로 처리합니다. 분기, afaik, SVN에서 병합하면 trunk/F를 누르고 branch/F를 삭제하십시오. 따라서 SVN의 새로운 버전 (아마도 1.5 이상)에 대해 브랜치/F를 수정 한 적이 있다면, 트리 충돌을 일으키고 SVN의 구버전에서는 수정을 잃어 버리게됩니다.최신 버전이 조금 개선되었지만 "올바르게"(분기/F를 분기/FNew로 이동하는) 이름 바꾸기 병합을 처리하는 사람은 없습니다. 이렇게하면 병합에 더 많은 노력이 필요할 것이고, 두 분기가 많이 벗어난 경우 병합이 더 어려워 질 수 있습니다.

-1

하나의 브랜치를 수정하고, 패치 파일을 생성하며, 다른 모든 브랜치를 업데이트하기 위해 동일한 패치 파일을 사용할 수 있다고 생각하십니까?

+0

좋습니다. 필자는 다른 사람의 코드를 패치하기 위해 다운로드 한 파일을 제외하고는 패치 파일을 사용한 적이 없습니다. – ravun

+1

패치를 사용하면 도움이되지 않으며 SVN 병합 추적도 손실됩니다. 병합을 사용하는 것만으로도 좋습니다. –

+0

아, 좋은 정보입니다. – ravun

1

분기를 대폭 변경하면 특히 다른 사람이 동일한 파일을 변경하는 동안 코드를 다시 병합하는 데 문제가 있습니다.

일부 영리한 스케줄링을 권장합니다. 현재 작업하지 않는 코드 부분을 작업해야합니다. 또는 리팩토링을 일반적인 비즈니스 운영에 포함 시키십시오.