Bug Report -- Assertion Failure `svn merge` on 1.14.3 from Ubuntu 24.04

The relative path '.' is passed to is_canonical causing an assertion failure in is_canonical when trying to sort the conflicts. The minimal path to reproduce requires a conflict of at least 2 items. One of the conflicts should be '.'. Steps to reproduce: # create and checkout a repo svnadmin cr

Subversion mergeinfo command bug

Hello,Recently, we encountered a bug while using mergeinfo in SVN. Here is an example:Our source branch has the following branch changes (through copy or rename) history:Branch 1: /products/xy1/develop/mos2/trunk, revision a

Re: [Bug] Export path is subject to peg revision parsing

Scratch that. My thread from five years ago is still valid: https://lists.apache.org/thread/lonftwtj2kmnjf5mlp91jyxz9xlsgv3d The issue sill persists. The doc improvement from Daniel Shahaf haven't been implemented yet. Michael

[Bug] Export path is subject to peg revision parsing

Folks, I could have either found a bug in the handling of input or a document insufficiency. We have received a downstream bug: https://github.com/websvnphp/websvn/issues/189 It boils down to this command: # svn export -r 50 'file:///var/svn/Playground/me%40you.d/@' me@you

Re: redirection error with file externals - possible bug

ors like this: >>>>> >>>>> Redirecting to URL ' >>>>> https://myserver/svn/myrepo/TestFolder/Project2/test.txt': >>>>> Fetching external item into 'checkout_target\test.txt': >>>>> svn: warning: W200035:

Re: redirection error with file externals - possible bug

: >>>> svn: warning: W200035: sqlite[S19]: NOT NULL constraint failed: >>>> EXTERNALS.def_repos_relpath >>>> >>> > This error occurs in subversion/libsvn_wc/wc_db.c line 3365 (as of > r1908925), where ieb->recorded_repos_relpath is null for a file e

Re: redirection error with file externals - possible bug

kout_target\test.txt': >>> svn: warning: W200035: sqlite[S19]: NOT NULL constraint failed: >>> EXTERNALS.def_repos_relpath >>> >> This error occurs in subversion/libsvn_wc/wc_db.c line 3365 (as of r1908925), where ieb->recorded_repos_relpath is null

Re: redirection error with file externals - possible bug

ing to checkout a working copy, file-externals are not >> downloaded, the log shows errors like this: >> >> Redirecting to URL ' >> https://myserver/svn/myrepo/TestFolder/Project2/test.txt': >> Fetching external item into 'checkout_target\test.txt':

Re: redirection error with file externals - possible bug

Redirecting to URL ' > https://myserver/svn/myrepo/TestFolder/Project2/test.txt': > Fetching external item into 'checkout_target\test.txt': > svn: warning: W200035: sqlite[S19]: NOT NULL constraint failed: > EXTERNALS.def_repos_relpath > > I found a similar bug r

redirection error with file externals - possible bug

t.txt': svn: warning: W200035: sqlite[S19]: NOT NULL constraint failed: EXTERNALS.def_repos_relpath I found a similar bug report for folder-externals, which was fixed in SVN 1.8.5 https://issues.apache.org/jira/browse/SVN-4428 Reproduction: - the webserver should be setup to redirect htt

Re: Bug: Subversion client at 100% cpu if server hangs up due to error

Den mån 26 juli 2021 kl 17:50 skrev John Abraham : > Hello, I’ve finally figured out the situation in which my subversion > client pins the CPU at 100% and never moves beyond it. And hence I’d like > to report a bug. > > Sometimes the server hangs up the connection, in my case

Bug: Subversion client at 100% cpu if server hangs up due to error

Hello, I’ve finally figured out the situation in which my subversion client pins the CPU at 100% and never moves beyond it. And hence I’d like to report a bug. Sometimes the server hangs up the connection, in my case with this error on the server log: "Working copy path 'hey i

Re: svn info tree conflicts bug using svn 1.10.6?

