RE: svnsync on large files

[Stümpfig , Thomas]

Hi Daniel,
you are a guru. I don't know why but it worked!

I guess the magic is in the difference of network transmission of svnsync vs 
svnrdump / svnadmin load

Are there suggestions from your side to avoid this error in the future?

Thank you very much for your help!!!

Regards
Thomas

-Original Message-
From: Daniel Shahaf [mailto:danie...@apache.org]
Sent: Donnerstag, 8. Dezember 2016 07:20
To: Stümpfig, Thomas (DF PL S DE PSM EAI) <thomas.stuemp...@siemens.com>
Cc: Pavel Lyalyakin <pavel.lyalya...@visualsvn.com>; users@subversion.apache.org
Subject: Re: svnsync on large files

Stümpfig, Thomas wrote on Wed, Dec 07, 2016 at 23:32:38 +:
> This is the situation of the starting point. (I restored)

The steps should be this:

f() {
  token="$USER@$(hostname):${RANDOM}:${RANDOM}"
  svn propset --revprop -r0 -- svn:sync-lock $token
  svn propget --revprop -r0 --strict svn:sync-lock | fgrep -q -- $token || 
return 1
  svn propset --revprop -r0 svn:sync-currently-copying 54618
  svnrdump dump -r54618 --incremental https://mysourceturl/repository >tmpfile
  svnadmin load /svnmirror/projektablage 

RE: svnsync on large files

[Stümpfig , Thomas]

Would you suggest the following command
svnsync initialize --allow-non-empty http://svn.example.com/svn-mirror \
   NEW-SOURCE-URL

?

-Original Message-
From: Pavel Lyalyakin [mailto:pavel.lyalya...@visualsvn.com]
Sent: Mittwoch, 7. Dezember 2016 18:59
To: Stümpfig, Thomas (DF PL S DE PSM EAI) <thomas.stuemp...@siemens.com>; 
users@subversion.apache.org
Subject: Re: svnsync on large files

Hello Thomas,

On Wed, Dec 7, 2016 at 8:54 PM, Stümpfig, Thomas <thomas.stuemp...@siemens.com> 
wrote:
>
> Hi everybody,
>
> i get an error with svnsync for large files. svnsync: E175002: REPORT
> request on


It seems to be only the first part of the error message. What's the full 
wording of the error?

>
> The rev to be synced is 2,291,973,385 Bytes large (Size in
> txn-protorevs directory. Of target mirror)
>
> The sync is with svn 1.9.5 (Visual SVN Server) over both https


You should use file:/// access to the local repository instead of HTTP(S). Here 
is an example:
[[[
svnsync sync "https://svn.example.com/svn/MyRepo;
"file:///C:/Repositories/MyRepo/"
]]]

Does the error occur when you use file:/// access to local repository?

> I tried to rdump, svnadmin load incremental (works) and adjust revprop info 
> in rev 0 to the new imported files. But the I got a path already exists for 
> following syncs.
> Might not be related to my manipulations but could be the case.
>
>
>
> Any Help is appreciated
>
>
>
> Mit freundlichen Grüßen
>
> Thomas Stümpfig
>
>
>
> Siemens Indusry Software GmbH
>
> Product Lifecycle Management
>
> Global Sales & Services
>
>
>
> Franz-Geuer Straße 10
>
> 50823 Köln
>
> Franz-Geuer-Straße 10
> 50823 Köln Tel.: +49 (2153 )9107117
>
> Fax.: +49 (221) 20802699
>
> Mobil: +49 (175) 2205 712
>
> thomas.stuemp...@siemens.com
>
> www.siemens.com/plm
>
>
>
> -
> Siemens Industry Software GmbH; Anschrift: Franz-Geuer-Str. 10, 50823
> Köln; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Urban
> August, Daniel Trebes; Sitz der Gesellschaft: Köln; Registergericht:
> Amtsgericht Köln, HRB 84564




--
With best regards,
Pavel Lyalyakin
VisualSVN Team
-
Siemens Industry Software GmbH; Anschrift: Franz-Geuer-Str. 10, 50823 Köln; 
Gesellschaft mit beschränkter Haftung; Geschäftsführer: Urban August, Daniel 
Trebes; Sitz der Gesellschaft: Köln; Registergericht: Amtsgericht Köln, HRB 
84564

RE: svnsync on large files

[Stümpfig , Thomas]

Hi guys
Thank you for your support.
Here is the full error message.

E:\svnbackup>svnsync sync --source-username=myusername --source-password=x  
--sync-username= myusername --sync-password=x https://mydesturl/repository  
https://mysourceturl/repository
Transmitting file data .svnsync: E175002: REPORT request on 
'/svn/projektablage
age/!svn/rev/54618' failed

(I modified the urls for infosec puposes ... )

E:\svnbackup>svn proplist --revprop -r 0 file:///E:/svnmirror/projektablage
Unversioned properties on revision 0:
  svn:date
  svn:sync-currently-copying
  svn:sync-from-url
  svn:sync-from-uuid
  svn:sync-last-merged-rev

E:\svnbackup>svn propget --revprop -r 0 svn:sync-currently-copying  
file:///E:/svnmirror/projektablage
54618

E:\svnbackup>svn propget --revprop -r 0 svn:sync-last-merged-rev  
file:///E:/svnmirror/projektablage
54617

E:\svnbackup>svn info -r HEAD file:///E:/svnmirror/projektablage
Path: projektablage
URL: file:///E:/svnmirror/projektablage
Relative URL: ^/
Repository Root: file:///E:/svnmirror/projektablage
Repository UUID: e75c21af-ffb9-1a4d-8d4e-43c49f6e0dd9
Revision: 54617
Node Kind: directory
Last Changed Author: xxx
Last Changed Rev: 54617
Last Changed Date: 2016-12-05 11:38:18 +0100 (Mon, 05 Dec 2016)


This is the situation of the starting point. (I restored)

Regards
Thomas

-Original Message-
From: Daniel Shahaf [mailto:danie...@apache.org]
Sent: Mittwoch, 7. Dezember 2016 23:09
To: Pavel Lyalyakin <pavel.lyalya...@visualsvn.com>
Cc: Stümpfig, Thomas (DF PL S DE PSM EAI) <thomas.stuemp...@siemens.com>; 
users@subversion.apache.org
Subject: Re: svnsync on large files

Pavel Lyalyakin wrote on Wed, Dec 07, 2016 at 20:59:24 +0300:
> On Wed, Dec 7, 2016 at 8:54 PM, Stümpfig, Thomas
> <thomas.stuemp...@siemens.com> wrote:
> >
> > The rev to be synced is 2,291,973,385 Bytes large (Size in
> > txn-protorevs directory. Of target mirror)
> >
> > The sync is with svn 1.9.5 (Visual SVN Server) over both https
>
>
> You should use file:/// access to the local repository instead of
> HTTP(S).

Why?  There are perfectly good reasons to use http://localhost/, for example, 
to have a one-stop-shop killswitch for disabling "everything"
from accessing the repository.

I'm guessing the dump/incremental-load/update-r0-revprops surgery went wrong.  
I would (a) double-check that the revision that had been manually synced did in 
fact sync correctly, (b) review the r0 revprops.
(Thomas: you can just post the 'proplist -v' here if you aren't sure whether 
it's correct now.)

Also, as Pavel says, we need the full error message.

Cheers,

Daniel

> Here is an example:
> [[[
> svnsync sync "https://svn.example.com/svn/MyRepo;
> "file:///C:/Repositories/MyRepo/"
> ]]]
>
> Does the error occur when you use file:/// access to local repository?
>
> > I tried to rdump, svnadmin load incremental (works) and adjust
> > revprop info in rev 0 to the new imported files. But the I got a
> > path already exists for following syncs.  Might not be related to my
> > manipulations but could be the case.
-
Siemens Industry Software GmbH; Anschrift: Franz-Geuer-Str. 10, 50823 Köln; 
Gesellschaft mit beschränkter Haftung; Geschäftsführer: Urban August, Daniel 
Trebes; Sitz der Gesellschaft: Köln; Registergericht: Amtsgericht Köln, HRB 
84564

svnsync on large files

[Stümpfig , Thomas]

Hi everybody,
i get an error with svnsync for large files. svnsync: E175002: REPORT request on

The rev to be synced is 2,291,973,385 Bytes large (Size in txn-protorevs 
directory. Of target mirror)
The sync is with svn 1.9.5 (Visual SVN Server) over both https

I tried to rdump, svnadmin load incremental (works) and adjust revprop info in 
rev 0 to the new imported files. But the I got a path already exists for 
following syncs.
Might not be related to my manipulations but could be the case.

Any Help is appreciated

Mit freundlichen Grüßen
Thomas Stümpfig

Siemens Indusry Software GmbH
Product Lifecycle Management
Global Sales & Services

Franz-Geuer Straße 10
50823 Köln
Franz-Geuer-Straße 10
50823 Köln Tel.: +49 (2153 )9107117
Fax.: +49 (221) 20802699
Mobil: +49 (175) 2205 712
thomas.stuemp...@siemens.com
www.siemens.com/plm


-
Siemens Industry Software GmbH; Anschrift: Franz-Geuer-Str. 10, 50823 Köln; 
Gesellschaft mit beschränkter Haftung; Geschäftsführer: Urban August, Daniel 
Trebes; Sitz der Gesellschaft: Köln; Registergericht: Amtsgericht Köln, HRB 
84564

RE: A couple thousand mp3 files (this is not spam I swear )

[Stümpfig , Thomas]

Hi,

While I fully agree with Stefan, I would like to mention that we use svn in a 
non-standard way. We think still with very good performance and use case 
coverage. It is not for source code. It is technical sales project management. 
Sharing all kind of doks jpegs,mp3,mp4,pdf,word,... We successfully have 
~3.000.000 Files in our repository. ~250 (commiters) ~1500 read only users 
since 2008.

We use tortoisesvn for most use cases. In addition to standard svn 
functionality, we created an SOLR based application for PowerPoint slide search 
and full text search.

The reasons to decide were:
a) SVN provides versioning (hey I am able to recover my presentation)
b) provides Path based authorization with Active Directory integration (as a 
large company we have to care about ip)
c) simple ui (tortoise) (even Sales can use it ;-))
d) checkout/check-in for offline usage is simple... (Good on customer site 
where we have no access to network)
e) Very good storage and network efficiency. (Good for home office/Hotel guys)
f) stable and reliable (we can use it 24/7 99% of the time)
g) active community (we can ask someone for help - and get it fast)
h) free and open source :-) - no compliance issues
i) multisite is supported, several multisite solutions exist.  But keep in mind 
svn is not a distributed scm tool. (we thought we might need it, but actually 
not implemented it, just for speed of recovery we have a 2nd server that 
mirrors the data)
j) updates were smooth we started with svn 1.3 - and are now on 1.9 (no big 
invest in upgrades ... my boss is happy)


