Re: Issue with SVN Checkout Due to Malformed XML Response

Den tis 10 sep. 2024 kl 22:20 skrev 耗子 : > Dear Subversion Development Team, > I hope this message finds you well. > I am encountering a critical issue when attempting to check out a specific > revision from the WordPress SVN repository. The command I used is: > > svn checkout

Issue with SVN Checkout Due to Malformed XML Response

Dear Subversion Development Team, I hope this message finds you well. I am encountering a critical issue when attempting to check out a specific revision from the WordPress SVN repository. The command I used is: svn checkout -r 2983085 https://plugins.svn.wordpress.org/acymailing-integration-for

Re: SVN issue - Repository - not able to login

Hello Daniel, We have checked from below link but not find the solution. If we create a new repository named as *Utilities *that repository is getting created but when user is trying to login that repository by using URL as - *svn://192.168.213.190/SVN/Utilities

Re: SVN issue - Repository - not able to login

Den mån 27 maj 2024 kl 14:50 skrev Roshan Pardeshi < roshan.parde...@ncdex.com>: > Hello Daniel, > > We are using below mentioned path for access in SVN through > TortoiseSVN->Repo Browser. > > svn://___.__.__.___(server ip)/SVN/aedge > So you are using svnserve. Can you double check your settin

Re: SVN issue - Repository - not able to login

Hello Daniel, We are using below mentioned path for access in SVN through TortoiseSVN->Repo Browser. svn://___.__.__.___(server ip)/SVN/aedge Regards,

Re: SVN issue - Repository - not able to login