;t have this problem). > Hello, Just following up to let you know that the above bug is fixed in svn 1.10.7 and 1.14.1, both of which were released last week. Cheers, Nathan

Re: svn info tree conflicts bug using svn 1.10.6?

In article hartman.nat...@gmail.com writes: > On Tue, Jan 19, 2021 at 12:45 PM Matthews, David > wrote: > > > > I appear to be getting incorrect results reported by "svn info --xml" for a > > file which has tree conflicts. > > > > I'm testing with svn 1.10.6 (and 1.9.12 which doesn't have this

Re: svn info tree conflicts bug using svn 1.10.6?

On Tue, Jan 19, 2021 at 12:45 PM Matthews, David wrote: > > I appear to be getting incorrect results reported by "svn info --xml" for a > file which has tree conflicts. > > I'm testing with svn 1.10.6 (and 1.9.12 which doesn't have this problem). Without digging deeper yet, I see it with 1.13.0

svn info tree conflicts bug using svn 1.10.6?

I appear to be getting incorrect results reported by "svn info --xml" for a file which has tree conflicts. I'm testing with svn 1.10.6 (and 1.9.12 which doesn't have this problem). The results from "svn info" for the conflicted file appear correct. However, "svn info --xml" reports the wrong infor

Re: Bug report - Subversion Exception

Dear Pawel, Could you try to install the command line tools in TortoiseSVN and then try to cleanup in the command line? Something like this: cd /d [drive and path to your repository] svn cleanup If this works then you should report the error on the mailinglist of TortoiseSVN, https://tortoisesvn

Bug report - Subversion Exception

--- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list

Re: Svn revert and file permissions bug

body nate 3147 Aug 13 23:32 svnperms.conf.example $ svn revert -R . (no output here) But change it back to 644, and we get the output again: $ sudo chmod 644 svnperms.conf.example $ ls -l svnperms.conf.example -rw-r--r-- 1 nobody nate 3147 Aug 13 23:32 svnperms.conf.example $ svn revert -R . Reve

Svn revert and file permissions bug

I have a really weird problem which may be a bug. I'm running Debian 9 with svn 1.8.17, but I also tried with svn 1.9.5, which I guess is the latest version supported by our OS. Basically, I'm tasked with updating the permission structure of our application servers because we've

Re: Possible bug: "Searching tree conflict details" takes forever

t with a suitable parameter (see > the output of 'svn help resolve' for a list). > > Otherwise, use this command to simply clear the conflict marker: > svn resolve --accept=working path/to/conflict/dir > And then resolve the actual conflict manually as required. >

Re: Possible bug: "Searching tree conflict details" takes forever

en resolve the actual conflict manually as required. > Mac OS 10.14.6 > SVN client 1.14.0, compiled Jul 4 2020, 20:57:11 on x86_64-apple-darwin18.7.0 > SVN server 1.8.13 Some conflicts may be avoided if the server was upgraded to SVN 1.10 or later. Newer servers can help with avoiding some

Possible bug: "Searching tree conflict details" takes forever

Hi there. I'm doing a merge which seems to be doing a very long-running operation (over an hour so far) when it gets to the "Searching tree conflict details" step. I'm wondering if there's any way to avoid this. I'm merging from a branch X where a directory was removed, into a branch Y where th

Re: Bug: Svn client will no longer connect to old SVN server

reserved. Qualcomm Technologies Incorporated. From: Thorsten Sent: June 15, 2020 8:52 PM To: Michael Back Cc: users@subversion.apache.org Subject: [EXT] Re: Bug: Svn client will no longer connect to old SVN server Another stupid hackaround could be to setup a local

Re: Bug: Svn client will no longer connect to old SVN server

Another stupid hackaround could be to setup a local old proxy/man in the middle https server that still accepts old tls  connection, but also provides newer protocols and switch your working copy to this server instead. But a much cleaner solution is to confront IT with the fact that they nee

Re: Bug: Svn client will no longer connect to old SVN server

