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

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 with this error > o

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

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

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

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 > : > [Subversion]Test blocked - Need test steps - Unable to get > notifications in channel. > > Our

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

On 07.10.2019 13:49, Grierson, David (Lead Engineer) wrote: > Hi, > > I've just deployed Subversion v1.11.1 and have run into an issue with the use > of the exclusion marker within authz files. > > See the attached authz file for data for the test cases. > > This file contains two groups: > 1. "

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

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.

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 actions? If you have a patch

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 '-F foo'. It was *not* put there to

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

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

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

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

On Fri, Aug 11, 2017 at 08:58:46PM +, Blaine Whittle wrote: > 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 > constrain

RE: [BUG] svn update produces unexpected result

The last change revision is documented to be the last revision in which that node changed. The revision number in Subversion is global for the repository, so not changing every file in every revision is 100% expected behavior. And this is the reason we show these different revisions. See t

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

The -r123 and @123 functions have completely different behavior. The @ syntax looks up the url as it was in in revision r123 and fetches the file from there The -r checks the path as it currently exists, back to the path it had in revision 123… following copies, renames, etc. (Note: you can

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

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 the “\0” codes, so I had an ANSI diff file called “changes_fixed.diff”

Re: --EXTERNAL--Re: Bug Report Againgst Subversion 1.9.3 libsvn_subr

On Thu, Jul 14, 2016 at 04:56:21PM +, Bailey, Aaron wrote: > Hey Stefan, > > I think I know what is going on, this is due to my lack of knowledge > about the inner workings of Apache. I'm building subversion for an > several older versions of Linux. I couldn't update the packages on > several

RE: --EXTERNAL--Re: Bug Report Againgst Subversion 1.9.3 libsvn_subr

x27;s worth the time to submit something to their group? Thank you for taking the time to respond, Aaron -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Thursday, July 14, 2016 1:07 AM To: Bailey, Aaron Cc: users@subversion.apache.org Subject: --EXTERNAL--Re: Bug Re

Re: Bug Report Againgst Subversion 1.9.3 libsvn_subr

On Wed, Jul 13, 2016 at 05:37:36PM +, Bailey, Aaron wrote: > This is an update to the reported issue below. > > It appears that calling the pre-processor macro svn_pool_create with an > argument of NULL is done a lot in the Subversion code base. The comments in > the APR function apr_pool_cr

RE: Bug Report Againgst Subversion 1.9.3 libsvn_subr

This is an update to the reported issue below. It appears that calling the pre-processor macro svn_pool_create with an argument of NULL is done a lot in the Subversion code base. The comments in the APR function apr_pool_create_ex in module memory/unix/apr_pools.c seems to imply you shouldn't

Re: bug

Update to 1.8.12 or 1.9.4 and try again. https://sourceforge.net/projects/tortoisesvn/files/1.8.12/Application/ https://sourceforge.net/projects/tortoisesvn/files/1.9.4/Application/   Andreas Gesendet: Montag, 13. Juni 2016 um 10:05 Uhr Von: lemon An: users@subversion.apache.org Betreff: bug ---

Re: BUG - SVN tries to connect to "akamai" - 15 second timeout - CRL - ctldl.windowsupdate.com

Cameron Sours wrote on Wed, Jan 27, 2016 at 20:32:45 +: > The windows Crypto API was attempting to connect to Windows Update to > retrieve Certificate revocation information (CRL - certificate > revocation list). The default timeout for CRL retrieval is 15 seconds. > The timeout for authenticat

Re: BUG - SVN tries to connect to "akamai" - 15 second timeout - CRL - ctldl.windowsupdate.com

Hello Mr. Sours, On Wed, Jan 27, 2016 at 08:32:45PM +, Cameron Sours wrote: >**Additional Information:** Debugging this issue was particularly >difficult. SVN 1.8 disabled support for the Neon HTTP RA (repository >access) library in favor of the Serf library which removed client de

Re: Bug Report: Subversion 1.7 segfaults when using gnome-keyring authentication (Linux x64)

Hi Vikram, Hi Stefan, Thank you for the response and clarification. Yes, I'm using 1.7.19 and I'm with that issue. And, I have tried installing CollabNet Subverion client 1.8.15 and I get a different issue (svn: E175013:) as below. I don't think its a credentials issue because it still fails

Re: Bug Report: Subversion 1.7 segfaults when using gnome-keyring authentication (Linux x64)

Hi Stefan, Thank you for the response and clarification. Yes, I'm using 1.7.19 and I'm with that issue. And, I have tried installing CollabNet Subverion client 1.8.15 and I get a different issue (svn: E175013:) as below. I don't think its a credentials issue because it still fails with the same e

Re: Bug Report: Subversion 1.7 segfaults when using gnome-keyring authentication (Linux x64)

Hi Vikram, Hi, I'm also stuck with this same issue, "svn up" makes svn segfaults and coring. This started happening when I give my new password set in my svn server. Can some one please help on this? Any help is highly appreciated. Thanks Vikram Unfortunately the 1.7 branch is no longer suppor

Re: Bug Report: Subversion 1.7 segfaults when using gnome-keyring authentication (Linux x64)

Hi, I'm also stuck with this same issue, "svn up" makes svn segfaults and coring. This started happening when I give my new password set in my svn server. Can some one please help on this? Any help is highly appreciated. Thanks Vikram

Re: Bug report: svnversion crashes during Subversion build/install

Hi, On Fri, Jan 08, 2016 at 11:44:49AM -0800, David Lowe wrote: > On 2016Jan 7,, at 17:32, Ryan Schmidt wrote: > > > > During the build of Subversion 1.9.3, it calls the just-built svnversion > > program. On OS X at least, this crashes because the just-built Subversion > > libraries have not b

Re: Bug report: svnversion crashes during Subversion build/install

On 2016Jan 7,, at 17:32, Ryan Schmidt wrote: > > During the build of Subversion 1.9.3, it calls the just-built svnversion > program. On OS X at least, this crashes because the just-built Subversion > libraries have not been installed yet so they are not in their expected > place. The crash cau

RE: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

> -Original Message- > From: edward.dauver...@gmail.com > [mailto:edward.dauver...@gmail.com] On Behalf Of Edward d'Auvergne > Sent: dinsdag 6 oktober 2015 12:21 > To: Edward d'Auvergne ; Greg Stein > ; users@subversion.apache.org > Subject: Re: Bug re

Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

On Tue, Oct 06, 2015 at 12:20:47PM +0200, Edward d'Auvergne wrote: > So setting MAGIC is having an effect, but Subversion is falling back, > probably via a non-magic internal code path, to the default > svn:mime-type of "application/octet-stream" for PNG and some other > files. If you don't allow

Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

On 4 October 2015 at 13:32, Stefan Sperling wrote: > On Sun, Oct 04, 2015 at 12:52:33PM +0200, Edward d'Auvergne wrote: >> I would maybe suggest introducing an option for disabling the entire >> automatic property subsystem, i.e. it combines both of these, and >> overrides them. This is an intere

RE: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Subject: Re: Bug report: The auto-props setting of svn:mime-type is > impossible to avoid. > > > This whole discussion -in its many iterations- is one of the reasons why I > > never looked

Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

On Mon, Oct 05, 2015 at 12:06:59AM +0200, Bert Huijben wrote: > I'm not sure if I would call it a security problem when a user adds a file of > their choosing to Subversion though :-) Yes, typical SVN use cases are of no concern. One case I could imagine where this might matter is some automated

Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

On Sat, Oct 03, 2015 at 11:13:08AM +0200, Edward d'Auvergne wrote: > is it really not a bug when: > > enable-auto-props = yes > > and: > > enable-auto-props = no > > both enable auto-props? > > Cheers, > > Edward I think your best way forward is what Ryan suggested: Ensure svn:mime-t

Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

On Oct 4, 2015, at 5:52 AM, Edward d'Auvergne wrote: > So the following setting disables [auto-props]: > >enable-auto-props = no > > If a svn:mime-type was defined in the config file, this is now > disabled. However in this case, [magic-auto-props] then decides to > tag everything with svn

RE: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: zondag 4 oktober 2015 22:01 > To: Branko Čibej > Cc: users@subversion.apache.org > Subject: Re: Bug report: The auto-props setting of svn:mime-type is > impossible to avoid. > > On Sun,

Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

On Sun, Oct 04, 2015 at 09:16:04PM +0200, Branko Čibej wrote: > On the other hand, I am surprised that the logic that uses libmagic > isn't turned off with 'enable-auto-props=no'. After all, using libmagic > is just a convenient extension to the definitions in the [auto-props] > section. Recall th

Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

On 04.10.2015 11:35, Ivan Zhakov wrote: > On 2 October 2015 at 11:06, Edward d'Auvergne wrote: >> Hi all, >> >> I was wondering if this should be considered a bug. At the FlightGear >> project we have a 6 GB data svn repository for aircraft ( >> https://sourceforge.net/projects/flightgear/ , >> h

RE: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: zondag 4 oktober 2015 13:32 > To: Edward d'Auvergne > Cc: Greg Stein ; users@subversion.apache.org > Subject: Re: Bug report: The auto-props setting of svn:mime-type is > impossible to

Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

On Sun, Oct 04, 2015 at 12:52:33PM +0200, Edward d'Auvergne wrote: > I would maybe suggest introducing an option for disabling the entire > automatic property subsystem, i.e. it combines both of these, and > overrides them. This is an interesting thought experiment - devise > any name for such a t

Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

]On 3 October 2015 at 13:19, Stefan Sperling wrote: > On Sat, Oct 03, 2015 at 11:13:08AM +0200, Edward d'Auvergne wrote: >> is it really not a bug when: >> >> enable-auto-props = yes >> >> and: >> >> enable-auto-props = no >> >> both enable auto-props? >> >> Cheers, >> >> Edward > > I thin

