svndumpfilter crash on empty revisions

[Steven Barbaglia]

I am moving an SVN repository from one third-party remote server to a local one 
and I would like to remove empty revisions but svndumpfilter keeps crashing.  I 
first loaded the dump from svnradmin into a local repository and dumped it 
again.  I also tried with a dump that just includes the first few revisions, 
but svndumpfilter keeps crashing.  Some of the attempts include:

  svndumpfilter --drop-empty-revs --renumber-revs include / < svnadmin.dump > 
svndumpfilter.dump
  svndumpfilter include / < svnadmin.dump > svndumpfilter.dump
  svndumpfilter exclude junk < svnadmin.dump > svndumpfilter.dump

I am attaching the dump with just the first few revisions and a crash log.

PS I am using the latest public svn version, 1.9.5 from CollabNet for Windows 
64-bit.

-
Sinara provides software development services and software products to major 
financial sector clients. For 25 years, we have combined strong technical 
skills with a pragmatic and flexible approach to deliver and support reliable 
IT systems for a global client base.

http://www.sinara.com
mailto:i...@sinara.co.uk
+44 20 7940 7950

Disclaimer: This e-mail message (and any attachments) is confidential and may 
contain privileged information. It is for the intended recipient only. If you 
are not the intended recipient, you must not copy, distribute or use any of the 
information in it. If you receive this message in error please notify us as 
soon as possible and delete it. Copyright in this e-mail and attachments 
created by us belongs to Sinara Consultants Limited. Internet e-mails are not 
secure. Sinara does not accept responsibility for changes made to this message 
after it was sent. Should you communicate with anyone at Sinara by email you 
consent to us monitoring and reading any such correspondence.


svnadmin.dump
Description: svnadmin.dump


svn-crash-log20170202145451.log
Description: svn-crash-log20170202145451.log

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

[Branko Čibej]

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

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

[Branko Čibej]

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.

-- Brane

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

[Bijewitz, Volker]

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?

Thank you,

Volker

RE: Code baseline in apache subversion implementation

[Cooke, Mark]

There is a very good book online:-

http://svnbook.red-bean.com/

You will be able to answer your question (and lots more) by reading the book.

~ Mark C


From: Durgaprasad Potnuru [mailto:durgaprasad.potn...@iictechnologies.com]
Sent: 02 February 2017 07:10
To: users@subversion.apache.org
Cc: Raghunath Reddy Chinthala
Subject: Reg: Code baseline in apache subversion implementation


Dear users,

Could you guide if code can be base-lined in repositories implementing apache 
subversion.

Related documentation links or tutorials if available would be useful.





Warm Regards,

Durga Prasad
Disclaimer: This message, including any attachments, contains confidential 
information intended for a specific purpose, and is intended for the addressee 
only. Any unauthorized disclosure, use, dissemination, copying, or distribution 
of this message or any of its attachments or the information contained in this 
e-mail, or the taking of any action based on it, is strictly prohibited. If you 
are not the intended recipient, please notify the sender immediately by return 
e-mail and delete this message.

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

[Branko Čibej]

On 02.02.2017 11:30, Bijewitz, Volker wrote:
> 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

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

[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:b...@qqmail.nl] 
Gesendet: Donnerstag, 2. Februar 2017 10:39
An: Bijewitz, Volker; users@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:v.bijew...@baum.de] 
Sent: donderdag 2 februari 2017 09:22
To: users@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 : v.bijew...@baum.de

Internet: 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

 

 

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

[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:v.bijew...@baum.de] 
Sent: donderdag 2 februari 2017 09:22
To: users@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 : v.bijew...@baum.de  

Internet: 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

 

 

Re: Reg: Code baseline in apache subversion implementation

[Durgaprasad Potnuru]

thanks Cooke, Eric & Pavel.


That really helped.


Regards,

Durga Prasad


From: Pavel Lyalyakin 
Sent: 02 February 2017 13:51
To: users@subversion.apache.org
Cc: Raghunath Reddy Chinthala; Durgaprasad Potnuru
Subject: Re: Reg: Code baseline in apache subversion implementation

Hello,

On Thu, Feb 2, 2017 at 10:09 AM, Durgaprasad Potnuru 
>
 wrote:

Dear users,

Could you guide if code can be base-lined in repositories implementing apache 
subversion.

Related documentation links or tutorials if available would be useful.

Read SVNBook | Tags: 
http://svnbook.red-bean.com/en/1.8/svn.branchmerge.tags.html

--
With best regards,
Pavel Lyalyakin
VisualSVN Team
Disclaimer: This message, including any attachments, contains confidential 
information intended for a specific purpose, and is intended for the addressee 
only. Any unauthorized disclosure, use, dissemination, copying, or distribution 
of this message or any of its attachments or the information contained in this 
e-mail, or the taking of any action based on it, is strictly prohibited. If you 
are not the intended recipient, please notify the sender immediately by return 
e-mail and delete this message.

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 : v.bijew...@baum.de  

Internet: 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

 

 

Re: Reg: Code baseline in apache subversion implementation

[Pavel Lyalyakin]

Hello,

On Thu, Feb 2, 2017 at 10:09 AM, Durgaprasad Potnuru  wrote:

> Dear users,
>
> Could you guide if code can be base-lined in repositories implementing
> apache subversion.
>
> Related documentation links or tutorials if available would be useful.
>
Read SVNBook | Tags:
http://svnbook.red-bean.com/en/1.8/svn.branchmerge.tags.html

--
With best regards,
Pavel Lyalyakin
VisualSVN Team