On Mon, Jun 15, 2020 at 5:05 AM Michael Back wrote: > Hello Subversion folks, > > When I upgraded to the latest version of my Linux OS (Ubuntu 20.04) and > installed Subversion 1.13.0 client, svn could no longer connect to our > company's old subversion server via https. > Doing a checkout result

Re: Bug: Svn client will no longer connect to old SVN server

On 15.06.2020 09:43, Michael Back wrote: > Hello Subversion folks, > > When I upgraded to the latest version of my Linux OS (Ubuntu 20.04) > and installed Subversion 1.13.0 client, svn could no longer connect to > our company's old subversion server via https. > > $ svn --version > svn, ver

Bug: Svn client will no longer connect to old SVN server

Hello Subversion folks, When I upgraded to the latest version of my Linux OS (Ubuntu 20.04) and installed Subversion 1.13.0 client, svn could no longer connect to our company's old subversion server via https. $ svn --version svn, version 1.13.0 (r1867053) compiled Mar 24 2020, 12:33:36 on x

Re: maybe a bug

ocal_abspath)) > Hi lu, If you encountered this error after clicking "Edit" on a file from the TortoiseSVN Repository browser, then you've probably hit a TortoiseSVN-specific bug that was already reported on this list a couple of times before. Just to be clear: TortoiseSVN (Windows G

maybe a bug

--- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list

Re: Bug in docs regarding case-sensitivity?

On 14.12.2019 14:38, sebb wrote: > On Sat, 14 Dec 2019 at 13:33, Daniel Shahaf > wrote: > > sebb wrote on Sat, 14 Dec 2019 13:17 +00:00: > > On Sat, 14 Dec 2019 at 11:51, Daniel Shahaf > mailto:d...@daniel.shahaf.name>> wrote: > > > sebb wrote on Sat

Re: Bug in docs regarding case-sensitivity?

sebb wrote on Sat, 14 Dec 2019 13:38 +00:00: > However [1] says: > > "Section and option names are case-insensitive, but case is preserved." > > Is that still accurate? Test it and, should you find that it isn't accurate, let us know.

Re: Bug in docs regarding case-sensitivity?

On Sat, 14 Dec 2019 at 13:33, Daniel Shahaf wrote: > sebb wrote on Sat, 14 Dec 2019 13:17 +00:00: > > On Sat, 14 Dec 2019 at 11:51, Daniel Shahaf > wrote: > > > sebb wrote on Sat, 14 Dec 2019 09:20 +00:00: > > > > The code comment here [1] and the wiki [2] both state that section > name > > >

Re: Bug in docs regarding case-sensitivity?

sebb wrote on Sat, 14 Dec 2019 13:17 +00:00: > On Sat, 14 Dec 2019 at 11:51, Daniel Shahaf wrote: > > sebb wrote on Sat, 14 Dec 2019 09:20 +00:00: > > > The code comment here [1] and the wiki [2] both state that section name > > > matching is case-insensitive. > > > > > > However my reading

Re: Bug in docs regarding case-sensitivity?

On Sat, 14 Dec 2019 at 11:51, Daniel Shahaf wrote: > sebb wrote on Sat, 14 Dec 2019 09:20 +00:00: > > The code comment here [1] and the wiki [2] both state that section name > > matching is case-insensitive. > > > > However my reading of the document here [3] says this changed in version > 1.7. >

Re: Bug in docs regarding case-sensitivity?

sebb wrote on Sat, 14 Dec 2019 09:20 +00:00: > The code comment here [1] and the wiki [2] both state that section name > matching is case-insensitive. > > However my reading of the document here [3] says this changed in version 1.7. Thank you for taking the time to point out the specific text wi

Bug in docs regarding case-sensitivity?

The code comment here [1] and the wiki [2] both state that section name matching is case-insensitive. However my reading of the document here [3] says this changed in version 1.7. These docs don't seem consistent to me. S. [1] https://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_subr

Re: Bug in Microsoft Application -Subversion