RE: Bug report: The auto-props setting of svn:mime-type is impossibleto avoid.

by the xml inventers was a safe decision. Your files are just not 'generic xml', and should have a more specific type. Bert From: Ivan Zhakov Sent: zondag 4 oktober 2015 11:35 To: Edward d'Auvergne Cc: users@subversion.apache.org Subject: Re: Bug report: The auto-props se

Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

On 2 October 2015 at 11:06, Edward d'Auvergne wrote: > Hi all, > > I was wondering if this should be considered a bug. At the FlightGear > project we have a 6 GB data svn repository for aircraft ( > https://sourceforge.net/projects/flightgear/ , > https://sourceforge.net/p/flightgear/fgaddon/HEAD

Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

On Sat, Oct 3, 2015 at 6:53 AM, Ryan Schmidt wrote: > > On Oct 3, 2015, at 4:13 AM, Edward d'Auvergne wrote: > >> is it really not a bug when: >> >>enable-auto-props = yes >> >> and: >> >>enable-auto-props = no >> >> both enable auto-props? > > Obviously, "enable-auto-props = yes" should e

Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

On Oct 3, 2015, at 4:13 AM, Edward d'Auvergne wrote: > is it really not a bug when: > >enable-auto-props = yes > > and: > >enable-auto-props = no > > both enable auto-props? Obviously, "enable-auto-props = yes" should enable auto-props and "enable-auto-props = no" should disable the

Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

