SVN 커밋 메시지를 편집 할 수없는 이유는 무엇입니까?

SVN을 사용하고 있습니다. 커밋 메시지를 작성할 때 때때로 뭔가를 놓칩니다. 그러나 일단 커밋되면 되돌릴 수 없으며 메시지를 편집 할 수도 없습니다. 편집 기능을 넣지 않은 이유는 무엇입니까?

version-control svn

— 이상현
소스

의 이야기를 생각 나게 Dave.cpp thedailtywtf에

— 팔콘

git을 사용 하면 커밋을 병합하고 메시지를 편집하며 히스토리로 원하는 것을 수행 할 수 있습니다.

— SK-logic

또는 당신이 할 수 없다면, 사용 git-svn하고 아무도 더 현명 하지 않습니다 .

— Matthew Scharley

@ Matthew : git-svn으로 지구상에서 어떻게 역사 편집 비활성화 된 svn repo에서 역사를 바꿀 수 있습니까?

— gbjbaanb

@ gbjbaanb : SVN 서버로 이미 푸시했다면 그렇지 않습니다. 그러나 로컬로 커밋 한 경우에도 커밋 메시지를 라이브 리포지토리로 푸시하기 전에 변경할 수 있습니다.

— Matthew Scharley

답변:

SVN FAQ에 따르면 리포지토리 관리자가 활성화 한 경우 또는 리포지토리에 대한 로컬 관리 액세스 권한이있는 경우 가능합니다 .

그러나이 작업을 수행하는 것은 좋지 않습니다. 당신은 사실상 역사를 바꾸고 있습니다. 버전 관리의 요점 중 하나는 프로젝트의 기록 및 감사 내역을 유지하는 것입니다. 기록을 임의로 변경하면 감사 내역이 무효화됩니다. 대신 작은 커밋을 수행하고 간결하면서도 명시적인 커밋 메시지를 작성하고 이러한 오류를 방지하기 위해 개인 작업 흐름을 개선하는 것이 좋습니다.

— 토마스 오웬스
소스

@Matthew git에서도, 어떤 시점에서든 역사를 바꾸는 것은 끔찍한 생각입니다. 이력은 감사 추적의 역할을하므로 어떤 이유로 든 어느 누구도 변경해서는 안됩니다.

— 토마스 오웬스

커밋 메시지에 대한 감사 추적은 일반적으로 커밋 메시지를 변경하는 목적으로 프로젝트 히스토리를 보다 쉽게 추적 할 수 있도록 하기 때문 입니다.

— 피터 테일러