On 21.11.2019 10:23, Anantha Chitradurga Venkatesh (Tata Consultancy Services Limi) wrote: > > Hi > > This is regarding Bug 438116 > <https://domoreexp.visualstudio.com/MSTeams/_workitems/edit/438116>: > [Subversion]Test blocked - Need test steps - Unable to get > notifi

Bug in Microsoft Application -Subversion

Hi This is regarding Bug 438116<https://domoreexp.visualstudio.com/MSTeams/_workitems/edit/438116>: [Subversion]Test blocked - Need test steps - Unable to get notifications in channel. Our internal testing team has come across bug with your Subversion application in Teams we were hopi

RE: [EXTERNAL] Re: Bug in authz exclusion markers

> It's hard to say without seeing the actual authz and group definition > files. The authnz handling is interesting enough that we really need > complete information to reproduce and debug. Sometimes the correct > behaviour is not intuitive. The authz file was attached to the message sent to the g

Re: Bug in authz exclusion markers

> Subversion but not mentioned in the authz file) have? > > $ svnauthz accessof svn_access_test --username unnamedUser > r > > Result: FAIL > > My interpretation of this is a bug in the authz validation - can anyone else > confirm that my thinking on this is correct or

Bug in authz exclusion markers

r Result: PASS 3. What access does unnamedUser (a user who is authenticated to access Subversion but not mentioned in the authz file) have? $ svnauthz accessof svn_access_test --username unnamedUser r Result: FAIL My interpretation of this is a bug in the authz validation - can anyone else confirm

Re: bug report

On Feb 14, 2019, at 11:04, Celso F wrote: > --- > Subversion Exception! > --- > Subversion encountered a serious problem. > Please take the time to report this on the Subversion mailing list > with as much information as possible about what > you wer

bug report

--- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list

Re: Bug report: An error occurred during authentication

Jan Marti wrote on Sun, 06 Jan 2019 00:32 +0100: > But now, with Win10 instead of Win7 as reverse proxy, i get that error > message: > > > > "An error occurred during authentication" Check the error logs of both the proxy server and the backend httpd server for more detailed error messages.

Bug report: An error occurred during authentication

Bug report: Now i installed Windows 10 x64 Pro a new virtualisation host system which also has a role as reverse proxy with IIS to use "Windows Authentication", before i used Windows 7 x64 Pro. The settings on the SVN apache webserver virtual machine are still the same... But now,

Re: possible bug in svn library at "searching tree conflict details" (operation hangs forever)

pts HTML, so I chose plain-text, > but this does not allow adding screenshots, so for convenience you may simply > look at the conversation at the TortoiseSVN google group, where I first > posted about the possible bug in your svn library: > https://groups.google.com/forum/#!topic/tor

possible bug in svn library at "searching tree conflict details" (operation hangs forever)

ience you may simply look at the conversation at the TortoiseSVN google group, where I first posted about the possible bug in your svn library: https://groups.google.com/forum/#!topic/tortoisesvn/qUoGtI8hxJ8 I have added the first and last message

Re: Wildcard bug? Or user error?

e stumbles > upon this, Stefan of Tortoise fame has confirmed your suspicion: > There is a bug in the (at this time) latest Windows SDK, version > 10.0.17134.0, that causes the first matching filename to be > truncated to one character. > > An upcoming Windows Update is supposed to

Re: Wildcard bug? Or user error?

code in Subversion proper for expanding > wildcards in the command-line arguments. > > Just to keep this list in the loop, in case someone else stumbles upon this, Stefan of Tortoise fame has confirmed your suspicion: There is a bug in the (at this time) latest Windows SDK, version 10.0.17134

Re: Wildcard bug? Or user error?

On Mon, Sep 3, 2018 at 6:31 PM Branko Čibej wrote: > These cases are, believe it or not, completely different. On your Mac, > the shell expands the wildcards. On Windows, Subversion is linked with a > library that's shipped with Visual Studio (setargv.obj) that expands the > wildcards in the argu