On Oct 3, 2015, at 3:25 AM, Edward d'Auvergne wrote: > On 2 October 2015 at 11:33, Stefan Sperling wrote: > >> - configure autoprops for *.xml in ~/.subversion/config to set >> the svn:mime-type property to 'text/plain'. >> Autoprops always override automatic detection with libmagic. > > Fr

Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

On 3 October 2015 at 11:01, Greg Stein wrote: > I do understand this, but this is not a "bug". It is how Subversion is > designed to work. For strange edge cases, the xml people want content to be > labeled application/xml rather than a text subtype. ... I *do* understand > that this negatively im

Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

I do understand this, but this is not a "bug". It is how Subversion is designed to work. For strange edge cases, the xml people want content to be labeled application/xml rather than a text subtype. ... I *do* understand that this negatively impacts your development workflow. Note that you can alw

Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

On 3 October 2015 at 01:05, Greg Stein wrote: > On Fri, Oct 02, 2015 at 10:06:26AM +0200, Edward d'Auvergne wrote: >>... >> As this bad behaviour can be so incredibly damaging for this >> repository, > > Note: the files themselves are not "damaged" -- Subversion will never > alter the contents of

Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

On 2 October 2015 at 12:30, Philip Martin wrote: > "Edward d'Auvergne" writes: > >> I was wondering if there was anything that has been missed here? Is >> this a real bug? The svn:mime-type property is not needed and is not >> desired for any file in this repository. Any help would be >> appre

Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

