svn rollback

svn은 rollback 기능을 제공하지 않고, 불편하지만 아래 방식을 사용함.

svn merge -r 2642:2641 .
svn st
svn commit -m "Rollback to revision 2641"

출처 : http://wiki.kldp.org/wiki.php/SubversionBook/BranchingAndMerging

-----

1.4. 저장소(repository)로부터의 변경을 삭제한다

svn merge 가 좋게 있는 사용법은 벌써 커밋했다 변경을 롤백(rollback) 하는 것입니다. integer.c (을)를 변경한 리비전 303의 변경은 완전하게 실수였다고 합니다. 그것은 커밋해야 하지는 않았습니다. 작업 카피의 변경을 취소하는데 (은)는svn merge 를 사용할 수가 있습니다. 그 후로 로컬 의 변경을 저장소(repository)에 커밋합니다. 하지 않으면 안 되는 것은, 반대 방향의차분을 지정하는 것 뿐입니다:

<pre class="SCREEN">$ svn merge -r 303:302 http://svn.example.com/trunk/calcU integer.c$ svn statusM integer.c$ svn commit -m "Undoing change committed in r303. "Sending integer.cTransmitting file data .Committed revision 350.</pre>

저장소(repository) 리비전에 대한 하나 더의 생각은, 그것을 특정의 변경의 모임이라고 생각하는 것입니다(몇개의 버전 관리 시스템에서는, 이것을,changesets와 부르고 있습니다). -r 스윗치를 사용해 svn merge 를 호출하는 것으로, 어느 체인지 세트를 적용하는지, 혹은 있는 범위의 체인지 세트 전부를 작업 카피에 적용할 수가 있습니다. 우리의 경우라면svn merge (을)를 사용해 체인지 세트#303를 작업 카피에반대 방향으로 적용합니다.

이러한 변경의 취소는, 보통svn merge 의 조작에 지나지 않기 때문에, 작업 카피가 바라는 상태가 되었는지 어떠했는지는 svn status 와svn diff 를 사용할 수가 있어 그 후svn commit 로 저장소(repository)에 최종적인 버전을 보낼 수가 있다, 라고 하는 것을 눌러 두어 주세요. 커밋 후는 이 특별한 체인지 세트는 이미 HEAD 리비전에는 반영되지 않습니다.

이렇게 생각할지도 모릅니다: 로 하면(자), 그것은 「취소」가 아니다 (이)가 아닌가. 변경은 아직 리비전 303에 존재하고 있는 것은, 이라고. 만약 누군가가calc 프로젝트의 리비전 303 (와)과 349의 사이의 버전을 체크아웃 했다고 하면(자), 잘못했다 변경을 받아들이는 것은 아닌지, 다른지, 라고.

말씀하시는 대로. 우리가, 변경의 것"취소"에 대해 말할 때, 사실은"HEAD로부터 없애는 것"을 말합니다. 원래의 변경은 저장소(repository)의 히스토리에 여전히 남아 있습니다. 대부분의 상황에서는 이것으로 충분합니다. 어쨌든 대부분의 사람들은 프로젝트의 HEAD를 뒤쫓는다 일에만 흥미가 있기 때문입니다. 그러나, 커밋에 관한 모든 정보를 삭제하고 싶다고 하는 예외적인 상황도 있겠지요. (아마, 누군가가 극비의 문서를 커밋해 버린, 등) 이것은 그렇게 쉬운 일이 아닙니다. Subversion은 의도적으로 결코 정보가 없어지지 않게 설계되고 있기 때문입니다. 히스토리로부터의 리비전의 삭제는, 연쇄적인 영향을 주어 모든 후속 리비전과 아마 모든 작업 카피에 혼란을 일으킵니다.

출처 URL : http://altibase.egloos.com/319877