Re: Wildcard bug? Or user error?

On 03.09.2018 22:30, Nathan Hartman wrote: > On Mon, Sep 3, 2018 at 11:10 AM Johan Corveleyn wrote: > >> On Sun, Sep 2, 2018 at 11:10 PM Nathan Hartman >> wrote: >>> I've encountered weirdness with wildcards several times today, so I >>> just tried in a clean freshly checked-out copy: >>> >>> E:\

Re: Wildcard bug? Or user error?

On Mon, Sep 3, 2018 at 11:10 AM Johan Corveleyn wrote: > On Sun, Sep 2, 2018 at 11:10 PM Nathan Hartman > wrote: > > I've encountered weirdness with wildcards several times today, so I > > just tried in a clean freshly checked-out copy: > > > > E:\workspace\processor>svn rm *.hconfig > > svn: E2

Re: Wildcard bug? Or user error?

On Sun, Sep 2, 2018 at 11:10 PM Nathan Hartman wrote: > > Has there been a recent change to how wildcards (the asterisk '*') is > treated under Windows? > > I am using command line client 1.10.2 r1835932 as installed with > TortoiseSVN 1.10.1, Build 28295 - 64 Bit , 2018/07/15 12:14:12, on > Windo

Wildcard bug? Or user error?

Has there been a recent change to how wildcards (the asterisk '*') is treated under Windows? I am using command line client 1.10.2 r1835932 as installed with TortoiseSVN 1.10.1, Build 28295 - 64 Bit , 2018/07/15 12:14:12, on Windows 10 Home 1803 build 17134.254. I've encountered weirdness with wi

Re: using -F fails using bash process substitution. bug?

Daniel Shahaf writes: > I see you've now done this in r1836306. Any reason not to backport > that? (Feel free to add my +1) Nominated for 1.10. -- Philip

Re: using -F fails using bash process substitution. bug?

Philip Martin wrote on Thu, 19 Jul 2018 16:16 +0100: > We might be able to fix the code that uses stat() > by having it check for EOF as well. I see you've now done this in r1836306. Any reason not to backport that? (Feel free to add my +1)

Re: using -F fails using bash process substitution. bug?

Philip Martin wrote on Thu, 19 Jul 2018 23:07 +0100: > Daniel Shahaf writes: > > >> The workaround is to use: > >> > >> echo -ne "ignorethis\n" | svn ps svn:ignore -F - . > > > > By the way, an even simpler workaround in this case is > > > > svn ps svn:ignore -m $'ignorethis\n' ./ > > No. In

Re: using -F fails using bash process substitution. bug?

Ok, thanks for the explanation. I can use the workaround.

Re: using -F fails using bash process substitution. bug?

Daniel Shahaf writes: >> The workaround is to use: >> >> echo -ne "ignorethis\n" | svn ps svn:ignore -F - . > > By the way, an even simpler workaround in this case is > > svn ps svn:ignore -m $'ignorethis\n' ./ No. In this case -F specifies the property value, not the log message. Something

Re: using -F fails using bash process substitution. bug?

Philip Martin wrote on Thu, 19 Jul 2018 16:16 +0100: > Zing Shishak writes: > > The following fails to set svn:ignore using process substitution for the > > file option: > > > > $ svn ps svn:ignore -F <(echo -ne "ignorethis\n") . > > property 'svn:ignore' set on '.' > > > > The property is created

Re: using -F fails using bash process substitution. bug?

Philip Martin wrote on Thu, 19 Jul 2018 16:16 +0100: > It's possible it did work in the past and in other places that construct > does work, e.g. > >svnmucc -mm put <(echo foo) URL > > Subversion has multiple ways to read a file and when reading from a pipe > (and that shell command construct

Re: using -F fails using bash process substitution. bug?

Zing Shishak writes: > The following fails to set svn:ignore using process substitution for the > file option: > > $ svn ps svn:ignore -F <(echo -ne "ignorethis\n") . > property 'svn:ignore' set on '.' > > The property is created but it's empty. Is this something that's not > expected to work? I