On 2 October 2015 at 11:33, Stefan Sperling wrote: > On Fri, Oct 02, 2015 at 10:06:26AM +0200, Edward d'Auvergne wrote: >> Hi all, >> >> I was wondering if this should be considered a bug. At the FlightGear >> project we have a 6 GB data svn repository for aircraft ( >> https://sourceforge.net/pr

Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

On Fri, Oct 02, 2015 at 10:06:26AM +0200, Edward d'Auvergne wrote: >... > As this bad behaviour can be so incredibly damaging for this > repository, Note: the files themselves are not "damaged" -- Subversion will never alter the contents of a file when it is first imported/added. It may make a fil

Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

"Edward d'Auvergne" writes: > I was wondering if there was anything that has been missed here? Is > this a real bug? The svn:mime-type property is not needed and is not > desired for any file in this repository. Any help would be > appreciated. You can disable libmagic by setting the environm

Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.

On Fri, Oct 02, 2015 at 10:06:26AM +0200, Edward d'Auvergne wrote: > Hi all, > > I was wondering if this should be considered a bug. At the FlightGear > project we have a 6 GB data svn repository for aircraft ( > https://sourceforge.net/projects/flightgear/ , > https://sourceforge.net/p/flightgea

Re: Bug Report: The "svn switch" command updates a files timestamp if the property svn:keywords is set

On 16.09.2015 14:31, Stefan Sperling wrote: > On Wed, Sep 16, 2015 at 12:08:33PM +, Wolfram, Dirk wrote: >>> I agree that the use of the svn:keywords "URL" has to effect a file's >>> contents if $URL$ is used and therefore the timestamp has to be changed as >>> well. >>> >>> But even if the $

Re: Bug Report: The "svn switch" command updates a files timestamp if the property svn:keywords is set

On Wed, Sep 16, 2015 at 12:08:33PM +, Wolfram, Dirk wrote: > > I agree that the use of the svn:keywords "URL" has to effect a file's > > contents if $URL$ is used and therefore the timestamp has to be changed as > > well. > > > > But even if the $URL$ keyword is not set and the file contents

Re: Bug Report: The "svn switch" command updates a files timestamp if the property svn:keywords is set

On Tue, Sep 15, 2015 at 06:57:43PM +, Wolfram, Dirk wrote: > Hi all, > > I'd like to file a bug in Subversion 1.9.1 and 1.9.0, but I'm not sure if > it's a deliberate behavior. > The problem was not encountered in Subversion 1.7.6, which we used for a long > time. > I didn't find anything co

Re: Bug Report

Hi Milen, Hi all, I'm getting an Assert exception in all recent versions. Tried with 1.9 too and the same... Steps to reproduce: 1. On the root checkout folder do a "Show Log" 2. Select a previous revision. 3. Select a modified file, right click and select "Revert Changes From This Revision"

Re: bug or a feature :)

On Wed, May 6, 2015 at 8:07 PM, Scott Aron Bloom wrote: > So I noticed something.. > > > > We use svn:externals quite a bit, using the format > > -r 1234 ^/externals/ lcldr > > > > And it works just fine, we never moved to the “new” format of > ^/externals/@1234 > > > > However, recently,

Re: BUG REPORT: svndumpfilter 1.8.8 produces corrupt output, incorrect order of Node records

Markus Kuhn writes: > SUMMARY: > > svndumpfilter (version 1.8.8) rearranges the order of Node records > in Revision records in its output, and as a result, the Node-path:, > which the specification says MUST come first, often appears not > as the first record. This can corrupt data when the outpu

Re: BUG REPORT: svndumpfilter 1.8.8 produces corrupt output, incorrect order of Node records

