subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: svn_dirent_t::size: often not the "real" file size
Date Thu, 02 Feb 2017 16:32:51 GMT
On 02.02.2017 17:28, Branko ─îibej wrote:
> On 02.02.2017 15:52, Bijewitz, Volker wrote:
>> Hi Brane,
>>
>>>> Unfortunately I do not know if the user has got an working copy and
>>>> where it can be found . So the only way to solve this is creating once
>>>> a local copy of each file and store the real size in a DB referenced
>>>> by the file URL and revision number L.
>>> Why would you do that? You'd effectively have to check out the file in a
>>> Subversion working copy to get the correct size (or reimplement
>>> Subversion's end-of-line conversion and keyword expansion logic, which I'd
>>> not recommend).
>>>
>>> The size of the file in the repository is as real as any other size. As are
>> the
>>> contents. Does your plugin show file contents? If yes, does it perform
>>> keyword expansion and newline substitution, like the Subversion client
>>> would? If no, don't bother about tweaking the reported size.
>> Ok, the situation is the following. The left widow of my TC file manager is
>> feed by my plugin with the contents of a folder coming from SVN. The right
>> window points to a location on the harddisk - maybe the working copy, but
>> maybe not. Now I choose the fuction to compare/synchronize these "folders".
>> On the synchronize pane I want so see the files correctly marked as new,
>> identical or different. And in the plugin I have no access to the file list
>> on the other side. Now three situations can happen based on the settings:
>>
>> * Standard compare: does not work, date and time is generally different
>> * Ignore date/time: problem caused by incorrect size (comparing just file
>> sizes)
>> * Compare by contend: not supported for plugins :-(.
>>
>> So there is not any way to compare the content of a SVN repo with a folder on
>> disk that is not a working copy - it is not even possible as plugin to get
>> any info about the other side file/folder list.
>>
>> Yes, I show the contents of a file on demand, using a temporary file. I hope
>> I do it correctly. I do the following: 
>>
>> - apr_open_file
>> - svn_stream_from_aprfile2
>> - svn_client_cat2
>> - svn_stream_close
>>
>> I hope the file I created this way is identically to the file of a SVN
>> working copy. Do you now, are they?
>
> They are not. 'svn cat', or in your case calling svn_client_cat2(), will
> return the contents of the file in the repository. It will not perform
> keyword expansion or newline normalization. You need a working copy for
> that; svn_client_cat2() does not use a working copy.
>
> If you _do_ have a working copy, you'd compare the local file in the
> working copy with the repository version with svn_client_status6(), or
> svn_client_diff6(), both of which take irrelevant differences (i.e.,
> keyword expansion and newline normalization) into account.

In fact, the size of the file you get from svn_client_cat2() should be
exactly the same as the file size reported in the repository, regardless
of platform or file properties.

You should also be aware that svn_client_status and svn_client_diff
check for changes in file properties, not just contents; svn_client_cat
only returns the contents.


-- Brane

Mime
View raw message