SVN was the tool that fitted best the needs of our project teams. And even 
better we have 2 part time admin (~10% of the effective Time) for the system.

However,
Svn has some "weaknesses' you should be aware of. OOTB it is not trivial/fast 
to query a file by properties like in Typical DMS. Backing up such large 
repositories through a dump is not feasible. Other means like btrfs/lvm2 should 
be put in place. SVN OOTB does not provide persistent encryption. You could 
encrypt during a commit by 3rd party tools. Transport encryption (https) is 
supported. And finally I would like to add that svn is not a file system, 
despite the fact that svn provides webdav capabilities. As Stefan stated, it is 
a scm tool :-) and it does the job really well.


Regards
Thomas

-Original Message-
From: Stefan Sperling [mailto:s...@elego.de]
Sent: Donnerstag, 18. August 2016 09:46
To: Adam Jensen 
Cc: users@subversion.apache.org
Subject: Re: A couple thousand mp3 files (this is not spam  I swear 
)

On Wed, Aug 17, 2016 at 09:09:27PM -0400, Adam Jensen wrote:
> What I need (and what I think is generally needed) is a high-capacity,
> large-file repository with a focus on data integrity (mandatory audit
> trails), sophisticated access control (smart contracts (maybe
> blockchain based)), probably (almost certainly) an encrypted
> file-system, and distribution/replication (that is maybe torrent
> based). Files in this type of system might need to be deleted but they 
> wouldn't be revised.
> This would not be a revision management system.
>
> I'm not sure how much of Subversion could be used/leveraged to build
> such a system.

