SVN 이용하다가 커밋을 잘못하는 경우가 발생할 수 있다.


이전버전의 소스코드를 일일이 비교하여 복구하는 노가다를 하는 방법도 있지만 아래 방법이 더 편하다. 

(수정된 내용이 많을수록 더욱 더!!)


# CLI 이용시


 svn merge -rHEAD:xxxx svn+ssh://svn/myserver/trunk ./

 svn ci -m "Roll back to the revision xxxx" 


- svn merge 를 이용하여 rollback 할 버전으로 merge.

- rollback 한 소스를 commit



# Eclipce 이용시


- 해당프로젝트 우클릭 - Team - Update to Revision .. (rollback 할 버전 설정 후 OK)



- rollback 한 소스를 commit



* 만약 변경 이력을 남기면 안되는 내용(보안상의 문제라던지) 을 커밋했을 경우 SVN Dump 를 이용하여, 해당 svn repository 의 특정 revision 까지 백업 후 repository 를  다시 설정해야 한다.



Posted by CJ.Ree
,
  • Root cause analysis (http://en.wikipedia.org/wiki/Root_cause_analysis)

Root cause analysis (RCA) is a method of problem solving that tries to identify the root causes of faults or problems.[1] A root cause is a cause that once removed from the problem fault sequence, prevents the final undesirable event from recurring. A causal factor is a factor that affects an event's outcome, but is not a root cause. Though removing a causal factor can benefit an outcome, it does not prevent its recurrence for certain. RCA arose in the 1950s as a formal study following the introduction of Kepner-Tregoe Analysis, which had limitations in the highly complex arena of rocket design development and launch in the United States by the National Aeronautics and Space Administration (NASA). New methods of problem analysis developed by NASA included a high level assessment practice called MORT, and acronym for Management Oversight Risk Tree. MORT differed from RCA by assigning causes to common classes of cause shortcomings, that summarized became a short list. These included work practice, procedures, management, fatigue, time pressure, along with several others. For example, an aircraft accident could occur as a result of weather augmented by pressure to leave on time. Failure to observe weather precautions could indicate a management or training problem, while lack of any weather concern might indict work practices.


  • 근본 원인 분석 기법

차이(Variance), 결함 또는 리스크를 유발하는 근본적인 이유를 판별하는데 사용되는 분석기법.
한가지 근본 원인이 여러곳의 차이(Variance), 결함, 리스크를 초래할 수 있다.



'용어정리' 카테고리의 다른 글

프로토타이핑 (Prototyping)  (0) 2014.07.16
파일럿 (Pilot)  (0) 2014.07.16
개념검증 (PoC, Proof of Concept)  (0) 2014.07.16
Posted by CJ.Ree
,
  • 프로토타입 (http://ko.wikipedia.org/wiki/프로토타이핑)

프로토타입(prototype)은 원래의 형태 또는 전형적인 예, 기초 또는 표준이다. 시제품이 나오기 전의 제품의 원형으로 개발검증과 양산 검증을 거쳐야 시제품이 될 수 있다. 프로토타입(prototype)은 '정보시스템의 미완성 버전 또는 중요한 기능들이 포함되어 있는 시스템의 초기모델'이다. 이 프로토타입은 사용자의 모든 요구사항이 정확하게 반영할 때까지 계속해서 개선/보완 된다. 실제로 많은 애플리케이션들이 지속적인 프로토타입의 확장과 보강을 통해 최종 설계가 승인된다.


  • 추가설명

- 새로운 컴퓨터 시스템이나 소프트웨어 개발 기법의 하나

개발 초기 단계에서 핵심적인 기능을 구현한 시제품을 만들어 사용자에게 제공

사용자의 시험 사용을 통해서 요구 사항을 분석하거나 요구 사항의 정당성을 검증하고 시제품의 성능을 평가하여다음 단계 또는 실용 시스템에 반영

시제품화는 시제품, 시험 사용, 개선 과정을 반복하여 실용판의 사양을 완성해 나가는 기법

전통적인 생명 주기 모델인 폭포수 모델의 단점을 보완하여 점진적으로 시스템을 개발하는 접근 방법

시제품의 시험 사용을 통해 명확하지 않았던 사용자의 요구사항 파악 가능

 

  • 프로토타이핑의 세가지 유형

- 탐험적 프로토타이핑: 요구사항의 명확한 파악을 위함. 내부 구현은 중요하지 않음. 개발 후 폐기

- 실험적 프로토타이핑: 요구된 S/W의 기술적 구현 여부 판단을 위함. 개발 후 폐기

- 진화적 프로토타이핑: 분석도구로 이용 후, 지속적으로 발전 시켜 원하는 소프트웨어로 만들어 나감



'용어정리' 카테고리의 다른 글

근본 원인 분석 (RCA, Root cause analysis)  (0) 2014.07.25
파일럿 (Pilot)  (0) 2014.07.16
개념검증 (PoC, Proof of Concept)  (0) 2014.07.16
Posted by CJ.Ree
,