using -F fails using bash process substitution. bug?

The following fails to set svn:ignore using process substitution for the file option: $ svn ps svn:ignore -F <(echo -ne "ignorethis\n") . property 'svn:ignore' set on '.' The property is created but it's empty. Is this something that's not expected to work? I seem to remember doing this in the pa

Re: Bug: svn copy --parents

Nikita Slyusarev writes: > I've prepared a patch for this bug and I'm ready to both create a > corresponding issue in the issue tracker and contribute the patch, but > issue creation form warned me to discuss the issue first on the > mailing list. What are my further a

Bug: svn copy --parents

Hi, all. I've recently discovered a bug in svn client code: copy operation fails with "svn: E155010: Directory 'dst_parent' is not under version control" under the following conditions: * it is repos-to-wc copy * dst parent directory exists, but unversioned *

Re: Bug: Locally deleted file wrongly accepted as log message string.

Branko Čibej wrote: > That check was put in the code to prevent users from writing '-m foo completion>' instead of '-F foo' [...] .. which reminds me of a Subversion tab-completion enhancement I have been missing for some time: completing the names of locally-deleted files in addition to those

Re: Bug: Locally deleted file wrongly accepted as log message string.

On 29.06.2018 10:35, Philip Martin wrote: > Karl Fogel writes: > >> :-). In any case, I first wanted to make sure there is consensus that >> this is a bug. Do we agree? > Agreed. That check was put in the code to prevent users from writing '-m foo' instead of &

Re: Bug: Locally deleted file wrongly accepted as log message string.

Karl Fogel writes: > :-). In any case, I first wanted to make sure there is consensus that > this is a bug. Do we agree? Agreed. -- Philip

Bug: Locally deleted file wrongly accepted as log message string.

I'm pretty sure this is a bug, but wanted to check here first before filing a ticket. Normally, if you accidentally use a local versioned file path as a log message, you will get an error: $ svn --version svn, version 1.10.0 (r1827917) [...] $ svn commit -m locally_versioned_path

Re: Bug in tools/server-side/svnpubsub/svnwcsub.py

On 25 May 2018 at 14:37, Daniel Shahaf wrote: > sebb wrote on Fri, 25 May 2018 14:14 +0100: >> The following fails because fname is not defined: >> >> self.read(fname) [1] >> >> it should be >> >> self.read(self.fname) > > Thanks for the report. OK. > With that change, the [DEFAULT] section does

Re: Bug in tools/server-side/svnpubsub/svnwcsub.py

sebb wrote on Fri, 25 May 2018 14:14 +0100: > The following fails because fname is not defined: > > self.read(fname) [1] > > it should be > > self.read(self.fname) Thanks for the report. With that change, the [DEFAULT] section doesn't get emptied by reload(). Would you like to send a patch th

Bug in tools/server-side/svnpubsub/svnwcsub.py

The following fails because fname is not defined: self.read(fname) [1] it should be self.read(self.fname) [1] http://svn.apache.org/viewvc/subversion/trunk/tools/server-side/svnpubsub/svnwcsub.py?view=markup#l378

Re: Bug - svn hangs

Hello, it finally seems to solve the problem an upgrade of kernel version to 4.13.0-19-generic At last! Thanks to everyone On 02/12/2017 13:26, Luca Baraldi wrote: ll /proc/4830/fd/3 lrwx-- 1 luca luca 64 dic  2 13:24 /proc/4830/fd/3 -> socket:[362320] On 02/12/2017 13:12, Matt Simmons

Re: Bug - svn hangs

ll /proc/4830/fd/3 lrwx-- 1 luca luca 64 dic  2 13:24 /proc/4830/fd/3 -> socket:[362320] On 02/12/2017 13:12, Matt Simmons wrote: What is /proc//fd/3 linked to? On Sat, Dec 2, 2017 at 3:54 AM Luca Baraldi > wrote: Thanks Andreas. I just tried but m

