Re: svn checkout/update fails with svn: Decompression of svndiff data failed: size too large error

2010-11-19 Thread Christian Unger

try this:
http://www.szakmeister.net/fsfsverify/


On 19.11.2010, at 07:04, Rajesh Menakath wrote:

> Hi,
>  
>   Recently we upgraded our svn server/client from 1.6.2 to 1.6.13, and since 
> then, we are encountering the following error when a user tries to 
> checkout/update a svn resource, where he has the required access (both read 
> and write).
>  
> svn: REPORT of '/svnrepository/!svn/vcc/default': 200 OK 
> (http://10.1.121.199) -> this was with http protocol, and found the below 
> errors in apache error logs:
>  
> [Tue Nov 16 19:57:07 2010] [error] [client 10.1.128.18] Provider encountered 
> an error while streaming a REPORT response.  [500, #0]
> [Tue Nov 16 19:57:07 2010] [error] [client 10.1.128.18] A failure occurred 
> while driving the update report editor  [500, #185005]
> [Tue Nov 16 19:57:07 2010] [error] [client 10.1.128.18] Decompression of 
> svndiff data failed: size too large  [500, #185005]
>  
> When I tried to do the same activity with svn protocol, I got the below error:
>  
> svn: Decompression of svndiff data failed: size too large
>  
> The weirdest part is that, it checks out the folder, but not the contents of 
> the folder, and then throws the error mentioned (for both svn and http 
> protocol).
>  
> When I tried to checkout all the files in the subjected folder, with the help 
> of svnlook (svnlook –r  cat repository_path 
> file_path > testfile), I got the same error for one of the file.
> svnlook: Decompression of svndiff data failed: size too large
>  
> I could re-produce the error with both command line svn client, and tortoise 
> svn and in both windows (xp service pack 3), and linux (RHEL5) environments. 
> As mentioned earlier, both of our client and server are 1.6.13.
>  
> Please confirm, if this is a bug or not, and suggest a way forward, and let 
> me know if you need any more info.
>  
>  
> Regards,
>  
> Rajesh
>  
>  
> 
> 
> This email is sent for and on behalf of Ivy Comptech Private Limited. Ivy 
> Comptech Private Limited is a limited liability company.
> 
> This email and any attachments are confidential, and may be legally 
> privileged and protected by copyright. If you are not the intended recipient 
> dissemination or copying of this email is prohibited. If you have received 
> this in error, please notify the sender by replying by email and then delete 
> the email completely from your system. Any views or opinions are solely those 
> of the sender.  This communication is not intended to form a binding contract 
> on behalf of Ivy Comptech Private Limited unless expressly indicated to the 
> contrary and properly authorised. Any actions taken on the basis of this 
> email are at the recipient's own risk.
> 
> Registered Office:
> 
> Ivy Comptech Private Limited, Cyber Spazio, Road No. 2, Banjara Hills, 
> Hyderabad 500 033, Andhra Pradesh, India.
> 
> Registered number: 37994. Registered in India. A list of members' names is 
> available for inspection at the registered office.
> 
> 
> 


--
christian unger • pferdeweide  47 • 22589 hamburg, germany
---
fon +49 16090987304
fon +49 4097073763 • fax +49 4097073765

aim christian_un...@mac.com
skype c_unger






svnsync and new auth realm

2010-11-29 Thread Christian Unger


so I have changed the authentication realm of my repository - this rather small 
change causes apache to make users re-authenticate against this realm.

now my buildbot triggered svnsync task fails because of this realm change - 
despite the fact that I tell it to always trust the server certs and friends - 
because I obviuosly have to also re-authenticate my sync task.

I understand that I could specify the credentials on the command line but I do 
hesitate because buildbot outputs the task's status to the log.

Is there a smarter way to let the sync'ed repository know how to authenticate 
against the source repository?


thx in advance
__
cu
christian unger









Re: Letters at beginnings of columns of svn output

2011-01-20 Thread Christian Unger

it's gone now :-)


On 20.01.2011, at 15:09, Ulrich Eckhardt wrote:

>>  For each merged item a line will be printed with characters reporting
>>  the action taken. These characters have the following meaning:
>> 
>>A  Added
>>D  Deleted
>>U  Updated
>>C  Conflict
>>G  Merged
>>E  Existed
>>R  Replaced
> 
> 
> What is "Existed"?
> 
> Uli
> 
> 
> -- 
> ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
> FAQ: http://subversion.apache.org/faq.html
> Docs: http://svnbook.red-bean.com/
> 
> 
> **
> Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
> **
> Visit our website at <http://www.dominolaser.com/>
> **
> Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
> bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
> Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
> sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
> weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
> E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
> Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht 
> verantwortlich.
> **
> 
> 


--
christian unger • pferdeweide  47 • 22589 hamburg, germany
---
fon +49 16090987304
fon +49 4097073763 • fax +49 4097073765

aim christian_un...@mac.com
skype c_unger






Re: detect externals in script

2010-06-23 Thread Christian Unger
doesn't `svn pget svn:externals` suffice? 

you probably want to look at subversion's bindings - depending on the scripting 
language you're using


On 23.06.2010, at 20:56, Paul Dugas wrote:

> I'm looking for a way for a script operating on a working directory to
> identify directories that were pulled in via an svn:external.  The
> script is in the top-level folder of the project and is used to
> maintain the common file headers for the project and I'd like it to
> not recurse down into externals.
> 
> Thanks in advance for suggestions,
> 
> Paul

__
cu
christian unger