한 달 전에 입력 한 커밋 메시지가 오해의 소지가 있고 혼란스럽고 완전히 잘못되었다는 것을 발견했다고 가정 해 봅시다 . 잘못된 메시지를 보는 모든 사람이 볼 수있는 수정 표기법을 추가 할 수 없습니까? (나는 원본 메시지를 쉽게 수정할 수 있어야하며 변경 자체를 추적하고 타임 스탬프해야한다는 데 동의합니다. 그러나 이것이 "변경 기록"에 해당한다는 것에 동의하지 않습니다.

— David Schwartz

잘못된 정보는 용납 할 수 없으므로 사람들은 그 정보를 오용을 숨길 수 있으므로 해당 정보를 수정하거나 명확하게해서는 안됩니다. 와. 와우

— David Schwartz

당신은 정직하게 자기 패러디처럼 보이기 시작합니다. "정확해야하므로 절대로 수정해서는 안됩니다."

— David Schwartz

이를 위해서는 저장소에 대한 관리자 권한 (직접 또는 간접)이 있어야합니다. 모든 사용자가이를 수행 할 수 있도록 저장소를 구성하거나 서버에서 직접 로그 메시지를 수정할 수 있습니다.

여기 에서 SVN FAQ를 확인 하십시오.
로그 메시지는 각 개정에 첨부 된 특성으로 저장소에 보관됩니다. 기본적으로, 로그 메시지 특성 (svn : log)은 커밋 된 후에 편집 할 수 없습니다. 이는 svn : log가 1 인 개정 속성을 변경하면 속성의 이전 값이 영구적으로 삭제되고 Subversion이 실수로이를 수행하지 못하게하기 때문입니다. 그러나 Subversion이 개정 속성을 변경하도록하는 방법에는 두 가지가 있습니다.

첫 번째 방법은 저장소 관리자가 개정 특성 수정을 사용하는 것입니다. 이것은 "pre-revprop-change"라는 후크를 작성하여 수행됩니다 (이 작업을 수행하는 방법에 대한 자세한 내용은 Subversion 책의이 섹션 참조). "pre-revprop-change"후크는 이전 로그 메시지가 변경되기 전에 액세스 할 수 있으므로 어떤 방식 으로든 (예 : 이메일 전송) 보존 할 수 있습니다. 개정 속성 수정이 활성화되면 --revprop 스위치를 다음 중 하나와 같이 svn propedit 또는 svn propset에 전달하여 개정의 로그 메시지를 변경할 수 있습니다.
$svn propedit -r N --revprop svn:log URL 
$svn propset -r N --revprop svn:log "new log message" URL 
여기서 N은 로그 메시지를 변경하려는 개정 번호이고 URL은 리포지토리의 위치입니다. 작업 복사본 내에서이 명령을 실행하면 URL을 생략 할 수 있습니다.

로그 메시지를 변경하는 두 번째 방법은 svnadmin setlog를 사용하는 것입니다. 파일 시스템에서 저장소의 위치를 참조하여 수행해야합니다. 이 명령을 사용하여 원격 저장소를 수정할 수 없습니다.
$ svnadmin setlog REPOS_PATH -r N FILE
여기서 REPOS_PATH는 저장소 위치이고, N은 로그 메시지를 변경하려는 개정 번호이고, FILE은 새 로그 메시지를 포함하는 파일입니다. "pre-revprop-change"훅이 제자리에 있지 않은 경우 (또는 어떤 이유로 훅 스크립트를 생략하려는 경우) --bypass-hooks 옵션을 사용할 수도 있습니다. 그러나이 옵션을 사용하기로 결정한 경우 매우주의하십시오. 변경 사항에 대한 이메일 알림 또는 개정판 특성을 추적하는 백업 시스템과 같은 것을 무시할 수 있습니다.

Stack Overflow에 대한 비슷한 질문에 대한 답변으로 Kamil Kisiel 이 답변했습니다 .

— 아비 마란 쿠가 타산
소스

stackoverflow에서 답변을 붙여 넣을 때 적어도 견적으로 표시하고 OP (이 경우 Kamil Kisiel)에게 신용을 제공해야합니다. 원본 링크 : stackoverflow.com/questions/304383/… 답을 편집하십시오.

— 팔콘

중앙 집중식 버전 제어 시스템 이기 때문에 변경 사항을 커밋하면 (그리고 커밋 메시지는 커밋에 바인딩 된 규칙에 따라) 리포지토리에 대한 읽기 권한이있는 모든 사람이 해당 정보를 볼 수 있습니다. 사람들이 "현실"에 대한 의견이 다르기 때문에 정보가 보급 된 후에 정보를 변경하는 것은 나쁜 생각 입니다.

Git과 같은 분산 버전 제어 시스템은 다른 사람이 정보를 사용할 수있게하는 행위가 원자 적이며 커밋 메시지와 같은 추가 정보 없이도이 문제를 완화합니다. 그러나 동일한 원칙이 여기에 적용됩니다. 다른 사람이 이미 사용할 수있는 것을 현지에서 변경하지 않는 것이 좋습니다.

— l0b0
소스

그들은 여러 버전의 커밋 메시지를 허용 할 수있다.

— Alex Feinman

@ l0b0 허위, 오도 또는 손상을 입기 쉬운 정보를 계속해서 배포하는 것이 객관적으로 나쁘지 않습니까? 기록 보관에는 나쁜 데이터를 숨길 필요가 없습니다.

— user179700

@ user179700 : 네 말이 맞아. 내가 본 모든 VCS에는 근본적으로 결함이있는 설계 가정이있다. 커밋에는 하나의 커밋 메시지가 있는데, 이는 변경할 수 없다. Alex가 말했듯이 "여러 버전의 커밋 메시지를 허용해야한다".

— l0b0

@ l0b0이 질문은 내가 더 많이 고려할수록 흥미로워지고 있습니다. 나의 첫 반응은 그 라인을 따라 갔고, 더 신중하게 쓰십시오. 현재 관행은 그 과정을 방해하는 것 같습니다. 다른 시스템이 더 강력한 방법을 구현하는지 궁금합니다. 다른 질문에 대한 시간입니다. +1

— 179700

@ user179700 : 현재 커밋 메시지를 변경할 수있는 스크립트를 작성하려고하지만 (타임 스탬프) 추가 문자열 만 추가하면됩니다. 감사 추적을 유지하면서 실수를 바로 잡을 수 있습니다.

— Tynam