Hi, On 02/02/15 17:14, Markus Kuhn wrote: > BUG REPORT: > > SUMMARY: > > svndumpfilter (version 1.8.8) rearranges the order of Node records Fixed since May 2014, See https://svn.apache.org/repos/asf/subversion/tags/1.8.9/CHANGES : * svndumpfilter: fix order of node record headers (r1578670

Re: [bug report][tortoisesvn 1.8.8] svnsync crashes when target repo cannot be found

I'm guessing you see a combination of a few bugs. The internal canonical format of URLs requires that you use the file://D:/none/existing form and no backslashes. The argument parser should probably convert this for you or produce a proper error. After that all the internal code requires the i

Re: bug about svn diff --summarize

On 8/22/2014 5:25 AM, Andy Levy wrote: On Thu, Aug 21, 2014 at 10:05 PM, 李猛超 wrote: Hello: If I have a file at version 1. then I modefy and commit it, get version 2, Now I make the file be same as version 1 and commit, get version 3. Running "svn diff -r 1", I will get no changes, bu

Re: bug about svn diff --summarize

On 8/22/2014 5:25 AM, Andy Levy wrote: On Thu, Aug 21, 2014 at 10:05 PM, 李猛超 wrote: Hello: If I have a file at version 1. then I modefy and commit it, get version 2, Now I make the file be same as version 1 and commit, get version 3. Running "svn diff -r 1", I will get no changes, bu

Re: bug about svn diff --summarize

On Thu, Aug 21, 2014 at 10:05 PM, 李猛超 wrote: > Hello: > > If I have a file at version 1. then I modefy and commit it, get version > 2, Now I make the file be same as version 1 and commit, get version 3. > Running "svn diff -r 1", I will get no changes, but "svn diff -r 1 > --summarize" wil

Re: bug report, with svn-generated files

Hi; I had an extremely unstable connection. I had troubles both with updates and commit; sorry, I do not remember if this crash was for one or the other. Best regards, Olivier 2014-08-20 5:07 GMT+08:00 Ryan Schmidt : > > On Aug 18, 2014, at 12:33 AM, Olivier Teytaud wrote: > > > > please find en

Re: bug report, with svn-generated files

On Aug 18, 2014, at 12:33 AM, Olivier Teytaud wrote: > > please find enclosed the bug report automatically generated by SVN during > my best svn-crash ever. What were you doing with svn when this crash occurred?

Re: bug with autoindex on Apache 2.4 when loading SVN modules

On 8/2/14 12:17 PM, Gibson, Brian (IMS) wrote: > I have found that if I have these two configuration statements on my Apache > server, I can no longer use auto index. > > LoadModule dav_svn_module /usr/local/subversion/modules/mod_dav_svn.so > > LoadModule authz_svn_module /usr/local/subversion/m

Re: [BUG] svnlook diff infinite loop

On Thu, Jun 5, 2014 at 7:32 PM, Kevin Priest wrote: > > > On Thursday, June 5, 2014 6:03:14 AM UTC-4, Johan Corveleyn wrote: >> >> > On Fri, May 30, 2014 at 5:36 PM, Bert Huijben wrote: >> >> >> >> Hi, >> >> >> >> >> >> >> >> I tried to reproduce your problem for debugging. >> >>

Re: [BUG] svnlook diff infinite loop

On Thu, Jun 5, 2014 at 4:02 PM, Kevin Priest wrote: > > > On Thursday, June 5, 2014 6:03:14 AM UTC-4, Johan Corveleyn wrote: >> >> > On Fri, May 30, 2014 at 5:36 PM, Bert Huijben wrote: >> >> >> >> Hi, >> >> >> >> >> >> >> >> I tried to reproduce your problem for debugging. >> >>

Re: [BUG] svnlook diff infinite loop

On Thursday, June 5, 2014 6:03:14 AM UTC-4, Johan Corveleyn wrote: > > > On Fri, May 30, 2014 at 5:36 PM, Bert Huijben > wrote: > >> > >> Hi, > >> > >> > >> > >> I tried to reproduce your problem for debugging. > >> > >> > >> > >> I did a: > >> > >> > >> > >> $ svn

Re: [BUG] svnlook diff infinite loop