Indeed it won't. I believe you should use something else for this job.
Not tracking changes contradicts a core requirement SVN was built for.

> At a minimum, it seems like it would involve a project fork and
> serious gutting and refactoring of the code-base after rethinking the
> basic principles, specifying the new requirements, and devising the
> new architecture. (And definitely a name change ).

You're free to use our code in whatever way you wish.
And we're always open to patches, of course.

But keep in mind that the code base is 16 years old and widely deployed.
Adding new features was easy in the early stages of development but is getting 
increasingly hard because of growing complexity and very strict reliability 
requirements imposed by our user base.

And we can't sever our roots:
"""
Apache Subversion is a full-featured version control system originally designed 
to be a better CVS. Subversion has since expanded beyond its original goal of 
replacing CVS, but its basic model, design, and interface remain heavily 
influenced by that goal. Even today, Subversion should still feel very familiar 
to CVS users.
"""
http://subversion.apache.org/features.html

So if you're really going to write a new piece of software for this you'll be 
much happier starting a new project from scratch rather than using SVN as a 
base.

-
Siemens Industry Software GmbH; Anschrift: Franz-Geuer-Str. 10, 50823 Köln; 
Gesellschaft mit beschränkter Haftung; Geschäftsführer: Urban August, Daniel 
Trebes; Sitz der Gesellschaft: Köln; Registergericht: Amtsgericht Köln, HRB 
84564

RE: Update Error over VPN

[Stümpfig , Thomas]

Hi all,
i'll try to get a Wireshark extract that covers the error. The problem I have 
with it, is that Wireshark on the server will capture a huge amount of data. We 
have ~20-100 parallel updates on the server. I observed peaks with 250 http 
sessions. Capturing the interface for a long time will be difficult. (I am not 
very good with Wireshark capture filters). How can I produce a serf debug 
output? The platform is Windows Server 2008R2 with current Microsoft patches.  
I am not aware of the exact configuration of the network. Siemens is a big 
company, and the hardware over the WAN is also unknown to me. :-(. I am just 
the guy who cares about the svn server.


Regards
Thomas

-Original Message-
From: Bert Huijben [mailto:b...@qqmail.nl]
Sent: Dienstag, 10. März 2015 14:33
To: 'Alfred von Campe'
Cc: 'Branko Čibej'; Stümpfig, Thomas; users@subversion.apache.org; 'Nico 
Kadel-Garcia'
Subject: RE: Update Error over VPN



 -Original Message-
 From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
 Sent: dinsdag 10 maart 2015 13:59
 To: Alfred von Campe
 Cc: Branko Čibej; Stümpfig, Thomas; users@subversion.apache.org
 Subject: Re: Update Error over VPN

 On Tue, Mar 10, 2015 at 7:16 AM, Alfred von Campe alfred@von-
 campe.com wrote:
  I was going to chime in earlier, but something in Brane’s response
  finally put me over the edge.  We are having a very similar error
  when updating
 over
  VPN (the problem does not occur when in the office):
 
  Summary of conflicts:
Text conflicts: 1
  svn: E175002: REPORT request on '/hepd/Shelby/!svn/me’ failed

This error can be triggered (without further details) if our serf HTTP library 
decides to cancel the request... But for that it would need a good reason.

It would be very interesting to know what caused this... A network trace (or 
serf debug output) would be very valuable. What platform do you see these 
problems on?


In another somehow related case that I'm investigating (strict firewall over a 
VPN link) it really helped to switch to the Subversion 1.9 pre-beta version... 
It would be very interesting to know if this has the same effect for you.

Bert

-
Siemens Industry Software GmbH  Co. KG; Anschrift: Franz-Geuer-Str. 10, 50823 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

RE: Update Error over VPN

[Stümpfig , Thomas]

I forgot to mention, indeed, the full path in the error message indicates that 
large avi files were involved in the update operation.

-Original Message-
From: Alfred von Campe [mailto:alf...@von-campe.com]
Sent: Dienstag, 10. März 2015 15:59
To: Bert Huijben
Cc: Branko Čibej; Stümpfig, Thomas; users@subversion.apache.org; Nico 
Kadel-Garcia
Subject: Re: Update Error over VPN

Bert:

 This error can be triggered (without further details) if our serf HTTP 
 library decides to cancel the request... But for that it would need a good 
 reason.

 It would be very interesting to know what caused this... A network trace (or 
 serf debug output) would be very valuable. What platform do you see these 
 problems on?

The client and server are both running Linux: CentOS 6.6 with WANdisco V1.8.11 
binaries on the client and Red Hat 5.8 with compiled from source 1.7.5 binaries 
on the server.  How to I create a network trace and/or serf debug output?

 In another somehow related case that I'm investigating (strict firewall over 
 a VPN link) it really helped to switch to the Subversion 1.9 pre-beta 
 version... It would be very interesting to know if this has the same effect 
 for you.

I can ask the user to give this a try.  Do you have binaries for CentOS 6.6 
available?

Alfred
-
Siemens Industry Software GmbH  Co. KG; Anschrift: Franz-Geuer-Str. 10, 50823 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

RE: Copy and Reduce the size of SVn repos

[Stümpfig , Thomas]

Hi all
Actually splitting projects is not a solution to something that eliminates old 
data. Think of a project with one file only. Legally one might be forced to 
keep the file at least for 5 or 10 Years. But after this period the very same 
old revisions of the file must be destroyed because of other legal or 
contractual obligations. There is enough reason for final deletion of old data. 
I appreciate very much the work of open source programmers. And as a matter of 
fact we deal with svn's limitations as we use it with much success for our 
purposes.  Said this, one of the most wanted feature is obliteration.

