Không thể đọc kích thước chunk. Lỗi trong SVN

Question

tôi đã phục hồi kho SVN từ máy tính bị rơi và bây giờ tôi có thể kiểm file từ vài thư mục nhưng ở một nơi trong thanh toán nó nói:

Error: REPORT of '/svn/RepTest/!svn/vcc/default': Could not read chunk size: 
Secure connection truncated (https://mypc:8443) 

bất cứ ai có thể giúp tôi, làm thế nào để sửa chữa kho đó? Cảm ơn!

Answer 1

tôi đã gặp vấn đề tương tự, tôi sử dụng TortoiseSVN và VisualSVN, vấn đề nằm trong một trong các cam kết của bạn, nhưng khó biết nó là cái gì, giải pháp cho tôi đã xóa và tạo kho lưu trữ trong VisualSVN rồi thực hiện cùng với "thư mục kiểm tra" trên máy tính của tôi, sau này, sao chép dự án vào thư mục và thực hiện "lần thứ hai cam kết" :) nhưng sẽ mất tất cả các cam kết trước đó.

Answer 2

Khi kiểm tra, tôi gặp lỗi tương tự. Vấn đề đã được thực sự với các phiên bản cụ thể, vì vậy tôi đã làm một workaround. Dường như các bản sửa đổi đã đưa ra lỗi có một đường dẫn dài. Một cái nhìn khác về các bản sửa đổi cụ thể khiến tôi nghĩ rằng nó có thể không cần phải được kiểm soát nguồn. Các tệp này được tạo tự động trên mỗi bản dựng. Tôi chỉ giữ một bản sao của toàn bộ thư mục trong thư mục 'Không được chấp nhận' và xóa các tệp/thư mục có vấn đề. Sau khi xóa, thanh toán đã được chấp nhận.

Answer 3

Tôi vừa gặp lỗi tương tự khi cố cập nhật thanh toán cho bản sửa đổi mới nhất. Một số khó khăn về tiết lộ rằng nó là một tập tin cụ thể gây ra vấn đề. Ví dụ:

root 
    - A 
    - AFileInFolderA.h 
    - AnotherFileInFolderA.h 
    - B 
    - AFileInFolderB.h 
    - C 
    - AFileInFolderC.h 

Với cấu trúc repo ở trên, AFileInFolderA.h là tệp sự cố. Tôi đã đi đến kết luận này bởi vì tôi có thể làm và svn update trong các thư mục B và C nhưng không phải trên root hoặc thư mục A. Khoan sâu hơn, tôi có thể cập nhật AnotherFileInFolderA.h nhưng không phải là vấn đề.

Dù sao, với những thông tin trong tay tôi sao chép của tôi thay đổi bản sao hoạt động từ thư mục A, sau đó (sử dụng Rùa SVN) đã làm một lựa chọn Cập nhật Để sửa đổi vào thư mục gốc, trừ thư mục A từ thanh toán của tôi. Sau đó tôi đã làm ngược lại, thêm lại thư mục vào thanh toán. Cuối cùng tôi đã thêm các thay đổi cục bộ của tôi trở lại và cam kết với repo. Tất cả hiện đang làm việc tốt.

Answer 4

tôi đã có lỗi tương tự gần đây:

BÁO CÁO của '/svn/.../!svn/vcc/default': Không thể đọc kích thước đoạn: Secure connection cắt ngắn.

Chúng tôi đang sử dụng Tortoise SVN và tôi là người duy nhất trong nhóm phát hành sự cố. Vì vấn đề không ngăn cản tôi thực hiện các thay đổi, tôi đã làm như vậy. Tiếp theo, tôi đã xóa thư mục với dự án khỏi ổ cứng của mình. Sau đó, tôi tạo ra nó một lần nữa và thực hiện một "SVN checkout".

Đây là những gì đã sửa cho tôi.

Answer 5

Đối với chúng tôi, sự cố bị thiếu tệp trong lịch sử SVN (có thể là hỏng đĩa). Bất kỳ thao tác nào bao gồm tệp có thay đổi gần đây nhất là từ phần bị thiếu trong lịch sử sẽ không thành công với lỗi "không thể đọc kích thước thư" hoặc lỗi XML không hợp lệ (tùy thuộc vào thao tác). May mắn thay chúng tôi đã có một bản sao lưu bao gồm các tập tin bị thiếu. Khôi phục chúng đã khắc phục được sự cố.

Answer 6

Tôi có vấn đề tương tự, mà 'svnadmin recovery' thực sự đã sửa chữa mọi thứ.

Trên một repo khác, nó sẽ không ... Sử dụng phiên bản SVN client (MacOSX) Tôi có thể thấy rằng tên người dùng cam kết của một số tệp trong thư mục không đúng là '### ERROR ###' - các thư mục này cho tôi sự cố "Đã ngắt kết nối an toàn" khi cập nhật. Chỉ cần 'di chuyển' các tệp đã đánh dấu này vào một thư mục khác và ngược lại (trên máy chủ, thông qua phiên bản SVN client), đủ để loại bỏ đánh dấu ### ERROR ### và cho phép cập nhật thành công.

Answer 7

Tuy nhiên, một câu trả lời bởi một ai đó với cùng một vấn đề, tuy nhiên với một giải pháp mà vẫn chưa được đề cập:

Trong trường hợp của tôi là vấn đề không thể được xác định chính xác vào một tập tin duy nhất. Tuy nhiên, nó đã được kết nối rõ ràng với một phiên bản svn duy nhất.

Giải pháp trong trường hợp này là bỏ qua tìm nạp bản sửa đổi xấu. Điều này có thể đạt được bằng cách gọi số git svn fetch với tùy chọn -r. Ví dụ, nếu r42 là phiên bản xấu, và bạn đã lấy tất cả các phiên bản lên đến r41, chỉ cần làm

git svn fetch -r43 

Tiếp theo

git svn fetch 

mang kho git của bạn được cập nhật. Tất nhiên, nhược điểm rõ ràng của cách tiếp cận này là lỗ hổng trong lịch sử mà bạn nhận được, nhưng tôi nghĩ tốt hơn là nên có một lỗ nhỏ trong lịch sử hơn là làm mà không có bản sao git svn đang hoạt động.