Mercurial 저장소 손상

이것은 이 질문 과 다소 관련 이 있지만 다른 질문입니다.

SSH 및 mercurial-server 를 통해 사용자에게 제공되는 중앙 Hg 저장소가 있습니다. 많은 Mac, Linux 및 Windows 클라이언트가 연결되어 있습니다.

Windows 사용자 중 하나가 저장소를 손상시킨 다음 중앙 저장소로 다시 밀어 넣어 두 번 발생했습니다. 중앙 리포지토리가 손상 될 경우 트랜잭션이 수락되지 않도록 중앙 리포지토리에 들어오는 후크 스크립트를 작성하려고합니다.

불행히도 나는 Mercurial이 그러한 스크립트를 작성하기에 충분하지 않습니다. 다른 사람이이 문제를 겪었을 가능성이 있습니까? 개인적으로 나는 왜 hg가 기본적으로 이것을하지 않는지 잘 모르겠습니다.

최신 버전의 Mercurial (1.5 이후)은 수신 데이터의 유효성 검사를 지원합니다. 더하다

[server]
validate = True

서버가 .hg/hgrc들어오는 데이터를 확인하고 유효하지 않은 푸시를 거부하도록 서버의 hg 구성 ( 또는 hgwebdir 구성이 제대로 작동해야 함)에 연결하십시오. 그러면 클라이언트는 다음과 유사한 오류를 보게됩니다.

remote: abort: missing file data for beta:dddc47b3ba30e54484720ce0f4f768a0f4b6efb9 - run hg verify

희망이 도움이됩니다!

어쩌면 저장소로 밀지 않아야합니다. Mercurial과 그 분산 된 특성으로 모든 사람이 지사를 가질 수 있으며 그들이 준비되었다고 느낄 때 그들은 당신에게 말하고 당신은 그들로부터 끌어냅니다. 커밋-액세스 문제도없고, 밀어 붙임도 없어서 ...

이것은 SVN에서 Mercurial로 마이그레이션 할 때 내 친구가 내게 준 조언입니다.

나는 이것이 당신에게 옵션 일지 모르겠지만, 모든 사람들을 위해 개인 저장소를 설정 한 다음 위험한 사람들을 잡으려고 노력하는 것보다 적은 노력이 필요할 수 있습니다.

David Herron의 블로그 와 동일한 작업 을 수행 할 수는 없지만 사전 라우팅에서 수행하는 대신 중앙 저장소의 사전 커밋 후크에서 수행합니까?

가능한 대안은 다음과 같습니다.

1. 푸시 후 저장소를 복제하십시오.
2. 그것을 확인하십시오.
3. 저장소가 양호하면 최신 저장소로 보관하십시오.
4. 리포지토리가 손상된 경우 경보를 발생시킵니다
5. 경보가 발생하면 가장 최근에 알려진 올바른 저장소를 복원하십시오.

이 솔루션은 필요한 것이 아니지만 최소한 손상이 발생한 경우 리포지토리를 롤백 할 수 있습니다.