Bogus file sizes in some remote repos

[mvf]

In #2, @vwbij reports that the file sizes reported by some SVN servers are bogus, breaking Total Commander's Synchronize Directories function. Local repositories are reported to not have this issue.

[vwbij]

I have done Investigations at the SVN board. They state that the file size reported in the client list callback is always a internal size in the repository. The "real" file size can be obtained using a local working copy. It has also something to do with the issue that a client can retrieve different kind of a single file (expand keywords, different line endings).

I have found one thing working. I create a temporary copy using apr_file_open, svn_stream_from_aprfile2 and svn_client_cat2. This file seems to have the correct size. I store this value in a CSV database, using the SVN URL together with the revision number as a key. It's a little bit ugly plumbing, but it seems to do the trick.

For me the ability to compare is very essential working with large trees, so this is better than have no chance to compare. At the moment I'm looking for bugs, then I try it with some repos to check it.

[mvf]

Well, that's certainly annoying. Especially since the Subversion docs state:

[...] the repository [...] does not pay attention to file contents. Subversion treats file contents as opaque strings of bytes, [...]

It might be possible to switch from svn_client_cat to svn_client_export5 [1] for retrieving files. Its ignore_keywords and native_eol parameters look like they allow the caller to deactivate the implicit processing. This should produce verbatim copies of repository contents with file sizes that always match those reported by svn_client_list2.

[1] https://subversion.apache.org/docs/api/1.8/group__Export.html#ga012408fea426f8bc283890fdad6f0b1c

[vwbij]

Thank you, a good Idea! And - as far as I can see - it does all magic inside one function, no need to do apr_file_open and svn_stream_from_aprfile2 before. I check it out!

[vwbij]

Thank you, it works! It seems to work at least as good as the svn_client_cat function, and it simplifies the code.