Mercurial 무시 된 파일 원인이 이전 버전으로 업데이트하려고 시도 할 때 중단합니다.

Question

여기에 제 시나리오가 있습니다. 처음에 Mercurial repo를 만들 때을 사용하여 모든 * .pl * .sh 및 * .sql 스크립트를 repo에 추가했습니다. 나중에 .hgignore 파일을 사용하여 repo에서 다른 파일을 제외하는 방법을 배웠습니다. 제외 할 파일 중 하나는 스크립트에 의해 생성 된 * .sql 파일 이었기 때문에 기본적으로 스크립트가 실행될 때 끊임없이 변경되는 데이터 파일입니다. 따라서 나는 몇 개정 전에 .hgignore 파일에 명시 적으로 추가했다.

오늘,이 .sql 파일이 .hgignore에 추가되기 전에 이전 개정판으로 업데이트하려고합니다. 따라서이 파일에서 분기를 만들 수 있습니다. 나는이 이전 버전으로 작업 디렉토리를 업데이트 할 때, 나는 다음과 같은 오류가 발생합니다 :

a.sql: untracked file differs abort: untracked files in working directory differ from files in requested revision

내가이 문제를 해결 얻을 수있는 한 가지 방법 업데이트하기 전에 파일을 삭제하는 것을 알고 이전 버전으로 수동으로 삭제하거나 hg update --clean --check을 사용하여

파일이 매번 스크립트에 의해 자동 생성되므로이 특정 경우에 작동 할 수 있습니다. 따라서 현재 그 파일에있는 데이터는 신경 쓰지 않습니다.

그러나 사람들이 일반적으로 자동 생성되지 않는 데이터 파일 집합과 같은 파일 집합을 무시하기로 결정할 때이 상황을 처리하는 안전한 방법은 무엇인지 알아 내려고합니다. 특히 Mercurial이 적극적으로 추적하는 파일의 이전 버전을 볼 수있는 동안 해당 파일 세트에서 최신 내용을 유지하려는 경우 이전 버전으로 돌아가서 무시하도록 표시하십시오.

나는 또한 파일을 백업 할 수 있다고 생각했지만, 이것이 일회용 인 경우 합리적인 해결책이라고 생각합니다. 자주 변경되는 경우 이전 버전의 hg update을 사용하려면 이전 버전으로 업데이트하기 전에 매번 데이터를 백업하는 것이 매우 지루합니다 (다른 사람이 삭제하지 않을 수있는 확실한 방법이 아닙니다) 레포에서 추적되지 않는 데이터).

도움 주셔서 감사합니다.

Answer 1

However, I'm trying to find out what is the safe way people would generally handle this situation when they decide to ignore a file set (like a set of data files that aren't auto-generated) and need to return to a previous revision before they were marked to be ignored, especially if they wanted to retain the most current content in those file sets while still being able to view earlier revisions of files that Mercurial is actively tracking.

에 달려 있습니다.

이 저장소를 독점적으로 제어 할 수 있고 모든 사람에게 다시 복제하도록 요구할 수 있다면 hg convert을 사용하여 이전 버전의 파일을 제외 할 수 있습니다. 이것은 훨씬 더 깨끗한 옵션이지만, 리비전 및 모든 위상 위상 자손에 대한 리비전 식별자 (해시)를 변경합니다. 이것이 모든 사람이 복제해야하는 이유입니다. 기존의 복제본은 새 저장소와 제대로 상호 작용하지 않습니다.

그럴 수 없다면 다른 곳에 파일을 복사하고 (이전에 이미 백업 했습니까?) 원본을 이전 버전으로 복제 한 다음 복사본에서 복원 할 수 있습니다. 이것은 파일을 검사 할 때마다 수행되어야합니다. 따라서 확실히 차선책입니다. 저장소 외부에 파일을 보관하고 파일에 대한 심볼릭 링크를 체크하면 파일을 약간 더 쉽게 만들 수 있지만 이전 버전을 체크 아웃 할 때마다 여전히 심볼릭 링크를 수정해야합니다.

그러나 설명하는 것은 Mercurial의 일반적인 사용 사례가 아닙니다. 일반적으로 추적 할 수없는 파일은 자동 생성되거나 최소한 추적 된 파일에서 다시 생성 할 수 있습니다. 작동하지 않는 파일은 중요하지 않으며 언제든지 폐기 될 수 있다는 가정이 있습니다.Mercurial은 무례 할 것이기 때문에 실제로 이것을하지는 않지만, (예를 들어) 저장소의 묶음을 만들 때 그것을 보존하기 위해 특별한 노력을하지도 않습니다.

오브젝트 파일의 버전 관리를 처리해야하는 경우, 일반적으로 오브젝트 파일을 별도의 아티펙트 저장소 또는 다른 시스템에 저장하는 것이 좋습니다. 빌드를 수행 할 때 소스 코드로 바이너리를 재결합해야하므로 관리가 더 어려울 수 있습니다. 하지만 바이너리를 저장소에 저장하지 않고 우연히 덮어 쓰거나 삭제하지 않기를 바라는 것보다 훨씬 강력합니다.

또 다른 옵션은 텍스트로 바이너리를 축소 한 다음 버전 제어하에 텍스트를 배치하는 것입니다. 항상 이 가능하고 파일 형식에 따라 실제로 또는 적절하지 않을 수도 있습니다 (예 : 16 진수 덤프 사용)입니다. 압축 된 파일 형식 (예 : 타르볼, 대부분의 이미지 파일 등)의 경우 hexdump는 원본 바이너리보다 3 방향 병합이 쉽지 않으므로 그 안에 작은 점이 있습니다. 마찬가지로 바이너리가 거대하면 헥스 덤프도 거대합니다. 반대로 소스 코드에서 바이너리를 컴파일하면 소스를 저장하고 바이너리를 삭제하는 것이 일반적입니다. SQLite 데이터베이스와 같은 구조의 경우, 데이터베이스를 생성 할 SQL 스크립트를 저장해보십시오. zip 파일 또는 tarball의 경우 내용을 저장하십시오. 등등. 체크 아웃 할 때마다 make 또는 유사한 도구를 사용하여 이러한 모든 작업을 다시 생성 할 수 있으며 repo hook을 사용하여 자동화 할 수 있습니다.