이 문제는 SCM의 복구측면의 이슈보다는 RSA에서 모델링간의 병합이슈가 더 크지 않을까 싶습니다.

..., 하나의 작업하고 있는 모델 파일을 잠시 그냥 다른 폴더에 저장했다가 다시 반영하였을 때 병합이슈가

있으냐 없느냐의 차원이라는 겁니다. 이렇게 했을 때 빠르게 잘 되는데 위와 같이 했을 때만 느리다면 RTC의 말씀과 같은

부분을 어떻게 개선해야할지 고려해야되는 상황이라는 겁니다.

병합이 많아서 문제가 된다면 이는 SCM은 둘째치고 현재 모델들간의 병합 이슈가 우선적으로 좀 더 개선이 되어야하지

않을까 싶습니다. 

그리고 되도록이면 baseline을 자주 만들도록 합시다.

1. 보통 reverse를 해서 내려 가거나,

2. baseline에서 다시 올라가는 방법이 있습니다.

(2) 번 처럼 baseline이 자주 있으면, 원하는 베이스라인으로 콤포넌트 베이스라인을 변경한뒤 accept하는 방식으로 올라가는 방식이 편리해 집니다. 거기서 베이스라인을 긋어 버리고 나서 새로운 스트림을 만들어 사용하는 방법도 고려해 볼 수 있습니다.

답변 감사합니다.

병합이슈 때문에 되돌리기가 힘들어서 버리기 기능을 알아봤는데 없다고 하네요. 필요하다면 개선사항으로 올리라고 하는데 올리는게 맞는지 모르겠습니다.

단순히 관리의 목적이라면 기능이 있으면 좋으나, 프로그램 개발의 차원에서 모두에게 공유되는 스트림까지 올라간 내용을 바로 버리기 하는 기능을 제공한다는 것이 맞는지는 고민해야 될 것 같습니다.

호주에서 온 답변입니다. 풍차님이 보내주신 내용 그대로네요. ^^

Normal 0 0 2 false false false EN-US KO X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"표준 표"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; mso-bidi-font-size:11.0pt; font-family:"맑은 고딕"; mso-ascii-font-family:"맑은 고딕"; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"맑은 고딕"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:"맑은 고딕"; mso-hansi-theme-font:minor-latin; mso-font-kerning:1.0pt;}

1. 문의 주신 내용으로 미루어 볼때 아래 링크에 포함된 reversing 방법은 이미 시도해보셨고, 적당하지 않은 방법으로 판단을 하신거죠?

http://jazz.net/library/article/126/#How_do_I_remove_a_change_set_fro

2. 같은 링크의 두번때 파트를 고려해보셨는지요?

잘못된 changeset이 포함되지 않은 baseline으로 바꾸는 것입니다.

이때 한가지 유의 하셔야할 점이 있는데, 이렇게 할때는, 벌써 누군가가

Accept하고, 없앨 changeset위에 작업을 했을때, 그 changeset들이 outgoing changeset으로 표시되는 것입니다.

이 경우엔 다음 링크에서 해결 방법을 찾으실 수 있습니다.

http://jazz.net/library/article/126/#Sometimes_I_have_outgoing_change

위의 방법들이 모두 적절하지 않으실 때는 Jazz.net에 Enhancement Workitem을 등록 시키실 수 있습니다.

이에 대해 궁금하신 점이 있으시면 연락주세요.

저도 baseline을 생각했었지만, 올려놓으신 이미지에보니 업데이트 주기가 빠른 상황에서는(하루에서 몇번의 변경이 있다면)

baseline 방법은 현실성이 떨어질 것 같습니다. 기기에서 해결하기보다 모델 자체를 어떻게 나누고 구성할지를 다시한번 보시게 현실적일 수 있습니다.