Regards
Thomas

-Original Message-
From: Les Mikesell [mailto:lesmikes...@gmail.com]
Sent: Dienstag, 10. März 2015 23:37
To: Nico Kadel-Garcia
Cc: Branko Čibej; Subversion
Subject: Re: Copy and Reduce the size of SVn repos

On Sun, Mar 8, 2015 at 8:27 PM, Nico Kadel-Garcia nka...@gmail.com wrote:
 
 Heh, I have to ask, where did you find that doctrine? There's no such
 thing. It's all a lot more mundane: First, you have to get people to

 I've had to deal with that doctrine personally and professionally
 since first working with Subversion in 2006. It comes up again eveyr
 so often, for example in
 http://subversion.tigris.org/issues/show_bug.cgi?id=516 and is
 relevant to the original poster's request.

 There can be both software and legal reasons to ensure that the
 history is pristine and never forgets a single byte. But in most
 shops, for any lengthy project, *someone* is going to submit
 unnecessary bulky binaries, and *someone* is going to create spurious
 branches, tags, or other subdirectories that should go the way of the
 passenger pigeon.

 agree what obliterate actually means; there are about five meanings
 that I know of. And second, all five are insanely hard to implement
 with our current repository design (just ask Julian, he spent about a
 year trying to come up with a sane, moderately backwards-compatible 
 solution).

 -- Brane

 I appreciate that it's been awkward. The only workable method method
 now is the sort of svn export; svn import to new repo and discard old
 repo that I described, or a potentially dangerous and often fragile
 dump, filter, and reload approach that preserves the original URL's
 for the repo, but it's really not the same repo.

 It remains messy as heck. This is, in fact, one of the places where
 git or other systems's more gracious exclusion or garbage collection
 tools doe better. Even CVS had the ability to simply delete a
 directory on the main fileserver to discard old debris: it's one of
 the risks of the more database based approach of Subversion to
 managing the entire repository history.

Maybe it is time to change the request from 'obliterate' to _any_
reasonable way to fix a repository that has accumulated cruft.   And a
big warning to new users to put separate projects in separate repositories from 
the start because they are too hard to untangle later.  I've considered dumping 
ours and trying to split by project, but I'm not even sure that is possible 
because many were imported from CVS then subsequently moved to improve the 
layout.  So I can't really filter by path.

--
   Les Mikesell
 lesmikes...@gmail.com
-
Siemens Industry Software GmbH  Co. KG; Anschrift: Franz-Geuer-Str. 10, 50823 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

RE: Update Error over VPN

[Stümpfig , Thomas]

