예 : 수정 번호가 svn update 인 경우를 말하십시오. 이제 파일을 추가하고 커밋을 수행하면 svnversion은 혼합 된 버전으로보고합니다. 즉 10시 11 분. 그러나이 숫자들은 연속적이기 때문에 그 사이에는 다른 어떤 커밋도 분명히 존재하지 않습니다. Subversion은이 버전에서 최신 버전 (= HEAD)을 차감 할 수 없으므로이 혼합 버전을 제거하기 위해 다른 svn 업데이트를 실행할 필요가 없습니다.Subversion : 왜 개정 번호가 순차적 일 때 "혼합 개정"입니까?
나는 이것이별로 중요하지 않다는 것을 알고있다. 나는 위의 추론이 사실이 아닐 수도 있다는 특별한 경우를 놓치고 있는지 궁금합니다.
실제로 Subversion은 수정되지 않은 파일이 버전 11이라고 주장합니다. 다른 누군가가 버전 11을 커밋 한 경우 파일의 버전이 12 이상이됩니다.
이유는 로컬 서브 버전이 추가 파일이있는 버전이 완전히 버전 11이라고 주장 할 수 없다는 것입니다. 아직 확실하지 않기 때문입니다.
위의 설명을 시도한 시나리오는 아무도 내 "업데이트"와 나중의 "커밋"사이에 버전을 커밋하지 않았으며 버전 번호가 순차적이므로 서브 버전이이를 추론 할 수 있어야합니다. 물론 누군가가 저에게 무언가를 저질렀다면 버전 12 (또는 그 이상)를 얻을 것이고 "혼합 수정"상태는 정당화 될 것입니다. –
그러나 로컬 Subversion은 서버와 이야기하지 않고 다른 사람이 아무 것도 저 지르지 않았다는 것을 모릅니다. –
Commit을 할 때 로컬 Subversion이 서버와 통신하지 않는다는 말입니까? –
문제를 올바르게 이해했다면 작업 복사본에 거의 항상 혼합 버전이 있음을 알 수 있습니다. 이것은 서로 다른 파일이 서로 다른 버전으로 커밋되어 변경된 것이기 때문입니다. 일부 파일 (예 :)이 수정본 10 및 다른 파일 25를 표시하지만 아직 HEAD 개정판에 있다는 것을 알고 계셨습니까? 이것은 작업 공간에 파일 및 개정판에 대한 추가 메타 데이터가 들어 있기 때문입니다.
일반적으로이 문제는 전혀 문제가되지 않으며 SVN 워크 플로의 일부로 걱정됩니다. 나는 이것이 SVN 문서의 어딘가에서 설명되었지만 지금 당장은 찾을 수없는 것을 기억한다. 내가 그렇게하면 내 대답을 편집 할 것입니다.
필자는 실수로 새 파일을 커밋하여 "혼합 된 버전"상태를 만들었습니다. 그런 다음 다시 TortoiseSVN을 사용하고 일반적으로 프로젝트 루트에서 커밋 작업을 수행합니다. 어쩌면 그것은 전체가 최신이라고 생각할 수 있습니다. – Wormbo