> On Fri, May 30, 2014 at 5:36 PM, Bert Huijben wrote: >> >> Hi, >> >> >> >> I tried to reproduce your problem for debugging. >> >> >> >> I did a: >> >> >> >> $ svn –version >> >> svn, version 1.8.9-SlikSvn-1.8.9-X64 (SlikSvn/1.8.9) X64 >> >>compiled May 8 2014, 20:00:31 on x8

Re: [BUG] svnlook diff infinite loop

Hi Bert, Sorry for the delayed reply. I'm not sure if SlikSvn will suffer from the same problem. I'm not even sure where the problem lies. I am able to reproduce this issue with the open source command-line client. Does SlikSvn customize the client in any way (possibly removing the issue)? I insta

RE: [BUG] svnlook diff infinite loop

Hi, I tried to reproduce your problem for debugging. I did a: $ svn –version svn, version 1.8.9-SlikSvn-1.8.9-X64 (SlikSvn/1.8.9) X64 compiled May 8 2014, 20:00:31 on x86_64-microsoft-windows6.2.9200 $ svnadmin create svnlook-loop $ svnadmin load svnlook-loo

Re: Bug

Hello, > On 2 Apr 2014, at 07:50, wrote: > > In file > 'D:\Development\SVN\Releases\TortoiseSVN-1.8.1\ext\subversion\subversion\libsvn_wc\wc_db.c' > line 8455: assertion failed (svn_dirent_is_absolute(local_abspath)) > --- > OK > --- Please upd

Re: Bug report: svn assert failure: svn: subversion/libsvn_client/merge.c:3128: merge_dir_deleted: Assertion `delb != ((void *)0)' failed.

2014-03-15 11:24 GMT+01:00 Bert Huijben : > This merge will cause the segfault with --force, while the merge succeeds > without problems without the --force. > > The problem is fixed on trunk in r1577812, but that doesn't remove my > recommendation of stopping to use --force with 1.8. Thanks for f

RE: Bug report: svn assert failure: svn: subversion/libsvn_client/merge.c:3128: merge_dir_deleted: Assertion `delb != ((void *)0)' failed.

> -Original Message- > From: Bert Huijben [mailto:b...@qqmail.nl] > Sent: zaterdag 15 maart 2014 10:31 > To: 'Stefan Sperling'; 'Danilo Piazzalunga' > Cc: users@subversion.apache.org > Subject: RE: Bug report: svn assert failure: svn: &

RE: Bug report: svn assert failure: svn: subversion/libsvn_client/merge.c:3128: merge_dir_deleted: Assertion `delb != ((void *)0)' failed.

> -Original Message- > From: Bert Huijben [mailto:b...@qqmail.nl] > Sent: zaterdag 15 maart 2014 10:03 > To: 'Stefan Sperling'; 'Danilo Piazzalunga' > Cc: users@subversion.apache.org > Subject: RE: Bug report: svn assert failure: svn: &

RE: Bug report: svn assert failure: svn: subversion/libsvn_client/merge.c:3128: merge_dir_deleted: Assertion `delb != ((void *)0)' failed.

> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: zaterdag 15 maart 2014 09:45 > To: Danilo Piazzalunga > Cc: users@subversion.apache.org > Subject: Re: Bug report: svn assert failure: svn: > subversion/libsvn_client/merge.c:3128: merge_d

Re: Bug report: svn assert failure: svn: subversion/libsvn_client/merge.c:3128: merge_dir_deleted: Assertion `delb != ((void *)0)' failed.

On Fri, Mar 14, 2014 at 10:53:05PM +0100, Danilo Piazzalunga wrote: > Hi all, > I am asking for confirmation before reporting a bug > > Using Subversion 1.8.8 installed from Ubuntu 14.04 packages, svn > crashed while performing a merge operation involving a replaced > directory. > > I already rep

Re: Bug report: svn assert failure: svn: subversion/libsvn_client/merge.c:3128: merge_dir_deleted: Assertion `delb != ((void *)0)' failed.

Did you read the documentation about adding issues? Adding an issue isn't part of the process of getting an issue resolved. So, do you want to be able to find it in a few years? Or do you want to see it fixed? If you only want to see it remembered, you can add an issue. But if you want to h

  1   2   3   >