Hi Bert, All
a REPORT require on '/svn//!svn/me' failed  this is the only message my 
colleague is getting. Same message with command line tools ,
. Server side (VisualSVN) error cannot exactly be linked to the users action 
-perhaps this could be an enhancement to mod_dav_svn - send a transaction id in 
the http header and log it. The server Error very probably is: Error writing 
base64 data: APR does not understand this error code  [500, #620018] (We have 
~300 commits per day and many more reading operations.
The error occurs only in WAN circumstances, and only on large updates (2GB). 
In LAN environment everything is ok. The user in question has got a 100Mb/s 
DOCIS3.0 line IPV6 based IPV4 carrier grade nat accessing the companies network 
via juniper client.
 Meanwhile I read about apache timeout,... and set this to 1800 - 30min... I 
hope this fixes the issues  I'll keep this list informed


regards
Thomas

From: Bert Huijben [mailto:b...@qqmail.nl]
Sent: Sonntag, 8. März 2015 13:20
To: Stümpfig, Thomas; users@subversion.apache.org
Subject: RE: Update Error over VPN

Hi Thomas,

It is kind of hard to answer questions on what might have failed if you only 
post a specific part of a failure.

Usually the error would contain a lot more details, such as how it failed; 
possibly network related errors.  You just note that it failed... and then try 
to ask us why.

In general the Subversion client should have told you why, and then we might be 
able to help you resolve why it failed... Now the only thing we can do is note 
that it failed... Which is something you already knew.

The E0001234 codes provide valuable information and in many cases allow you to 
google for the result, but in many cases there are even more helpful hints in 
the error messages.

Bert


From: Stümpfig, Thomas [mailto:thomas.stuemp...@siemens.com]
Sent: zondag 8 maart 2015 10:12
To: Stümpfig, Thomas; 
users@subversion.apache.orgmailto:users@subversion.apache.org
Subject: RE: Update Error over VPN

Nobody has any suggestions? What are the influences on networkside other than a 
correct http(s)/tcp/ip transmission.
Where can I get info about timouts etc..

From: Stümpfig, Thomas [mailto:thomas.stuemp...@siemens.com]
Sent: Mittwoch, 4. März 2015 15:27
To: users@subversion.apache.orgmailto:users@subversion.apache.org
Subject: Update Error over VPN

Hi everybody,
we have a strange issue here with svn 1.8.11
upon svn update with we get a REPORT require on '/svn//!svn/me' failed

but only on a specific WAN connection.
With a lan connection everything is fine. Updates to the same working folder 
are ok.
The WAN connection is a Juniper VPN connection (ipsec, nat traversal 
compatible)  over a carrier grade nat internet connection.

Any idea what is going wrong here?

Regards
Thomas




-
Siemens Industry Software GmbH  Co. KG; Anschrift: Franz-Geuer-Str. 10, 50823 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

-
Siemens Industry Software GmbH  Co. KG; Anschrift: Franz-Geuer-Str. 10, 50823 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

-
Siemens Industry Software GmbH  Co. KG; Anschrift: Franz-Geuer-Str. 10, 50823 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

RE: Update Error over VPN

[Stümpfig , Thomas]

Nobody has any suggestions? What are the influences on networkside other than a 
correct http(s)/tcp/ip transmission.
Where can I get info about timouts etc..

From: Stümpfig, Thomas [mailto:thomas.stuemp...@siemens.com]
Sent: Mittwoch, 4. März 2015 15:27
To: users@subversion.apache.org
Subject: Update Error over VPN

Hi everybody,
we have a strange issue here with svn 1.8.11
upon svn update with we get a REPORT require on '/svn//!svn/me' failed

but only on a specific WAN connection.
With a lan connection everything is fine. Updates to the same working folder 
are ok.
The WAN connection is a Juniper VPN connection (ipsec, nat traversal 
compatible)  over a carrier grade nat internet connection.

Any idea what is going wrong here?

Regards
Thomas




-
Siemens Industry Software GmbH  Co. KG; Anschrift: Franz-Geuer-Str. 10, 50823 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

-
Siemens Industry Software GmbH  Co. KG; Anschrift: Franz-Geuer-Str. 10, 50823 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

Update Error over VPN

[Stümpfig , Thomas]

Hi everybody,
we have a strange issue here with svn 1.8.11
upon svn update with we get a REPORT require on '/svn//!svn/me' failed

but only on a specific WAN connection.
With a lan connection everything is fine. Updates to the same working folder 
are ok.
The WAN connection is a Juniper VPN connection (ipsec, nat traversal 
compatible)  over a carrier grade nat internet connection.

Any idea what is going wrong here?

Regards
Thomas




-
Siemens Industry Software GmbH  Co. KG; Anschrift: Franz-Geuer-Str. 10, 50823 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

Cannot commit files on one laptop but on an other

[Stümpfig , Thomas]

Hi All,
We have VisualSVN 2.5 Server and TortoiseSvn 1.8. We use path based 
authorization with Basic Authentication over Active Directory.

I have one colleague who has write access to the entire project.

On his Laptop, despite write access, he can't commit to some branches (403). 
Other branches Work fine.
He can update and switch revisions on these branches.

Doing the same commit operation with his credentials  on my Laptop works 
perfect.

We ran out of Ideas. (Cleanup, Reset Save Data, update)

Mit freundlichen Grüßen

Thomas Stümpfig
Senior Presales Consultant
Global Sales  Services
Product Lifecycle Management

Siemens Industry Sector
Siemens Industry Software GmbH  Co. KG
Franz-Geuer-Str. 10
50823  Cologne, Germany
Tel.  :+49 (2153) 9107117
Fax  :+49 (221) 20802 699
Mobile :+49 (175) 2205712
thomas.stuemp...@siemens.com
www.siemens.com/plm


-
Siemens Industry Software GmbH  Co. KG; Anschrift: Franz-Geuer-Str. 10, 50674 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

Fresh checkout shows modified files

[Stümpfig , Thomas]

Hi all,
for some directories I get modified working copies right after a fresh checkout.
This seems very strange to me. I do not get any error message. My Platform is 
Windows 7 64 Bit. I am using TortoiseSVN 1.8.1, Build 24570 - 64 Bit as client. 
Visual SVN as server. But also tortoise svn command line tools are producing 
the same results.

How can I start to debug? Network doesn't seem to be the issue. Am I right?

Mit freundlichen Grüßen

Thomas Stümpfig
Senior Presales Consultant
Global Sales  Services
Product Lifecycle Management

Siemens Industry Sector
Siemens Industry Software GmbH  Co. KG
Franz-Geuer-Str. 10
50823  Cologne, Germany
Tel.  :+49 (2153) 9107117
Fax  :+49 (221) 20802 699
Mobile :+49 (175) 2205712
thomas.stuemp...@siemens.com
www.siemens.com/plm


-
Siemens Industry Software GmbH  Co. KG; Anschrift: Franz-Geuer-Str. 10, 50674 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

RE: svn AD authentication

[Stümpfig , Thomas]

Hi Pavel,
most users use tortoisesvn. What are the drawbacks of NTLM, SSPI, for 
Tortoisesvn users? I read some articles about 401 errors etc...
Also, I do not have the AD under control and it would not be easy for me to ask 
for changes in the AD. Btw. we are using the free version of Visualsvn and I 
hope to be able to test 1.8rc2 soon.

Thomas Stümpfig
Global Sales  Services

Siemens Industry Sector
Siemens Industry Software GmbH  Co. KG
Franz-Geuer-Str. 10
50823  Cologne, Germany
Tel.  :+49 (2153) 9107117
Fax  :+49 (221) 20802 988
Mobile :+49 (175) 2205 712
thomas.stuemp...@siemens.com
www.siemens.com/plm

 -Original Message-
 From: Pavel Lyalyakin [mailto:pavel.lyalya...@visualsvn.com]
 Sent: Donnerstag, 23. Mai 2013 11:34
 To: Stümpfig, Thomas
 Cc: users@subversion.apache.org
 Subject: Re: svn AD authentication

 Hello Thomas,

  are using svn in our company and authenticate against Microsoft Active
  Directory. We are quite happy since years now.
 
  We are working worldwide and hence multi language. Some passwords may
  have german umlaut, $, and other characters.
 
  Users that have these characters in their passwords do not
  authenticate. Can anybody give me a hint where to start searching.
 
  (Apache, MS AD, OS).

 Non-ASCII symbols (e.g. '£', 'ü', 'ä' etc.) in password are not supported in 
 plain-
 text Basic Authentication. For details check this mailing list thread:
 http://mail-archives.apache.org/mod_mbox/subversion-
 users/201204.mbox/%3c87obqpxnis@stat.home.lan%3E

 In order to use special characters in passwords you should consider advanced
 authentication methods that do not store and transfer plain-text passwords
 over HTTP. As your network is based on Active Directory the solution would
 be to setup Single Sign-On / Integrated Windows AD authentication via
 Kerberos and/or NTLM.

 You may want to try VisualSVN Server Enterprise Edition that perfectly
 integrates in Active Directory and provides Single Sign-On out of the box
 without any additional configuration.

 Integrated Windows Authentication:
 http://www.visualsvn.com/server/features/windows-auth/#integrated
 VisualSVN Server Features list: http://www.visualsvn.com/server/features/

 Thank you.

 --
 With best regards,
 Pavel Lyalyakin
 VisualSVN Team
-
Siemens Industry Software GmbH  Co. KG; Anschrift: Franz-Geuer-Str. 10, 50674 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

svn AD authentication

[Stümpfig , Thomas]

Hi everybody,

we are using svn in our company and authenticate against Microsoft Active 
Directory. We are quite happy since years now.
We are working worldwide and hence multi language. Some passwords may have 
german umlaut, $, and other characters.
Users that have these characters in their passwords do not authenticate. Can 
anybody give me a hint where to start searching.
(Apache, MS AD, OS).

Thomas Stümpfig
Global Sales  Services

Siemens Industry Sector
Siemens Industry Software GmbH  Co. KG
Franz-Geuer-Str. 10
50823  Cologne, Germany
Tel.  :+49 (2153) 9107117
Fax  :+49 (221) 20802 988
Mobile :+49 (175) 2205 712
thomas.stuemp...@siemens.com
www.siemens.com/plm


-
Siemens Industry Software GmbH  Co. KG; Anschrift: Franz-Geuer-Str. 10, 50674 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

RE: SVN as DMS

[Stümpfig , Thomas]

Hi all,
we have svn through  tortoisesvn successfully running 4 Years for 110 Users / 
20 documents as DMS.

SVN is successful because
a) it provides History of Projects
b) it provides very good Offline Capabilities!
c) it is simple

