Subversion : 트렁크에 병합되지 않은 모든 개정을 찾는 방법은 무엇입니까?

Subversion : 트렁크에 병합되지 않은 모든 개정을 찾는 방법은 무엇입니까?

---

릴리스주기에 대한 분기 소스는 일반적인 소스 관리 시나리오 중 하나입니다. 가능한 한 빨리 병합하는 것이 좋습니다. 따라서 우리는 인적 요소를 가지고 있습니다. 가지가 닫혀 있지만 누군가가 무언가를 다시 트렁크에 병합하는 것을 잊었습니다.

Q : 분기 X에서 트렁크로 병합되지 않은 모든 개정 번호를 가져 오는 "한 번의 클릭"방법이 있습니까?

(참고 : 병합 할 항목을 찾기 위해 이러한 수정 번호가 필요하지 않습니다. 자동 유효성 검사를 생성해야합니다.이 번호는 사람들이 트렁크에 항목을 병합하는 것을 잊지 않았는지 확인하도록 상기시켜줍니다. 병합 자체는 문제가되지 않습니다.)

svn mergeinfo 명령이 여기서 도움이되지 않는 것 같습니다. 병합이 루트 수준에서 수행되지 않은 경우 분기 및 트렁크 루트 전달이 실패합니다 (일반적인 시나리오 임).

스크립트, 도구 모든 종류의 svn 후크를 솔루션으로 환영합니다.

추신

최신 버전의 SVN. 이 시나리오가 얼마나 일반적이거나 좋은지 논쟁 할 필요가 없습니다.)

---

짧은 대답 : 그렇게 생각하지 않습니다.

긴 대답 :이 질문에 답하기 위해 파이썬 스크립트를 작성했습니다. 개발자가 변경 집합을 병합 할 때마다 로그 메시지에 "merged rXXX"를 입력해야합니다. (이는 svn : mergeinfo가 존재하기 전의 것입니다.) 스크립트는 모든 라이브 svn 브랜치 + 트렁크를 구문 분석하고 모든 "병합 된"링크를 재귀 적으로 스캔하여 병합하지 않은 변경 사항의 개발자 별 목록을 출력합니다.

[업데이트] @tmont의 대답은 더 나은 지금은 모두가 지원하는하는 SVN 버전을 가지고 있다는 것입니다 svn mergeinfo --show-revs eligible그리고 svn merge --record-only그 시간에 당신은 단지 논리적 인 수정을 기록합니다.

---

mergeinfo하위 명령 과 함께 비교적 최신 버전의 Subversion (1.5 이상)을 사용하는 경우이 작업을 매우 쉽게 수행 할 수 있습니다 .

svn mergeinfo --show-revs eligible svn://repo/branches/your-branch-name svn://repo/trunk

그러면 "your-branch-name"브랜치에서 트렁크에 병합 할 수있는 모든 개정이 표시됩니다.

출처 : http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.mergeinfo.html

---

나는 당신의 사건이 아마도 너무 늦었 음을 알고 있지만, 이런 종류의 일을 위해 내가하는 일은 나중에 식별 할 수 있도록 병합 커밋에 대한 규칙을 설정하는 것입니다. 예 : "Merging [1234] : ... (전체 커밋 로그 1234) ...". 그런 다음 나중에 스크립트를 사용하여 svn 로그에서 구문 분석 할 수 있습니다.

전체 팀이이를 수행하도록하려면 병합 규칙을 스크립트로 만들고 프로젝트에 넣으십시오. (예 : ./scripts/merge 1234). 사람들은 일반적으로 이것을 고맙게 생각할 것입니다. 따라서 스크립트가 원본 svn 명령이 소스 URL을 자동으로 파악하는 것과 같은 작업을 수행하는 것보다 병합을 더 쉽게 만든다면

행운을 빕니다.

---

병합해야하는 특정 변경 번호에 대해서는 걱정하지 않고 diff 만 살펴 보겠습니다.

먼저, 트렁크와 함께 사이드 브랜치를 최신 상태로 만듭니다 (또는 병합 될 항목 확인).

cd branch-dir
svn merge --reintegrate http://svnrepo/path-to-trunk .
svn ci -m'making this branch current'