Re: Bug - svn hangs

What is /proc//fd/3 linked to? On Sat, Dec 2, 2017 at 3:54 AM Luca Baraldi wrote: > Thanks Andreas. > > I just tried but my skills fall short on system calls. > > Seems it is blocked on the middle of a read() line, even the line seems > half printed in the log... > > The line which would go as >

Re: Bug - svn hangs

On Sun, Nov 26, 2017 at 11:03:11PM +0100, Luca Baraldi wrote: >I am blocked by this problem and cannot go on working with my pc. As an initial quick emergency hint by an outside person, try using strace/ltrace to figure out more context info (i.e., *why* it might be hanging). Good luck! Andr

Bug - svn hangs

Hello, I am experiencing a problem for which I cannot see solution nor better way to investigate my case than writing to you. I am a java developer so I may not know low level details, but if instructed I may provide them. Client: Ubuntu 17.10, svn version is 1.9.7 (r1800392) - official repos

Re: a little bug when checkout invalid url

On Wed, Sep 27, 2017 at 5:22 PM, Shmuel Hanoch wrote: > Hi, > > When I (accidently) tried to checkout some repository from a wrong url (with > ":" instead of a "@"), the subversion process crushed on assertion. It's > easy to reproduce on my machine, for example: > > svn co svn+ssh://a:l > svn: >

a little bug when checkout invalid url

Hi, When I (accidently) tried to checkout some repository from a wrong url (with ":" instead of a "@"), the subversion process crushed on assertion. It's easy to reproduce on my machine, for example: svn co svn+ssh://a:l svn: /build/subversion-8E3yhQ/subversion-1.9.3/subversion/libsvn_subr/dirent

Re: bug report - optimization suggestion for 1.10's new conflict resolver.

ation bugs still lurking which need to be flushed out during testing. One such bug has already been recorded here: https://issues.apache.org/jira/browse/SVN-4688 Thanks, Stefan

Re: possible client bug with 1.10 automatic conflict resolver

On Fri, Aug 11, 2017 at 09:26:14PM +, Blaine Whittle wrote: > I'm seeing different behavior with automatic conflict resolver when operating > against a 1.10.0-alpha3 compared to a 1.7.10 server. I'm using a > 1.10.0-alpha3 client. > > Test case > > * Create branch B from branch A. >

bug report - optimization suggestion for 1.10's new conflict resolver.

I'm a big fan of the auto tree conflict resolution feature. One optimization I'd like to suggest is after a tree conflict is found, and if the two branches share ancestry then branch move history search should be constrained to the start revision of when the branch was made. When testing the ne

possible client bug with 1.10 automatic conflict resolver

I'm seeing different behavior with automatic conflict resolver when operating against a 1.10.0-alpha3 compared to a 1.7.10 server. I'm using a 1.10.0-alpha3 client. Test case * Create branch B from branch A. * Checkout branch B. * Modify file contents in branch B + commit. * Mo

RE: Checksum mismatch bug in 1.8.18

: Checksum mismatch bug in 1.8.18 Hi David, thanks for the report; the issue turned out to be quite serious. The underlying bug has been present since at least as early as 1.8.0 but only surfaced with the added SHA1-collision detection code in 1.8.18. Under certain circumstances, yet-to-be-committed

Re: Checksum mismatch bug in 1.8.18

Hi David, thanks for the report; the issue turned out to be quite serious. The underlying bug has been present since at least as early as 1.8.0 but only surfaced with the added SHA1-collision detection code in 1.8.18. Under certain circumstances, yet-to-be-committed data would be cached under

RE: Checksum mismatch bug in 1.8.18

e if you really hit this scenario, or that we have a bug in our code that tries to catch this scenario. Assuming you properly verified with 1.9.6 (and not 1.9.5 or earlier) I assume that this is a bug in 1.8.18, as other scenarios are really extremely unlikely. I'm not sure I'll ha

RE: [BUG] svn update produces unexpected result