one important characteristic about our guys is, that they work in different 
locations throughout Germany and are 50% out of office. So simple collaboration 
while being able to efficiently work offline is key for us.
An other key to the success was the fact that we were able to full text search 
in the Repository. SOLR/Lucene were at hands. 

regards
Thomas

 -Original Message-
 From: Geoffrey Myers [mailto:li...@serioustechnology.com]
 Sent: Mittwoch, 21. März 2012 12:36
 To: Phil Pinkerton
 Cc: Laura Mohiuddin; users@subversion.apache.org
 Subject: Re: SVN as DMS
 
 Check out 1mage.
 
 That is the number one followed by 'mage'
 
 It's not a typo.
 
 On 03/21/2012 07:20 AM, Phil Pinkerton wrote:
  SharePoint for documentation. As Subversion has no built-in search
  attribute so to speak, however there are 3rd party application that
  claim to search Subversion,
  but why go thorough all that. I here there have been substantial
  improvement is the SharePoint application.
 
  2 cents
 
  On Mar 14, 2012, at 12:32 PM, Laura Mohiuddin wrote:
 
  Dear Sir/Madam,
 
  My company IBCS-PRIMAX Software (BD) Ltd. (http://www.ibcs-primax.com
  http://www.ibcs-primax.com/) is looking to install a Document
  Management System for the organization. I suggested SVN, but the DMS
  should also come with a dashboard and search facilities. Is there any
  way that I can setup subversion to provide me with a dashboard and
  search facilities?
 
  Thank you for your kind cooperation
 
  Regards,
  --
  *Laura Mohiuddin***
  Manager, Marketing
  IBCS-PRIMAX Software (Bangladesh) Limited
  House # 51, Road # 10A, Dhanmondi R/A
  Dhaka - 1209, Bangladesh
  Web: http://www.ibcs-primax.com http://www.ibcs-primax.com/
 
 
 
 --
 Until later, Geoffrey
 
 I predict future happiness for America if they can prevent
 the government from wasting the labors of the people under
 the pretense of taking care of them.
 - Thomas Jefferson

RE: Permanent removal

[Stümpfig , Thomas]

There may be Companywide retention policies for Document archival. Working, 
Approved, Archived, Deleted. There might be cases where deletion is required by 
these policies. 

Dumpfilter is just a workaround for a new command and privilege (r,w,d). From 
what I can see, permanent delete Issues has already been discussed several 
times. AFAIK there is no plan to implement such a command. Please correct me if 
I am wrong. 


Regards
Thomas Stümpfig

 -Original Message-
 From: Cooke, Mark [mailto:mark.co...@siemens.com]
 Sent: Donnerstag, 12. Januar 2012 08:15
 To: sureshkumar nandakumar; users
 Cc: Sureshkumar.Nandakumar
 Subject: RE: Permanent removal
 
 Hello,
 
  -Original Message-
  From: sureshkumar nandakumar [mailto:suresh1256...@gmail.com]
  Sent: 12 January 2012 06:58
  Subject: Permanent removal
 
  Dear Expert,
 
 I'm not an expert, just another user...
 
  Our repository size are increasing on daily basis, we were planed and
  removed unused tags in SVN.
 
 Tags are very cheap copies that take hardly any space:
 http://svnbook.red-bean.com/en/1.7/svn.branchmerge.tags.html
 
  But still the size is not increased. And also whatever I have removed
  all those files are still persist in earlier version.
  Then there is no use of my removal.
 
 Correct.  deleteing stuff in subversion does not remove the data, just
 removes the items from subsequent revisions.  That is one of the main
 features of source code control...
 
  Suppose, I would like to do permanent removal in SVN, how can it
  possible and how to do permanent removal in SVN?
 
 You can dump the repository, run it through svndumpfilter and then reload
 the filtered dump into a new repository.
 
 http://svnbook.red-
 bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.tk.svn
 dumpfilter
 
 http://svnbook.red-
 bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.filteri
 ng
 
  If I do permanent removal, how I can take those files in case if it is
  require for future reference.
 
 Whilst filtering your dump, also create a different dump file with the stuff
 you don't want, then you can load it somewhere else in future if you want
 to.
 
  Please advise me  with good practice.
  Your suggestion is more use to me.
 
 Personally I chose to go the multiple-repository route from the start, 
 creating
 new repos under a parent path for all new projects.  This makes it a lot 
 easier
 to move stuff around (so long as the projects are not too intimately related,
 of course)...
 
 
 I have to say that I do not consider 100GB to be hugh these days (although
 disk prices have gone up somewhat recently due to the flooding in Thailand)
 but 1000GB disks are still relativley cheap?
 
 Hope that helps,
 
 ~ mark c

svn upgrade with dump/load

[Stümpfig , Thomas]

Hi all,
I plan to upgrade a 250GB Repository from 1.5 to 1.7. As I learned from other 
threads in this list, it is wise to dump and load the repository in order to 
bring everything to the latest features.
I have to keep the revision numbers and transaction dates.

Now svn dump and load offer some flexibility. And my server has 32GB Memory and 
16 Cores.
Now, in order to optimize the migration process would it be worth to split the 
dump into multiple dumps? And if yes, would you use delta dumps?


Thomas Stümpfig

AW: SVN File Size

[Stümpfig , Thomas]

Daniel,

nice url xy...

svn_ra_progress_notify_func_t: callback
Notification callback for network progress information.

it is not the progress I am looking for. It is an upfront information about the 
amount of data I am going to update before initiating the update. 

or is svn_ra_progress_notify_func_t doing this also?

Thanks
Thomas


 -Ursprüngliche Nachricht-
 Von: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
 Gesendet: Dienstag, 20. September 2011 14:20
 An: Stümpfig, Thomas
 Cc: users@subversion.apache.org
 Betreff: Re: SVN File Size
 
 http://s.apache.org/xy-problem
 
 See svn_ra_progress_notify_func_t.
 
 Daniel
 
 Stümpfig, Thomas wrote on Tue, Sep 20, 2011 at 09:55:09 +:
  Hi Daniel,
 
  The reason for file size in 'Svn log' would be to easily estimate the
 amount of an update operation. It is already in 'svn list' which helps
 for checkout and export. Let's assume you work offline for a week.
 Your colleague commits many jpg's, or tutorial avis to the
 documentation directory.
  You are unaware of this since you just update your project directory.
 If you're on a WAN bandwidth you will have to wait or interrupt, and
 probably svn cleanup. Things I do not really like.
  I agree, one could script around and produce deltas of 'svn list',
 but I would expect this in core. Sure it's not an obvious use case, but
 this would definitely help my guys to work smoother with svn.
 
  I still will have to convince TortoiseSVN to calculate filesize for
 directories in the Browser and in logsummery.
 
 
 
  With respect to the question of how to implement I would appreciate
 any input, since I am a newbie in svn programming.
 
  Regards
  Thomas
 
 
 
 
   -Ursprüngliche Nachricht-
   Von: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
   Gesendet: Dienstag, 20. September 2011 00:03
   An: Stümpfig, Thomas
   Cc: users@subversion.apache.org
   Betreff: Re: SVN File Size
  
   svn_ra_stat() does return the filesize, and it's the API that 'svn
   info'
   uses.  The next/prev links in the chain are svn_client_info3() and
   ra_svn_stat() (the latter is a file-private function in
 libsvn_ra_svn).
  
   So, yes, you're on the right path.  However, I knew all these APIs
   would
   exist, so I'm still where I was before: I'd like to know why the
   proposed new feature is generally useful enough to be included in
 the
   core, where it stands wrt 'svn log' and 'svn info', and how it
 would be
   implemented.
  
   In particular, implementing a protocol change involves a non-
 negligible
   amount of work (to revv four transports, client and server, plus
 compat
   code for old servers), while if it doesn't involve a protocol
 change
   the
   question is Why is a bindings script not a sufficient solution?.
  
   Stümpfig, Thomas wrote on Mon, Sep 19, 2011 at 21:33:11 +:
Hi all,
   
I found the following when examining the svnlook code
svn_fs_file_length where svn look gets the filesize. This is
   obviously the fs side function.
   
In /libsvn_ra_svn/protocol
I found the commands stat and log
   
stat contains a response token of size:number
log does not contain such a token
   
I then had a search for svn_ra functions in various header files.
 But
   I could not locate an ra api counterpart for svn_fs_file_length.
   
I cannot see if svn_ra_stat is providing filesize info, whilst
 being
   defined in /libsvn_ra_svn/protocol. (I hope I am interpreting this
   correctly) I neither can see if the server_side part encodes
 filesize
   information into the stream. Can somebody tell me where the answer
 is
   put into the stream?
   
   
Am I on the right path? Is this already subject to the Dev
   Mailinglist? This is my starting point of subversion coding.
   
Regards
Thomas
   
   
   
   
 ==
stat
params:   ( path:string [ rev:number ] )
response: ( ? entry:dirent )
dirent:   ( name:string kind:node-kind size:number has-
 props:bool
created-rev:number [ created-date:string ]
[ last-author:string ] )
   
   
===
   
   
   
log
params:   ( ( target-path:string ... ) [ start-rev:number ]
[ end-rev:number ] changed-paths:bool strict-
   node:bool
? limit:number
? include-merged-revisions:bool
all-revprops | revprops ( revprop:string ... ) )
Before sending response, server sends log entries, ending
 with
   done.
If a client does not want to specify a limit, it should send
 0 as
   the
limit parameter.  rev-props excludes author, date, and log;
 they
   are
sent separately for backwards-compatibility.
log-entry: ( ( change:changed-path-entry ... ) rev:number
 [ author:string ] [ date:string

AW: SVN File Size

[Stümpfig , Thomas]

Hi all,
First of all, I would like to thank you for your dedication to this issue
I would like to resume:

a) there is work on serverside in 1.7 that cares about file size
b) svnlook filesize makes use of it in 1.7
c) there might be issues related to svn:eol and svn:keywords
d) It is worth to create a ER for svn log