cd ../trunk-dir
svn merge --dry-run http://svnrepo/path-to-trunk http://svnrepo/path-to-branch .
svn ci -m'merging in all unmerged changes from <branch>'

svn merge 명령은 svn diff 명령과 비슷하다는 것을 기억하십시오. diff / patch를 만든 다음이를 특정 위치에 적용합니다. 위의 병합 명령은 단순히 "트렁크와 브랜치 간의 모든 차이점을 가져와 트렁크의 작업 복사본에 적용"하는 것입니다. 따라서 두 번째 병합 명령을 메일 알림에 대한 diff로 쉽게 변경할 수 있습니다.

나쁜 일이 발생하지 않았는지 확인하기 위해 각 경우에 커밋하기 전에 diff를 확인하는 것을 잊지 마십시오. 일부 충돌을 해결해야 할 수도 있습니다.

---

지금 당장 테스트 할 SVN 서버가 집에 없어서 미안하지만 다음 명령을 사용할 수 있습니다.

svn log --verbose

어떤 것을 파싱 할 수 있습니까? 메인으로 다시 병합 한 후 출력이 확실하지 않지만 로그를 구문 분석하고 (내 SVN 서버를 사용하는 유일한 사람이기 때문에없는 스크립트를 사용하여) 모두 읽을 수 있습니다. 체크인 된 파일을 찾은 다음 파일이 main에 병합되었음을 나타내는 키워드를 찾으십시오.

시간이 있으면 오늘 밤 집에 가면 확인해 보도록하겠습니다.

---

이러한 이유로 CVS는 분기의 루트를 표시하는 태그를 만들었습니다. :) SVN의 경우 다음과 같아야합니다.

+ trunk / project1
+ tags / project1-b1-root
+ branches / project1-b1

메모:

1. 태그 project1-b1-root 와 branch project1-b1 은 트렁크에서 동시에 생성됩니다.
2. 아무도 project1-b1-root에 커밋해서는 안됩니다 ( 태그 / 경로에 대해이 작업을 제한 할 수 있음 ).
3. 모두가 그가 모든 것을 트렁크에 넣었다고 주장 할 때, 당신은 project1-b1-root 와 project1-b1 사이에 차이를 만들고 그것을 트렁크에 적용하려고 시도합니다 : 이미 적용된 변경은 조용히 건너 뛸 것입니다. 나머지는 차이 또는 충돌을 볼 수 있습니다.

---

윌 svn merge --dry-run당신이 필요로하는 정보를 제공?

---

은색 총알이 없기 때문에 합쳐진 내용과 위치를 기록하는 것이 규율적인 방법입니다.

---

를 기반으로 에테르 의 답변 위의 지점에서 당신이 병합되지 않은 버전을 확인하려면,

svn merge --dry-run http://svnrepo/path-to-merge-source .  \
| grep Merging                                             \
| sed 's/--- Merging//'                                    \
| sed 's/into.*//'                                         \
| sort -u                                                  \
| sed 's/ through r/:/'                                    \
| sed -e :a -e N -e 's/\n//' -e ta                         \
| sed 's/ r/ -r/g'                                         \
| sed 's|^|svn log http://svnrepo/path-to-merge-source |'

---

3 년 만에 당신의 실을 즐기고 있습니다. 그리고 나는 당신이 넣은 형태로 당신의 작업에 대한 해결책이 아직 없다고 생각합니다 :)

What I found though in the $ svn help merge is the advice not to do sub tree merges:

If you want to merge only a subtree, then the subtree path must be included in both SOURCE and TARGET_WCPATH; this is discouraged, to avoid subtree mergeinfo

So I guess the solution is to break your "common scenario" of doing subtree merges.

It would be mandatory to establish some control for merge operation, as otherwise anybody having Read access to one branch and Write access to another can do the merge from first to second. So the actual question is - how to control subtree merges ))

---

I have written Java Web Application using Wicket and SVNKit for finding not merged revisions between branches, it could be customized to do whatever you want... link

o

ReferenceURL : https://stackoverflow.com/questions/2207756/subversion-howto-find-all-revisions-that-are-not-merged-to-trunk