iao.d...@garmin.com] Sent: vrijdag 10 maart 2017 19:48 To: users@subversion.apache.org Subject: [BUG] svn update produces unexpected result Hi, When using svn update on a file with -r flag from one revision to another where the content of the file at both revisions are identical, the last commit of r

[BUG] svn update produces unexpected result

Hi, When using svn update on a file with -r flag from one revision to another where the content of the file at both revisions are identical, the last commit of result file appears to be out of sync. Example: Foo.txt have identical content at r100 and r200 Foo.txt is at base revision r100 svn up

RE: [Bug] svn export -r of single file fails if there is a newer revision available than the exported one

ndreas [mailto:andreas.sche...@harman.com] Sent: donderdag 16 februari 2017 11:31 To: users@subversion.apache.org Subject: [Bug] svn export -r of single file fails if there is a newer revision available than the exported one SVN server: V1.8.14 (r1692801) Hi, When trying to export a dedicated f

[Bug] svn export -r of single file fails if there is a newer revision available than the exported one

the server, the following error message is returned: svn: E195012: Unable to find repository location for in revision The “@syntax” is working fine: # svn export https://svn-server/trunk/myfile.txt@https://svnserver/trunk/myfile.txt@%3crevision>> Is this an already kno

Re: SVN BUG

hout any error and the operation was successful also . That doesn't sound like a Subversion bug. That sounds like you are using an old version if underlying Apache software with a *horrible* password handling module. Please publish which operating system, which version of Subversion, and whet

Re: SVN BUG

> On Jan 23, 2017, at 05:20, Swamy, Gagana Prabhu wrote: > > Hi , > > Recently I faced the following issue: > > 1)My password that is used is “#anusuya2893#” > 2)While checking out, I mistakenly used the password “#anusuya#” and it > worked fine without any error and the operation was succe

SVN BUG

Hi , Recently I faced the following issue: 1)My password that is used is "#anusuya2893#" 2)While checking out, I mistakenly used the password "#anusuya#" and it worked fine without any error and the operation was successful also . 3)Any other combinations is not working but the 2 combinations(1

[bug] check-mime-type.pl: Windows Support

Dear all, the hook-script check-mime-type.pl [A] doesn't work on the Windows platform as Windows does not support openfork. Additionally files/paths with spaces have to be put in quotes. Plus getting the temp dir should be left to the related Perl functions. [A] https://svn.apache.org/viewvc/subv

RE: Bug patching Unicode files

On Fri, Nov 25, 2016 at 14:32 PM +0100, Stefan Sperling wrote: > Hi Hugo, > > Subversion only supports Unicode it if is encoded as UTF-8. > > Unicode represented in encodings other than UTF-8 is usually treated like a binary file. Fixing this would be a major effort. > See https://issues.apache.org

Re: Bug patching Unicode files

On Fri, Nov 25, 2016 at 01:38:02PM +0100, Hugo González wrote: > Apart from that, I tried to fix the diff file myself, just to check if the > error was only during the generation of the diff file or also to apply an > Unicode diff file. I edited the “changes.diff” file using Notepad++ and > removed

RE: Bug patching Unicode files

users@subversion.apache.org' Asunto: Bug patching Unicode files Hello, and congratulations for your great job at the Subversion project. I think it is an amazing tool. I have found a bug when trying to apply a patch over a Unicode file. The steps to reproduce this bug are: 1.

Bug patching Unicode files

Hello, and congratulations for your great job at the Subversion project. I think it is an amazing tool. I have found a bug when trying to apply a patch over a Unicode file. The steps to reproduce this bug are: 1. Create and version a Unicode file in your repository, for example

fatal bug on svn in core functionality reproducing every time

Bug title: Svn checkout or update cannot successfully get second sub-root folder and files from svn server. Let assume that we have on server one root folder and two sub-root folders. In sub-roots folder have many files and directory. User want to get all data from svn server to local directory

  1   2   3   4   5   6   7   8   9   >