I will try to dig into the code and see if I am able to understand, the rough 
structure of it. 
Where should I look to, as a starting point? I am not anymore so fluent in C 
but I will try my best.
For sure I should know more details about the architecture, but I would like to 
concentrate on the part that 
deals with this one.

Regards
Thomas 



 -Ursprüngliche Nachricht-
 Von: Stefan Sperling [mailto:s...@elego.de]
 Gesendet: Freitag, 16. September 2011 10:43
 An: Stümpfig, Thomas; users@subversion.apache.org
 Betreff: Re: SVN File Size
 
 On Fri, Sep 16, 2011 at 10:31:05AM +0200, Stefan Sperling wrote:
  So what you're asking amounts to either a performance hit for 'svn
 log'
  or to a new feature in the filesystem (record the size of the full
  text of a file along with the changed-path data which 'svn log'
 reads).
 
 Ooops, I was wrong here, sorry. The expanded size of the full text is
 already recorded in the filesystem. As Johan pointed out, there is
 'svnlook
 filesize' which prints this number (which is stored in the FS, so there
 is no need to compute it). There wouldn't be a performance hit for 'svn
 log'.
 
 The below is still valid as-is:
 
  I think the feature you are requesting is reasonable.
  If you like, you can file an 'enhancement request' issue in our issue
  tracker about this. Maybe somebody will have time to work on it.
  (In case you know somebody who would like to work on this I'd like
  to point out that we're always happy to help newcomers get started :)

AW: SVN File Size

[Stümpfig , Thomas]

Hi all,

I found the following when examining the svnlook code
svn_fs_file_length where svn look gets the filesize. This is obviously the fs 
side function.

In /libsvn_ra_svn/protocol 
I found the commands stat and log

stat contains a response token of size:number
log does not contain such a token

I then had a search for svn_ra functions in various header files. But I could 
not locate an ra api counterpart for svn_fs_file_length.

I cannot see if svn_ra_stat is providing filesize info, whilst being defined in 
/libsvn_ra_svn/protocol. (I hope I am interpreting this correctly) I neither 
can see if the server_side part encodes filesize information into the stream. 
Can somebody tell me where the answer is put into the stream?


Am I on the right path? Is this already subject to the Dev Mailinglist? This is 
my starting point of subversion coding. 

Regards
Thomas



==
stat
params:   ( path:string [ rev:number ] )
response: ( ? entry:dirent )
dirent:   ( name:string kind:node-kind size:number has-props:bool
created-rev:number [ created-date:string ]
[ last-author:string ] )


===



log
params:   ( ( target-path:string ... ) [ start-rev:number ]
[ end-rev:number ] changed-paths:bool strict-node:bool
? limit:number
? include-merged-revisions:bool
all-revprops | revprops ( revprop:string ... ) )
Before sending response, server sends log entries, ending with done.
If a client does not want to specify a limit, it should send 0 as the
limit parameter.  rev-props excludes author, date, and log; they are
sent separately for backwards-compatibility.
log-entry: ( ( change:changed-path-entry ... ) rev:number
 [ author:string ] [ date:string ] [ message:string ]
 ? has-children:bool invalid-revnum:bool
 revprop-count:number rev-props:proplist
 ? subtractive-merge:bool )





 -Ursprüngliche Nachricht-
 Von: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
 Gesendet: Montag, 19. September 2011 13:41
 An: Stümpfig, Thomas
 Cc: users@subversion.apache.org
 Betreff: Re: SVN File Size
 
 Stümpfig, Thomas wrote on Mon, Sep 19, 2011 at 09:18:06 +:
  Hi all,
  First of all, I would like to thank you for your dedication to this
 issue
  I would like to resume:
 
  a) there is work on serverside in 1.7 that cares about file size
  b) svnlook filesize makes use of it in 1.7
 
 IIRC, in 1.7 svnlook simply exposed a long-existing FS API.
 
  c) there might be issues related to svn:eol and svn:keywords
 
 The FS returns the length of the repository-normal form, i.e., LF
 linefeeds and contracted keywords.
 
  d) It is worth to create a ER for svn log
 
 
 I'm not sure; where do you draw the line between 'svn log' and 'svn
 info'?
 
  I will try to dig into the code and see if I am able to understand,
 the rough structure of it.
  Where should I look to, as a starting point? I am not anymore so
 fluent in C but I will try my best.
  For sure I should know more details about the architecture, but I
 would like to concentrate on the part that
  deals with this one.
 
 
 First of all you should determine whether your patch needs to extend
 the
 wire protocol or not.  See subversion/libsvn_ra_svn/protocol or
 subversion/include/svn_ra.h
 
  Regards
  Thomas
 
 
 
   -Ursprüngliche Nachricht-
   Von: Stefan Sperling [mailto:s...@elego.de]
   Gesendet: Freitag, 16. September 2011 10:43
   An: Stümpfig, Thomas; users@subversion.apache.org
   Betreff: Re: SVN File Size
  
   On Fri, Sep 16, 2011 at 10:31:05AM +0200, Stefan Sperling wrote:
