Re: mailer.py commit says TypeError: must be unicode, not str

On Wed, Jan 31, 2018 at 10:40 PM, Kenneth Porter wrote: > --On Wednesday, January 31, 2018 7:23 PM -0800 Kenneth Porter > wrote: > >> fp = builtins.open(file, 'w+') # avoid namespace clash with >># trimmed-down svn_fs_open() > > > I'm now thinking the probl

Re: mailer.py commit says TypeError: must be unicode, not str

--On Wednesday, January 31, 2018 7:23 PM -0800 Kenneth Porter wrote: fp = builtins.open(file, 'w+') # avoid namespace clash with # trimmed-down svn_fs_open() I'm now thinking the problem is in the open call, and that I'm somehow getting a Python 3 open

Re: mailer.py commit says TypeError: must be unicode, not str

--On Tuesday, January 23, 2018 7:14 AM -0800 Kenneth Porter wrote: File "/usr/lib64/python2.7/site-packages/svn/fs.py", line 87, in _dump_contents fp.write(chunk) TypeError: must be unicode, not str Here's the code where this is going wrong. I think svn_stream_read is returning a by

Re: Building 1.8.19 from source tarball

Stefan Sperling wrote on Wed, 31 Jan 2018 16:58 +0100: > On Wed, Jan 31, 2018 at 10:45:07AM -0500, Nathan Hartman wrote: > > The get-deps.sh script that comes with the source tarball is fetching > > apr-1.4.6 and apr-util-1.5.1. There are newer versions available, > > namely apr-1.6.3 and apr-util-

Re: Building 1.8.19 from source tarball

On Wed, Jan 31, 2018 at 10:45:07AM -0500, Nathan Hartman wrote: > Hi all, > > I'm planning to update a Subversion server from 1.8.11 to 1.8.19. > > I'm building from the source tarball in order to run the test suites > of svn and its dependencies. > > The get-deps.sh script that comes with the s

Building 1.8.19 from source tarball

Hi all, I'm planning to update a Subversion server from 1.8.11 to 1.8.19. I'm building from the source tarball in order to run the test suites of svn and its dependencies. The get-deps.sh script that comes with the source tarball is fetching apr-1.4.6 and apr-util-1.5.1. There are newer versions

RE: Issue while loading the SVN Dump SVN version 1.9.7

Hi Johan, As you suggested I have removed the leading spaces from line 39 (enable-rep-sharing=false) and this time it worked and was able to successfully load the problematic revision. So does this conclude I have the sha-1 colliding files in my repo ? Also what are the next steps to catchup th

Re: Issue while loading the SVN Dump SVN version 1.9.7

On Wed, Jan 31, 2018 at 2:44 PM, Johan Corveleyn wrote: > On Wed, Jan 31, 2018 at 9:28 AM, Santosh Kondapuram > wrote: >> Hi Johan, >> >> Sorry for the delayed response as I was in long vacation. >> Yes, I don’t think we are hitting the real sha-1 collision in our repository >> and as you said i

Re: Issue while loading the SVN Dump SVN version 1.9.7

On Wed, Jan 31, 2018 at 9:28 AM, Santosh Kondapuram wrote: > Hi Johan, > > Sorry for the delayed response as I was in long vacation. > Yes, I don’t think we are hitting the real sha-1 collision in our repository > and as you said it might be another bug in the sha-1 collision detection code. > I

RE: Searching for a C++ API

> -Original Message- > From: Branko Čibej [mailto:br...@apache.org] > Sent: maandag 29 januari 2018 13:54 > To: users@subversion.apache.org > Subject: Re: Searching for a C++ API > > On 29.01.2018 11:45, R developer wrote: > > Hello all, > > > > I have been involved in writing a closed s

RE: Issue while loading the SVN Dump SVN version 1.9.7

Hi Johan, Sorry for the delayed response as I was in long vacation. Yes, I don’t think we are hitting the real sha-1 collision in our repository and as you said it might be another bug in the sha-1 collision detection code. I am sure that no one committed the sha-1-colliding files from https://