답변:
기본적으로 "뒤로 병합"해야 합니다. 현재 버전 과 이전 버전 사이의 차이를 현재 버전 에 적용한 다음 (이전 버전 과 같은 작업 복사본으로 끝남) 다시 커밋합니다. 예를 들어 개정판 150 (현재)에서 개정판 140으로 돌아가려면 다음을 수행하십시오.
svn update
svn merge -r 150:140 .
svn commit -m "Rolled back to r140"
Subversion Red Book에는 이것에 대한 좋은 섹션이 있습니다.
svn merge -r HEAD:140.
서브 버전 히스토리 의 헤드 에서만 새로운 변경 사항을 커밋 할 수 있습니다 .
당신이 당신의 PC에있는 좋은 사본으로 직접 아무것도 할 수없는 이유는 .svn폴더가 과거의 코드임을 알고 있기 때문에 커밋 전에 업데이트가 필요하기 때문입니다.
원하는 이전 사본의 개정 번호를 찾으십시오.
다음을 사용하여 현재 개정판을 받으십시오 .
svn info --show-item revision
# or
svn log
또는 이전 버전의 프로젝트 를 확인 하려면 다음을 사용하십시오.
svn update -r <earlier_revision_number>올바른 개정 번호를 찾을 때까지
올바른 개정 번호를 기록해 두십시오 ( 123아래 예 참조).
최신 개정으로 업데이트하십시오.
svn update원하는 개정판과 최신 버전 사이의 모든 변경 사항을 취소하십시오.
svn merge -r HEAD:123 .
svn commit "Reverted to revision 123"
(위의 Jon Skeet의 답변과 동일합니다.)
이전 사본을 찾을 수없고 현재 PC에있는 파일을 커밋하려는 경우 :
좋은 버전의 사본을 만드십시오 (그러나 .svn폴더는 없습니다).
cd ..
rsync -ai --exclude=.svn project/ project-good/
이제 최신 버전인지 확인하십시오.
cd project
svn update
# or make a fresh checkout
svn checkout <url>
작업 버전 상단에 올바른 버전을 복사하십시오.
이 명령은 올바른 트리에없는 파일을 작업 트리에서 복사하고 삭제하지만 기존 .svn폴더 에는 영향을 미치지 않습니다 .
cd ..
rsync -ai --exclude=.svn --delete project-good/ project/
rsync가없는 경우 사용할 수 cp -a있지만 원하지 않는 파일을 수동으로 삭제해야합니다.
지금 가지고있는 것을 커밋 할 수 있어야합니다.
cd project
svn commit "Reverted to good copy"
이 줄을 사용하십시오
svn 업데이트 -r yourOldRevesion
다음을 사용하여 현재 개정판을 알 수 있습니다.
svn 정보
병합을 사용하여 전체 체크인을 취소하는 표준 방법은 원하는 경우 효과적입니다. 그러나 때로는 단일 파일을 되돌리기 만하면됩니다. 그렇게 할 수있는 합법적 인 방법은 없지만 해킹이 있습니다.
svn의 export 하위 명령을 사용하십시오.
svn 내보내기 http : // url-to-your-file @ 123 / tmp / filename
(여기서 123은 파일의 올바른 버전에 대한 개정 번호입니다.) 그런 다음 해당 단일 파일을 이동하거나 복사하여 이전 파일을 덮어 씁니다. 수정 된 파일을 체크인하면 완료됩니다.
svn합니까?
svn cat -r 123 path-in-your-working-copy > path-in-your-working-copy
조금 더 구식
svn diff -r 150:140 > ../r140.patch
patch -p0 < ../r140.patch
그리고 평소
svn diff
svn commit
이전 답변의 대부분은 리버스 병합을 사용했으며 일반적으로 정답입니다. 그러나 그렇지 않은 한 가지 상황 (나에게 일어난 일)이 있습니다.
작은 변경을 할 때 실수로 Unix 줄 끝이있는 파일을 DOS 줄 끝으로 변경하고 커밋했습니다. 이것은 줄 끝을 변경하고 다시 커밋하거나 역 병합하여 쉽게 취소 할 수 있지만 svn blame, 파일의 모든 줄의 소스로 내 목록을 편집 하는 효과가 있습니다. 흥미롭게도 Windows의 TortoiseSVN은 이것의 영향을받지 않으며 명령 줄 만 영향을받습니다 svn blame.
에서보고 한대로 기록을 유지 svn blame하려면 다음을 수행해야한다고 생각합니다.
삭제는 약간 무섭지 만 항상 파일을 리포지토리에 저장 했으므로 복원하는 것이 중요하지 않습니다. 다음은 단계를 설명하는 코드입니다. xxx이것이 마지막 양호한 사본의 개정 번호 라고 가정하십시오 .
svn rm svn+ssh://path/to/file
svn copy svn+ssh://path/to/file@xxx svn+ssh://path/to -m"Restore good copy"
svn update
<restore the edits>
svn commit -m"Restore edits"
저장소의 사본의 경우 대상은 파일 이름이 아닌 디렉토리 여야합니다.
Jon Skeet의 대답은 간단히 말해서 해결책이지만, 당신이 나와 같다면 설명을 원할 수도 있습니다. Subversion 매뉴얼은 이것을
매뉴얼 페이지에서.
이 형식을 '체리 픽'병합이라고합니다. '-r N : M'은 수정본 N과 M 사이의 소스 분기 이력 차이를 나타냅니다.
'역 범위'를 사용하여 변경을 취소 할 수 있습니다. 예를 들어 소스와 대상이 동일한 분기를 참조 할 경우 이전에 커밋 된 개정은 '실행 취소'될 수 있습니다. A의 리버스 레인지 또는 "-c"옵션은 음수로 사용되는 「M N -r ', N은 M에서보다 큰 "-c -M'에 해당 'M -r'. 이와 같은 변경을 취소하면 '역 병합'을 수행하는 것으로 알려져 있습니다.
소스가 파일 인 경우 해당 파일에 차이가 적용됩니다 (이전 변경 내용을 병합하는 데 유용함). 그렇지 않으면 소스가 디렉토리 인 경우 대상의 기본값은 '.'입니다.
일반적인 사용법에서 작업 복사본은 단일 수정 버전에서 최신 상태 여야하며 로컬로 수정하거나 하위 트리를 전환하지 않아야합니다.
예:
svn merge -r 2983:289 path/to/file
이것은 로컬 사본 [2983] (위의 인용에 따라 서버와 동기화되어야합니다-귀하의 책임)을 서버의 개정 289로 대체합니다. 변경 사항은 로컬에서 발생합니다. 즉, 체크 아웃이 깨끗하면 변경 사항을 커밋하기 전에 검사 할 수 있습니다.