So what you're asking amounts to either a performance hit for
 'svn
   log'
or to a new feature in the filesystem (record the size of the
 full
text of a file along with the changed-path data which 'svn log'
   reads).
  
   Ooops, I was wrong here, sorry. The expanded size of the full text
 is
   already recorded in the filesystem. As Johan pointed out, there is
   'svnlook
   filesize' which prints this number (which is stored in the FS, so
 there
   is no need to compute it). There wouldn't be a performance hit for
 'svn
   log'.
  
   The below is still valid as-is:
  
I think the feature you are requesting is reasonable.
If you like, you can file an 'enhancement request' issue in our
 issue
tracker about this. Maybe somebody will have time to work on it.
(In case you know somebody who would like to work on this I'd
 like
to point out that we're always happy to help newcomers get
 started :)

SVN File Size

[Stümpfig , Thomas]

Hi all,
what is the reason that svn log does not tell me the actual file size. I would 
be more patient ;-), probably as a separate option or within -v
All I can find about in the net is a pre/or post commit that does a svnlook cat 
operation. But this is an expensive operation.
The Server should be able to deal with it during the commit operation.

regards
Thomas Stümpfig
Presales Knowledge Management

Siemens Industry Sector
Siemens Industry Software GmbH  Co. KG
Franz-Geuer-Str. 10
50823 Köln

Tel.:+49 2153 9107117
Mobil: +49 175 2205712
Fax.:   +49 221 248928

thomas.stuemp...@siemens.comjuergen.hasselb...@siemens.com
www.siemens.com/plm

Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858