svn_dirent_t::size: often not the "real" file size

[Bijewitz, Volker]

Hi SVN developers,



I am working on an TotalCommander plugin to browse SVN repositories. Now I
have the problem that on some repositories the filesize reported by
svn_client_list3 is different from the "real" file size of the working copy -
so comparing the SVN repo with the working copy is impossible. So here are my
questions on this issue:



· Is there a way for a SVN client to detect the "real" filesize?

· Does this behavior change with the server version? I have one
server where the filesize seems to match, another server where it does not
match.

· If there are servers that reports "real" file sizes: is there a
client functionality to detect if he is connected to a server with "good"
behavior?



This may be not the correct way to do a compare, there would be better ways
using the SVN interface. But I am limited to the TC plugin interface. And in
this interface there is no "Compare with file" function. I have just to
deliver the correct properties, and TC itself does the operation in a way the
user has configured it.



Cheers,



Volker Bijewitz



BAUM Systeme GmbH

Industriestr. 15

74909 Meckesheim





E-Mail : ***@baum.de <mailto:***@baum.de>

Internet: www.baum.de <http://www.baum.de/>





Geschäftsführer: Wolfgang Baum - Thomas Friehoff



Registergericht Mannheim, HRB 333567

Gerichtsstand: Heidelberg



VAT Nr: DE 143260354

IK 590820251



Bankverbindungen:

Commerzbank Heidelberg

IBAN: DE63 6724 0039 0193 5808 00

BIC: COBADEFFXXX

Postbank Karlsruhe

IBAN: DE40 6601 0075 0202 5007 54

BIC: PBNKDEFF

[Bert Huijben]

The size reported is the size of the file in repository form. The size might
be different when a different line end encoding is used and/or when keyword
expansion is enabled. (Can be larger or smaller)



svn_client_statusX() reports both sizes when the file is a ‘normal’ working
copy file.



The list function works 100% repository side and we simply don’t know the
size the file would be in some working copy, as the size might be different
in other working copies.



Bert



From: Bijewitz, Volker [mailto:***@baum.de]
Sent: donderdag 2 februari 2017 09:22
To: ***@subversion.apache.org
Subject: svn_dirent_t::size: often not the "real" file size



Hi SVN developers,



I am working on an TotalCommander plugin to browse SVN repositories. Now I
have the problem that on some repositories the filesize reported by
svn_client_list3 is different from the “real” file size of the working copy
– so comparing the SVN repo with the working copy is impossible. So here are
my questions on this issue:



* Is there a way for a SVN client to detect the “real” filesize?

* Does this behavior change with the server version? I have one
server where the filesize seems to match, another server where it does not
match.

* If there are servers that reports “real” file sizes: is there a
client functionality to detect if he is connected to a server with “good”
behavior?



This may be not the correct way to do a compare, there would be better ways
using the SVN interface. But I am limited to the TC plugin interface. And in
this interface there is no “Compare with file” function. I have just to
deliver the correct properties, and TC itself does the operation in a way
the user has configured it.



Cheers,



Volker Bijewitz



BAUM Systeme GmbH

Industriestr. 15

74909 Meckesheim





E-Mail : ***@baum.de <mailto:***@baum.de>

Internet: www.baum.de <http://www.baum.de/>





Geschäftsführer: Wolfgang Baum - Thomas Friehoff



Registergericht Mannheim, HRB 333567

Gerichtsstand: Heidelberg



VAT Nr: DE 143260354

IK 590820251



Bankverbindungen:

Commerzbank Heidelberg

IBAN: DE63 6724 0039 0193 5808 00

BIC: COBADEFFXXX

Postbank Karlsruhe

IBAN: DE40 6601 0075 0202 5007 54

BIC: PBNKDEFF

[Bijewitz, Volker]

Ok, thank you for explaining this. Yes, I understand that SVN is normalizing
the text files, so their real size may differ from client to client.



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.



Volker



Von: Bert Huijben [mailto:***@qqmail.nl]
Gesendet: Donnerstag, 2. Februar 2017 10:39
An: Bijewitz, Volker; ***@subversion.apache.org
Betreff: RE: svn_dirent_t::size: often not the "real" file size



The size reported is the size of the file in repository form. The size might
be different when a different line end encoding is used and/or when keyword
expansion is enabled. (Can be larger or smaller)



svn_client_statusX() reports both sizes when the file is a 'normal' working
copy file.



The list function works 100% repository side and we simply don't know the
size the file would be in some working copy, as the size might be different
in other working copies.



Bert



From: Bijewitz, Volker [mailto:***@baum.de]
Sent: donderdag 2 februari 2017 09:22
To: ***@subversion.apache.org
Subject: svn_dirent_t::size: often not the "real" file size



Hi SVN developers,



I am working on an TotalCommander plugin to browse SVN repositories. Now I
have the problem that on some repositories the filesize reported by
svn_client_list3 is different from the "real" file size of the working copy -
so comparing the SVN repo with the working copy is impossible. So here are my
questions on this issue:



· Is there a way for a SVN client to detect the "real" filesize?

· Does this behavior change with the server version? I have one
server where the filesize seems to match, another server where it does not
match.

· If there are servers that reports "real" file sizes: is there a
client functionality to detect if he is connected to a server with "good"
behavior?



This may be not the correct way to do a compare, there would be better ways
using the SVN interface. But I am limited to the TC plugin interface. And in
this interface there is no "Compare with file" function. I have just to
deliver the correct properties, and TC itself does the operation in a way the
user has configured it.



Cheers,



Volker Bijewitz



BAUM Systeme GmbH

Industriestr. 15

74909 Meckesheim





E-Mail : ***@baum.de

Internet: www.baum.de <http://www.baum.de/>





Geschäftsführer: Wolfgang Baum - Thomas Friehoff



Registergericht Mannheim, HRB 333567

Gerichtsstand: Heidelberg



VAT Nr: DE 143260354

IK 590820251



Bankverbindungen:

Commerzbank Heidelberg

IBAN: DE63 6724 0039 0193 5808 00

BIC: COBADEFFXXX

Postbank Karlsruhe

IBAN: DE40 6601 0075 0202 5007 54

BIC: PBNKDEFF

[Branko Čibej]

Post by Bijewitz, Volker
Ok, thank you for explaining this. Yes, I understand that SVN is normalizing
the text files, so their real size may differ from client to client.
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.

-- Brane

[Bijewitz, Volker]

Hi Brane,

Post by Branko Čibej

Post by Bijewitz, Volker
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

Post by Branko Čibej
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?

Thank you,

[Branko Čibej]

Post by Bijewitz, Volker
Hi Brane,

Post by Branko Čibej

Post by Bijewitz, Volker
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

Post by Branko Čibej
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
* 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
- 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.

-- Brane

[Branko Čibej]

Post by Branko Čibej

Post by Bijewitz, Volker
Hi Brane,

Post by Branko Čibej

Post by Bijewitz, Volker
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

Post by Branko Čibej
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
* 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
- 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