Den tors 23 maj 2024 kl 18:03 skrev Roshan Pardeshi < roshan.parde...@ncdex.com>: > Hello Team, > > Please find the my input inline below. > > Which protocol are you using to access the repository? - Tortoise SVN - > Repo Browser > Are you using Apache/mod_dav_svn (http[s]://..), svnserve (sv

Re: SVN issue - Repository - not able to login

gt; Hi All, >> >> We are not getting Authentication window(using TortoriseSVN Repo Browser) >> after creating a new repository in SVN to access that repository >> >> Else if we are getting authentication window then after input of username >> and password of us

Re: SVN issue - Repository - not able to login

cation window then after input of username > and password of user its showing error message as "Authentication > failed" > > Requesting to please help on this issue. > > Below is the steps we are following to create repository > > Home path: /home/svnadmin >

SVN issue - Repository - not able to login

ailed" Requesting to please help on this issue. Below is the steps we are following to create repository Home path: /home/svnadmin # cd /SVN # svnadmin create YAALA (Repository Name: YAALA) Regards, <https://www.youtube.com/user/trustncdex> <https://twitter.com/ncdex> <

Re: Security issue Log4j

On Tue, Dec 14, 2021 at 11:51 AM Clemens, G. (Gijs) wrote: > > I have been contacted by my system administrator that there might be security > issues with Apache Subversion. The following files have been located on our > system: > > grails-plugin-log4j-2.4.4.jar > log4j-1.2.17.jar > tomcat-embed

Recall: Security issue Log4j

Clemens, G. (Gijs) would like to recall the message, "Security issue Log4j".

Recall: Security issue Log4j

Clemens, G. (Gijs) would like to recall the message, "Security issue Log4j".

Security issue Log4j

on our system are not on the list of fixed issues, I would kindly request your advise on how to proceed with this issue. Can we save delete the files without harming our system. Or is there a patch available which we can download? Kind regards, Clemens, G. (Gijs) __

Re: svn update issue?

On Fri, Sep 10, 2021 at 4:45 AM Mikael Stålhammar < mikael_stalham...@hotmail.com> wrote: > I'm wondering if the behavior of "svn update" is correct in this below > case: > > I have a file in my local working copy containing a change on one line in > the file. > Meanwhile the file is modified and

svn update issue?

I'm wondering if the behavior of "svn update" is correct in this below case: I have a file in my local working copy containing a change on one line in the file. Meanwhile the file is modified and committed by someone else, with a change to another line in that file. It turns out that that change

Re: svn authz error: Access denied issue when running svn rm resource where the user should be able to have full access

Grass/Grass01/skwnorp_2K_Normal.uasset' > >>> forbidden > >>> > >>> in apache logs i can see the following > >>> > >>> [Wed Jul 21 19:47:42.187161 2021] [authz_svn:error] [pid 1510:tid > >>> 140015597156096] [client 188.26.223

Re: svn authz error: Access denied issue when running svn rm resource where the user should be able to have full access

Hi Daniel, thank you for your response. i have tried to recreate customer issue in a test repo so that i dont expose customer name, i have created mostly same path structure to the uasset file and created same authz file in my repo authz file [groups] r_users = andrei [:glob:/] * = rw [:glob

Re: svn authz error: Access denied issue when running svn rm resource where the user should be able to have full access

gt;> >>> in apache logs i can see the following >>> >>> [Wed Jul 21 19:47:42.187161 2021] [authz_svn:error] [pid 1510:tid >>> 140015597156096] [client 188.26.223.19:42966] Access denied: >>> 'Alexander_Lost' DELETE >>> repo_name:/branches/proje

Re: svn authz error: Access denied issue when running svn rm resource where the user should be able to have full access

Daniel Shahaf wrote on Sat, Jul 31, 2021 at 00:41:48 +: > Now, the delete logic should request a *non* recursive access check if > the thing to be deleted is a plain file in HEAD. > subversion/libsvn_repos/commit.c:delete_entry() > does behave this way — when the .uasset path identifies a non

Re: svn authz error: Access denied issue when running svn rm resource where the user should be able to have full access

> > [:glob:/**/Source/**] > > @r_users = > > Do you know what versions are you using for the server and for the client? > > There is an issue with the authorization rules in versions 1.10.0 until > 1.14.0, fixed in 1.10.7 and 1.14.1. I'm not sure if

Re: svn authz error: Access denied issue when running svn rm resource where the user should be able to have full access

[dev@: tl;dr: mod_authz_svn shouldn't require svn_authz_recursive access on DELETE when the target is a file] Andrei Cusnir wrote on Wed, Jul 21, 2021 at 21:58:04 +0200: > Hi, > here is my authz config file > > [groups] > r_users = Alexander_Lost > > [:glob:/] > * = rw > > [:glob:/**/*.uasset]

Re: svn authz error: Access denied issue when running svn rm resource where the user should be able to have full access

3.19:42966] Access denied: >> 'Alexander_Lost' DELETE >> repo_name:/branches/project_name/Projects/ShooterGame/Content/Mods/project_name/Assets/Foliage/Trees/StepeeGrass/Grass01/skwnorp_2K_Normal.uasset >> >> >> Please let me know if this is a config error or

Re: svn authz error: Access denied issue when running svn rm resource where the user should be able to have full access

' DELETE > repo_name:/branches/project_name/Projects/ShooterGame/Content/Mods/project_name/Assets/Foliage/Trees/StepeeGrass/Grass01/skwnorp_2K_Normal.uasset > > > Please let me know if this is a config error or it is an authz bug. > Do you know what versions are you using for the

svn authz error: Access denied issue when running svn rm resource where the user should be able to have full access

Hi, here is my authz config file [groups] r_users = Alexander_Lost [:glob:/] * = rw [:glob:/**/*.uasset] @r_users = rw [:glob:/**/Source/**] @r_users = user Alexander_Lost should be able to work with uasset type of files and should not see anything that has Source in the global path when i

Re: [ISSUE] Cancelling svn checkout leaves an open file handle

es lifetime of various resources — primarily memory, but also file handles — via the apr_pool_t abstraction. Nearly every API function takes at least one pool parameter. Given that you mentioned closing the TortoiseSVN window is a valid workaround for that version of the issue, I guess the file handl

Re: [ISSUE] Cancelling svn checkout leaves an open file handle

Hi Daniel, Not sure what are "relevant pools", I am not really too familiar with SVN :) Attached below is a minimal reproduction case. It is a C# winforms app with Check and Cancel button (.NET 4.8 with SharpSvn 1.9 x64 nuget) You would just need to type in some real svn repo address in Form1.cs

Re: [ISSUE] Cancelling svn checkout leaves an open file handle

Uroš Jovanović wrote on Mon, 07 Sep 2020 19:25 +0200: > when using SharpSvn in context of a larger > application, this would mean the user needs to close the entire application > because one unmanaged file handle was left alive. Have you tried clearing the relevant pools? Could you help debugging

[ISSUE] Cancelling svn checkout leaves an open file handle

Hello, Recently I came across this behaviour where if I use the Cancel API to cancel a long running checkout operation, the process running the SVN code leaves an open file handle in the .svn\tmp folder inside the working copy. Initially, I thought it was a SharpSvn (1.9 x64) issue, but I

Re: SVNSYNC issue with user

Andreas Stieger wrote on Fri, 13 Mar 2020 11:45 +00:00: > Hello, >   > > > “svnsync init --allow-non-empty --username abcd file:///u03/svn/repos > > svn://xxx.xxx.xxx.xxx/” > [...] > > svnsync: E165001: Revprop change blocked by pre-revprop-change hook (exit > > code 1) with output: > > Changing

Re: SVNSYNC issue with user

Hello,   > “svnsync init --allow-non-empty --username abcd file:///u03/svn/repos > svn://xxx.xxx.xxx.xxx/” [...] > svnsync: E165001: Revprop change blocked by pre-revprop-change hook (exit > code 1) with output: > Changing revision properties is not permitted, the user used is klnm When running

SVNSYNC issue with user

Hi In our organization we have one svn Master node and one slave node. By using crontab we are doing svnsync in regular intervals, but from few days onwards sync is not happening properly. While initializing we are used below command and user name is abcd. "svnsync init --allow-non-empty --user

Re: Reg: SVN subversion checkout issue in ubuntu

ve the -q option from 'ssh' > in the [tunnels] section of your Subversion configuration file. > Did you try this step of removing the -q option? What shows up on the command line? Eric. > Network connection closed unexpectedly > > I tried lot of ways from the forums to get ou

Reg: SVN subversion checkout issue in ubuntu

7;svn+ssh://DOMAIN/SVN_PATH' To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file. Network connection closed unexpectedly I tried lot of ways from the forums to get out from this issue. But sadly i c

Fwd: Re: Possible issue: Out of date output from svn help remove

Thanks, Branko. I was wrong. Sent using the mail.com mail app Forwarded email > From: "Branko Čibej" > Date: 18 April 2019 at 17:30 > To: users@subversion.apache.org > Subject: Re: Possible issue: Out of date output from svn help remove > > On 18.04.2019 18:17, Ric

Re: Possible issue: Out of date output from svn help remove

On Thu, Apr 18, 2019 at 12:30 PM Branko Čibej wrote: > On 18.04.2019 18:17, Richard Cavell wrote: > > Hello. I believe that the output of svn help remove on my machine is > > out of date. It says that each item is scheduled for deletion. But > > this has been changed over the years as subversi

Re: Possible issue: Out of date output from svn help remove

On 18.04.2019 18:17, Richard Cavell wrote: > Hello.  I believe that the output of svn help remove on my machine is > out of date.  It says that each item is scheduled for deletion.  But > this has been changed over the years as subversion has evolved.  Now, > the item is deleted right away. That i

Possible issue: Out of date output from svn help remove

Hello.  I believe that the output of svn help remove on my machine is out of date.  It says that each item is scheduled for deletion.  But this has been changed over the years as subversion has evolved.  Now, the item is deleted right away.  I'm not able to build svn on my current machine so I'm u

Re: Issue with binaries generated(subversion 1.10.2) after compilation on AiX 7.2

Prannoy K.v wrote on Fri, 28 Dec 2018 05:53 +: > > Hi Daniel, > Thank you for your help. I wanted to know if I am doing any mistake > during compilation or is it an Issue with AiX or Subversion ? Did you see the comment in the source code I referred you to? I'm gues

Re: Issue with binaries generated(subversion 1.10.2) after compilation on AiX 7.2

Hi Daniel, Thank you for your help. I wanted to know if I am doing any mistake during compilation or is it an Issue with AiX or Subversion ? If it is an issue with AiX and Subversion is it resolved in 1.10.3 or any other versions ?  Thanks and Regards,Prannoy K VOn Thursday, 27 December

Re: Issue with binaries generated(subversion 1.10.2) after compilation on AiX 7.2

Daniel Shahaf wrote on Thu, Dec 27, 2018 at 15:04:09 +: > In subversion/libsvn_subr/io.c, in svn_io_file_flush_to_disk(), there's > an APR_STATUS_IS_EINVAL() check. Try making it check > APR_STATUS_IS_EBADF() as well and handle it the same way (assuming "Bad > file number" is strerror(3) of EB

Re: Issue with binaries generated(subversion 1.10.2) after compilation on AiX 7.2

Prannoy K.v wrote on Thu, 27 Dec 2018 13:35 +: > Hi Team,  > I tried compiling subversion 1.10.2 on AiX 7.2 machine . Note that 1.10.3 has been released. > After "make" command generated binaries work well in the folder where it > is generated, whereas if we move binaries to a different loca

Issue with binaries generated(subversion 1.10.2) after compilation on AiX 7.2

Hi Team,  I tried compiling subversion 1.10.2 on AiX 7.2 machine . My configure command is as follows :-  ./configure CFLAGS="-I/home/lroot/temp_mod1/subversion/zlib" --without-berkeley-db --with-apr=/home/lroot/temp_mod1/subversion/apr --with-apr-util=/home/lroot/temp_mod1/subversion/apr-util

Re: 答复: a issue of --include' and '--exclude' options on 'svnadmin dump'

钱海远(Nathan) wrote on 2018-12-03: > I can help you to test it. Thank you. Can you help write the regression test for it, by extending the existing test? - Julian > >> if I copy a non-include file, the dump result is to add a file with file > >> content; > >> But if the copy is a non-include d

答复: a issue of --include' and '--exclude' options on 'svnadmin dump'

.org] 发送时间: 2018年11月30日 18:06 收件人: 钱海远(Nathan) 抄送: Subversion; Johan Corveleyn 主题: Re: a issue of --include' and '--exclude' options on 'svnadmin dump' Johan Corveleyn wrote on 2018-10-16: > On Tue, Oct 16, 2018 at 11:56 AM 钱海远(Nathan) > wrote: >> During

Re: a issue of --include' and '--exclude' options on 'svnadmin dump'

Johan Corveleyn wrote on 2018-10-16: > On Tue, Oct 16, 2018 at 11:56 AM 钱海远(Nathan) > wrote: >> During I am testing the -include' and '-exclude' options on 'svnadmin dump'  >> ,  I found >> that if I copy a non-include file, the  dump result is to add a file with >> file content; >> But if the

Re: Filesystem corrupt issue in repo

On Wed, Nov 7, 2018 at 2:05 PM Dennis Jakobsen wrote: > > Hi, > > I have a repo that returns no errors with 'svnadmin recover' or > 'svnadmin verify', but dumping and loading into a new repo gives me: > svnadmin: E160004: Filesystem is corrupt > svnadmin: E200014: Checksum mismatch while reading r

Filesystem corrupt issue in repo

Hi, I have a repo that returns no errors with 'svnadmin recover' or 'svnadmin verify', but dumping and loading into a new repo gives me: svnadmin: E160004: Filesystem is corrupt svnadmin: E200014: Checksum mismatch while reading representation:    expected:  aa2f4b4990d8a287d104dd30ddf50ab0    

Re: a issue of --include' and '--exclude' options on 'svnadmin dump'

diffcount > > Node-kind: dir > > Node-action: add > > Prop-content-length: 10 > > Content-length: 10 > > > > PROPS-END > > > > In fact, the copy directory has many files. But the dump file is only add > a new dir. > > > --

a issue of --include' and '--exclude' options on 'svnadmin dump'

Dear Sir, During I am testing the -include' and '-exclude' options on 'svnadmin dump' , I found that if I copy a non-include file, the dump result is to add a file with file content; But if the copy is a non-include directory, the dump only adds this directory. I think, this may be wrong, i

Re: SVN checkout speed issue

On 31.07.2018 00:56, Art Hatch wrote: > Hi Team! > > We think there may be a bug, or a feature we don't understand: > > When checking out a repository using TortoiseSVN on top of a Visual > SVN Server v3.6, running on Windows Server 2012R2, we notice that > files with a mime type set (usually appli

Re: SVN patch issue with property changes

Summary of conflicts: > Property conflicts: 1 > root@contrail-ubm-dipuh:/tmp/tests# svn diff xpathleak.py > root@contrail-ubm-dipuh:/tmp/tests# You should probably find all files that have svn:executable set to empty and change the property's value to "*", and commit that.

Re: SVN patch issue with property changes

Philip Martin wrote on Thu, Jun 28, 2018 at 16:19:30 +0100: > The normalization of svn:executable values is implemented in the client. > If some client chooses not to implement that normalization the backend > will store any value given. > > Should the svn client silently merge '' and '*' for svn:

Re: SVN patch issue with property changes

m confused, you are treating as '' special? Suppose an existing >>>> property P has value 'foo'. Should a patch that adds P with value 'bar' >>> The issue is about a patch that *changes* the current value to another >>> value, not a pa

Re: SVN patch issue with property changes

>>>>> this form, that tries to change a property value from empty to >>>>> non-empty. >>>> I committed a test for this in http://svn.apache.org/r1834628 >>> I'm confused, you are treating as '' special? Suppose an existing >>>

Re: SVN patch issue with property changes

y to >>>> non-empty. >>> I committed a test for this in http://svn.apache.org/r1834628 >> I'm confused, you are treating as '' special? Suppose an existing >> property P has value 'foo'. Should a patch that adds P with value 'bar

Re: SVN patch issue with property changes

Julian Foad writes: > The issue is about a patch that *changes* the current value to another > value, not a patch that *adds* a property. Yes, sorry. I misinterprted the patches. -- Philip

Re: SVN patch issue with property changes

ommitted a test for this in http://svn.apache.org/r1834628 > > I'm confused, you are treating as '' special? Suppose an existing > property P has value 'foo'. Should a patch that adds P with value 'bar' The issue is about a patch that *changes* the cur

Re: SVN patch issue with property changes

Julian Foad writes: > Julian Foad wrote: >> The bug seems to be that 'svn patch' fails to apply any patch of >> this form, that tries to change a property value from empty to >> non-empty. > > I committed a test for this in http://svn.apache.org/r1834628 I'm confused, you are treating as '' spe

Re: SVN patch issue with property changes

Julian Foad wrote: > The bug seems to be that 'svn patch' fails to apply any patch of this form, > that tries to change a property value from empty to non-empty. I committed a test for this in http://svn.apache.org/r1834628 - Julian

Re: SVN patch issue with property changes

Dipu H wrote: > Property changes on: xpathleak.py > ___ > Modified: svn:executable > ## -0,0 +1 ## > +* <<<- Yes, there is a change, value * added... > \ No newline at end of property [...] > The patch is rejected with

Re: SVN patch issue with property changes

Hi Philip, It is a conflict. Values didn’t change after applying the patch. root@contrail-ubm-dipuh:/tmp/tests# svn patch /tmp/patch Cxpathleak.py > rejected hunk ## -0,0 +1,1 ## (svn:executable) Summary of conflicts: Property conflicts: 1 root@contrail-ubm-dipuh:/tmp/tests# sv

Re: SVN patch issue with property changes

Daniel Shahaf writes: > You mentioned earlier that svn:executable was present with an empty > value. Is that really the case? If it is --- which would be surprising, > as it's supposed to be an impossible state --- it would explain why you > got a conflict. The normalization of svn:executable

Re: SVN patch issue with property changes

Hi Daniel, Thanks for the update. Yes, I have many files in the repository with "svn:executable" value set to "null". This is a very old repository, may be created using a very older version of svn. Older clients might have added the property without a value. root@contrail-ubm-dipuh:/tmp/tests

Re: SVN patch issue with property changes

Dipu H wrote on Thu, 28 Jun 2018 14:24 +: > Looks like svn is not able to properly handle the svn:executable > property changes via patch. Works for me: [[[ % svnadmin create r % svn co -q file://`pwd`/r wc % cd wc % touch iota % svn add -q iota % svn ci -q -m add % svn up -q % svn ps -q

Re: SVN patch issue with property changes

without changing the property. The destination file > already has svn:executable property present in it. But the value is empty. > Ideally, if the patch was applied properly, the value should have been > changed to "*". > > > After little bit

Re: SVN patch issue with property changes

gt; Property conflicts: 1 > > The patch is rejected without changing the property. The destination file > already has svn:executable property present in it. But the value is empty. > Ideally, if the patch was applied properly, the value should have been > changed to "*". > &

SVN patch issue with property changes

to "*". After little bit of googling, I found the below link which looks like a similar issue. https://jira.atlassian.com/browse/CRUC-6114?src=confmacro SVN Version : 1.8.11 I understand that the latest svn clients add * as the value of svn:executable property. However, if w

Re: issue with relative externals after a rename

bly also take the peg > revision into account. It makes intuitive sense that ../fold1@18 should Do The Right Thing. But if it takes "." and expands it to a full path, then strips off the last component, then applies the peg revision, that will explain the source of the issue. Part

Re: issue with relative externals after a rename

On Wed, Mar 28, 2018 at 4:36 PM, Nathan Hartman wrote: > On Tue, Mar 27, 2018 at 11:36 PM, Branko Čibej wrote: >> >> Because the default operative revision is HEAD and there's no such >> object in HEAD, yes. > > > [snip] > >> >> You need both peg and operative revisions: >> >> -r 18 ../fold1 fold

Re: issue with relative externals after a rename

On 3/28/2018 9:37 AM, Bo Berglund wrote: Just curious since I am working on setting up our svn repositories migrated from CVS. How does one "lock down" tags to disallow further commits? In CVS that was built-in but svn works differently... Bo B. Put a check for the commit path(s) in the p

Re: issue with relative externals after a rename

Just curious since I am working on setting up our svn repositories migrated from CVS.How does one "lock down" tags to disallow further commits? In CVS that was built-in but svn works differently... Bo B.

Re: issue with relative externals after a rename

On Wed, Mar 28, 2018 at 10:59 AM, Nico Kadel-Garcia wrote: > On Wed, Mar 28, 2018 at 10:36 AM, Nathan Hartman > wrote: > > > Our requirements are: at any time in the future, if someone checks > > out code from the past, they should get exactly the same tree as what > > existed in the past. I ass

Re: issue with relative externals after a rename

On Wed, Mar 28, 2018 at 10:36 AM, Nathan Hartman wrote: > Our requirements are: at any time in the future, if someone checks > out code from the past, they should get exactly the same tree as what > existed in the past. I assume that this is probably THE #1 use case > and desired behavior for ext

Re: issue with relative externals after a rename

On Tue, Mar 27, 2018 at 11:36 PM, Branko Čibej wrote: > Because the default operative revision is HEAD and there's no such > object in HEAD, yes. [snip] > You need both peg and operative revisions: > > -r 18 ../fold1 fold1@18 > -r 18 ../fold2/file1.txt@18 file1.txt > > The peg revision tells

Re: issue with relative externals after a rename

On Wed, Mar 28, 2018 at 5:36 AM, Branko Čibej wrote: > On 28.03.2018 01:38, Jonathan Schell wrote: >> I have a tree that looks like: >> >> https://svn/repo/name1/externs/normal_files_here >> >> The folder "externs" has two external properties: >> ../fold1@18 fold1 >> ../fold2/file1.txt@18 file1.tx

Re: issue with relative externals after a rename

On 28.03.2018 01:38, Jonathan Schell wrote: > I have a tree that looks like: > > https://svn/repo/name1/externs/normal_files_here > > The folder "externs" has two external properties: > ../fold1@18 fold1 > ../fold2/file1.txt@18 file1.txt > > These folders and file exist at rev 18. The commit to ad

RE: issue with relative externals after a rename

still an error on the folder. However, I just repeated the issue on a test repo and it worked fine for both the folder and the file, so maybe there's some other condition that's affecting it. Jon -Original Message- From: Johan Corveleyn [mailto:jcor...@gmail.com] Sent: Tuesd

Re: issue with relative externals after a rename

On Tue, Mar 27, 2018 at 10:46 AM, Ryan Schmidt wrote: > > On Mar 26, 2018, at 17:20, Jonathan Schell wrote: > >> I have a tree where one folder is referencing some other folders and >> documents in different parts of the tree. And those externals are pegged. >> >> So, I did a rename of the top f

Re: issue with relative externals after a rename

is this really a bug as it appears to be? Or is it > maybe an issue with TortoiseSVN?

issue with relative externals after a rename

operative revision. This works for the files, but not for the folders. Am I missing something or is this really a bug as it appears to be? Or is it maybe an issue with TortoiseSVN? Jon

Re: E130003: The XML response contains invalid XML - svn co and log issue on some repos using https/http

On Tue, Mar 6, 2018 at 5:21 PM, NOCERA, ANDY wrote: > John, > > Good feedback. > > Svnadmin 1.9 verify is showing the error also. I did a dump and load and it > resolved that repo.Having reviewed my repos, it looks like around 30% > have this issue. Not sure wh

RE: E130003: The XML response contains invalid XML - svn co and log issue on some repos using https/http

John, Good feedback. Svnadmin 1.9 verify is showing the error also. I did a dump and load and it resolved that repo.Having reviewed my repos, it looks like around 30% have this issue. Not sure what we could have done wrong to cause it. A real simple repo is mine and has only a

Re: E130003: The XML response contains invalid XML - svn co and log issue on some repos using https/http

On Thu, Mar 1, 2018 at 11:52 PM, NOCERA, ANDY wrote: > I disabled ssl to simplify. I noticed that svn log sometimes stops with an > error, sometimes it just stops although there is an error in the log. I > think I need to review the build.Not sure if it’s the SVN side of the > build or the

RE: E130003: The XML response contains invalid XML - svn co and log issue on some repos using https/http

[400, #160062] From: Paul Hammant [mailto:p...@hammant.org] Sent: Wednesday, February 28, 2018 8:28 AM To: NOCERA, ANDY Cc: Andreas Krey ; Michael Rohan ; users@subversion.apache.org Subject: Re: E130003: The XML response contains invalid XML - svn co and log issue on some repos using https

RE: E130003: The XML response contains invalid XML - svn co and log issue on some repos using https/http

Cc: Andreas Krey ; Michael Rohan ; users@subversion.apache.org Subject: Re: E130003: The XML response contains invalid XML - svn co and log issue on some repos using https/http As you work toward a conclusion, Andy, do you think there was a different error message that could have driven you to root cause more quickly?

Re: E130003: The XML response contains invalid XML - svn co and log issue on some repos using https/http

As you work toward a conclusion, Andy, do you think there was a different error message that could have driven you to root cause more quickly?

RE: E130003: The XML response contains invalid XML - svn co and log issue on some repos using https/http

, ANDY Cc: Michael Rohan ; Paul Hammant ; users@subversion.apache.org Subject: Re: E130003: The XML response contains invalid XML - svn co and log issue on some repos using https/http On Wed, 28 Feb 2018 03:21:01 +, NOCERA, ANDY wrote: > My cert is not valid at this point, I had turned off ss

Re: E130003: The XML response contains invalid XML - svn co and log issue on some repos using https/http

"NOCERA, ANDY" writes: > svn co https://xxx.com:6022/svn/asgard > svn: E130003: The XML response contains invalid XML If you have the socat proxy available then you can use that to log the traffic and see the failing XML: https://subversion.apache.org/docs/community-guide/debugging.html#net-tra

Re: E130003: The XML response contains invalid XML - svn co and log issue on some repos using https/http

On Wed, 28 Feb 2018 03:21:01 +, NOCERA, ANDY wrote: > My cert is not valid at this point, I had turned off ssl and had the same > error. I wasn???t sure how to get beyond the 301 on a curl You ask for .../asgard, and get redirected to .../asgard/ (note the slash at the end). Try that. And

RE: E130003: The XML response contains invalid XML - svn co and log issue on some repos using https/http

invalid XML - svn co and log issue on some repos using https/http Hi, Might be interesting to see what sort of document you are getting: $ curl https://scm-uat.web.att.com:6022/svn/asgard Might need "-k" on that command depending on what sort of certs are in place. Take care, Michael.

RE: E130003: The XML response contains invalid XML - svn co and log issue on some repos using https/http

There are several repos work fine and even different version is this repo. From: Paul Hammant [mailto:p...@hammant.org] Sent: Tuesday, February 27, 2018 9:44 PM To: NOCERA, ANDY Cc: users@subversion.apache.org Subject: Re: E130003: The XML response contains invalid XML - svn co and log issue

Re: E130003: The XML response contains invalid XML - svn co and log issue on some repos using https/http

Hi, Might be interesting to see what sort of document you are getting: $ curl https://scm-uat.web.att.com:6022/svn/asgard Might need "-k" on that command depending on what sort of certs are in place. Take care, Michael. On Tue, Feb 27, 2018 at 6:44 PM, Paul Hammant wrote: > Do you get the sa

Re: E130003: The XML response contains invalid XML - svn co and log issue on some repos using https/http

Do you get the same error with a testfile.txt resource in a freshly created (and Apache mounted) Subversion repo?

RE: E130003: The XML response contains invalid XML - svn co and log issue on some repos using https/http

-D SERVER_CONFIG_FILE="conf/httpd.conf" From: Paul Hammant [mailto:p...@hammant.org] Sent: Tuesday, February 27, 2018 7:36 PM To: NOCERA, ANDY Cc: users@subversion.apache.org Subject: Re: E130003: The XML response contains invalid XML - svn co and log issue on some repos u

Re: E130003: The XML response contains invalid XML - svn co and log issue on some repos using https/http

See what you can see on the server-side Apache logs - https://unix.stackexchange.com/questions/115972/how-do-i-find-where-apache-keeps-the-log-files (and others; or adjust for your Linux).

E130003: The XML response contains invalid XML - svn co and log issue on some repos using https/http

Hi, I have a recently built SVN 1.9.7 including httpd and I see issues using https/https protocol on a few repos and version. The test repos are 1.8.X and work using file level protocol and svnserve. Some Other repos work with no issues. For asgard example below, I was able to checkout from -

Re: Issue while loading the SVN Dump SVN version 1.9.7

e I have the sha-1 colliding files in my repo ? Also what > are the next steps to catchup the latest revisions from the master node ? > Appreciate all your help and great working with you on this issue !!! > > FYI, > > By the way I have tried running the following command &q

RE: Issue while loading the SVN Dump SVN version 1.9.7

the latest revisions from the master node ? Appreciate all your help and great working with you on this issue !!! FYI, By the way I have tried running the following command " svnadmin load -M 0 /u01/svn/repos < incdump724413.txt "with rep-sharing enabled and still see the same issue.

Re: Issue while loading the SVN Dump SVN version 1.9.7

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://shattered.io >> Our repository is very huge with 1 Million + revisions and I am seeing the &g

Re: Issue while loading the SVN Dump SVN version 1.9.7

ction code. > I am sure that no one committed the sha-1-colliding files from > https://shattered.io > Our repository is very huge with 1 Million + revisions and I am seeing the > issue only while loading the specific revision 724413. I am able to load the > revisions before and

  1   2   3   4   5   6   7   8   >