5년 동안 임대했던 전용서버의 마더보드가 고장나서 새것으로 교체해 주었습니다. 아주 오래된(Debian) 배포판은 마더보드의 모든 새 하드웨어를 따라잡을 수 없었기 때문에 새로운 배포판(Debian Wheezy)을 처음부터 다시 설치하기로 결정했습니다(오래된 Debian은 저한테는 잘 안되네요 제가 아는 한에는 새 메인보드의 이더넷 칩셋이 인식이 안되서 처음부터 다시 설치했습니다.
SVN을 다시 설치하고 다음을 수행하여 모든 저장소를 얻었습니다.
tar -xzf repoBackups.tgz
효과가있다".
문제는 Eclipse가 SVN 저장소를 인식하더라도 파일이 동일하더라도 모든 파일을 커밋하려고 한다는 것입니다.
이것이 파일의 타임스탬프와 관련이 있을 수 있습니까? 어느 쪽이든, 이 문제의 원인과 해결 방법을 알고 있습니까?
나할 수 있다모든 프로젝트에 대해 모든 파일을 다시 제출하도록 모든 사람에게 요청하면 모든 것이 괜찮을 것이라고 생각하지만 이러한 프로젝트 중 일부는 상당히 커서 개발자에게는 약간의 고통이 될 것입니다.
추가적인(그리고 덜 중요한) 질문: Git이나 Mercurial과 같은 다른 VCS는 이 문제로 인해 "고통"을 받지 않습니까?
답변1
Subversion 저장소의 파일 복사는 지원되는 백업 방법이 아닙니다. (바라보다[SVN]: 리포지토리를 어떻게 백업하나요?그리고Subversion 저장소를 백업하는 가장 좋은 방법은 무엇입니까?그리고원격 SVN 저장소를 백업하는 방법올바른 방법을 찾으십시오. ) 데이터베이스가 손상된 상태인 것 같습니다.
svnadmin dump압축을 푼 저장소와 svnadmin load결과 덤프 에서 실행해 보세요 . 이로 인해 작업 저장소가 생길 수 있습니다(그러나 약속은 없습니다. 저는 svn에 익숙하지 않습니다).
파일의 타임스탬프는 중요하지 않습니다. Subversion은 커밋 여부를 결정하는 데 이를 사용하지 않고 대신 개정 번호를 사용합니다.