AW: Subversion Exception - assertion failed

: Subversion Exception - assertion failed Den tis 12 sep. 2023 kl 12:19 skrev Matthias Klose mailto:m.kl...@automation.de>>: Hi, I want to list a failing assertion. What have I done?: Preparing a merge on a directory with Doxygen configuration files (maybe not usefull, but I did it). choosing o

Re: Subversion Exception - assertion failed

dry-run option. > -> this leads into the following exception: > > --- > Subversion Exception! > --- > Subversion encountered a serious problem. > Please take the time to report this on the Subversion mailing list > with as

Subversion Exception - assertion failed

the following 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 fi

Re: JavaHL: SVNClient.copy throws not very helpful exception

it fails with following exception: org.apache.subversion.javahl.ClientException: Wrong or unexpected property value svn: Commit failed (details follow): svn: Invalid property value at org.apache.subversion.javahl.SVNClient.copy(Native Method) at

Re: JavaHL: SVNClient.copy throws not very helpful exception

On 08 Jun 2021, Thomas Singer wrote: Hi, A user wanted to copy a working copy to an URL and it fails with following exception: org.apache.subversion.javahl.ClientException: Wrong or unexpected property value svn: Commit failed (details follow): svn: Invalid property value at

JavaHL: SVNClient.copy throws not very helpful exception

Hi, A user wanted to copy a working copy to an URL and it fails with following exception: org.apache.subversion.javahl.ClientException: Wrong or unexpected property value svn: Commit failed (details follow): svn: Invalid property value at org.apache.subversion.javahl.SVNClient.copy

Re: Subversion Exception svn_relpath_is_canonical in ra_loader.c

Branko Čibej wrote: All I can say is that there is no way for our canonicalisation functions to produce the correct result for *every* possible input. The new variants that return errors instead of aborting are an improvement, We should mention the new variants in http://subversion.apache.org/d

Re: Subversion Exception svn_relpath_is_canonical in ra_loader.c

>>> it. >>> I right-clicked on a tag and selected "Mark for comparison" >>> I clicked on the trunk. >>> Can't recall if I clicked "compare URLs" or not. >>> >>> Ooh. This is repeatable. I shut down TortoiseSVN complet

Re: Subversion Exception svn_relpath_is_canonical in ra_loader.c

ark for comparison" > > I clicked on the trunk. > > Can't recall if I clicked "compare URLs" or not. > > > > Ooh. This is repeatable. I shut down TortoiseSVN complete and restarted > > it. > > Performed the same sequence of events; I get this sam

Subversion Exception!

When doing an update on the working copy, since twenty commit has been made since last update, I got the following: --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion

Re: [PATCH][swig-py3] Detach Python exception context in callbacks

Yasuhito FUTATSUKI wrote on Tue, 05 Feb 2019 16:11 +0900: > On 2/3/19 11:30 PM, Daniel Shahaf wrote: > > Yasuhito FUTATSUKI wrote on Sun, 03 Feb 2019 20:52 +0900: > >> The patch attached fix them by inserting PyErr_Fetch() and PyErr_Restore() > >> save and restore Python error indicator. > >> > >>

Re: [PATCH][swig-py3] Detach Python exception context in callbacks

On 2/3/19 11:30 PM, Daniel Shahaf wrote: Yasuhito FUTATSUKI wrote on Sun, 03 Feb 2019 20:52 +0900: The patch attached fix them by inserting PyErr_Fetch() and PyErr_Restore() save and restore Python error indicator. (The patch in other thread textually conflict with this patch, though) I don't

Re: [PATCH][swig-py3] Detach Python exception context in callbacks

Yasuhito FUTATSUKI wrote on Sun, 03 Feb 2019 20:52 +0900: > The patch attached fix them by inserting PyErr_Fetch() and PyErr_Restore() > save and restore Python error indicator. > > (The patch in other thread textually conflict with this patch, though) I don't have an opinion on this specific pat

[PATCH][swig-py3] Detach Python exception context in callbacks

Hi, Jun Omae told me (with patch) that exception from Python callback in svn_swig_py_status_func2() causes segmentation fault on Python 3.7. (The patch have already been committed as r1551888). I think cause of segmentation fault on py3 is the change of exception handling between py2 and py3

Re: Subversion Exception!

>> +} >> + >> >> Can we somehow use a smarter pool (perhaps just require passing an existing >> scratch pool as some similar apr apis do). Some library users do use the >> can_return feature and/or exception handling and we would introduce a minor >>

Re: Subversion Exception!

g > scratch pool as some similar apr apis do). Some library users do use the > can_return feature and/or exception handling and we would introduce a minor > memory leak. We'd have to somehow tweak the malfunction_handler to create its own svn_error_t* from the provided pool. Another

Re: Subversion Exception!

= apr_pvsprintf(pool, fmt, ap); + va_end(ap); + return malfunction_handler(can_return, file, line, expr); +} + Can we somehow use a smarter pool (perhaps just require passing an existing scratch pool as some similar apr apis do). Some library users do use the can_return feature and/or exception handling and

Re: svn commit: r1849737 - in /subversion/trunk/subversion/bindings/cxx: include/svnxx.hpp include/svnxx/exception.hpp src/aprwrap/pool.hpp src/exception.cpp src/private/exception-private.hpp tests/te

t;> Branko Čibej wrote on Wed, 26 Dec 2018 22:41 +0100: >>>>>> On 26.12.2018 19:50, Daniel Shahaf wrote: >>>>>>> Haven't reviewed the rest of the patch, nor the mapping of >>>>>>> svn_error_t::apr_err values to this hierarchy.

Re: svn commit: r1849737 - in /subversion/trunk/subversion/bindings/cxx: include/svnxx.hpp include/svnxx/exception.hpp src/aprwrap/pool.hpp src/exception.cpp src/private/exception-private.hpp tests/te

00: > >>>> On 26.12.2018 19:50, Daniel Shahaf wrote: > >>>>> Haven't reviewed the rest of the patch, nor the mapping of > >>>>> svn_error_t::apr_err values to this hierarchy. > >>>> There is just one exception type that encapsula

Re: svn commit: r1849737 - in /subversion/trunk/subversion/bindings/cxx: include/svnxx.hpp include/svnxx/exception.hpp src/aprwrap/pool.hpp src/exception.cpp src/private/exception-private.hpp tests/te

celed' — or at >>> least not without a lot of effort, as there are no public constructors. >>> I would hope a smart IDE would notice, or else at least a smart user >>> will. :) >>> >>> But yes, I hear you. stop_iteration is a good suggestion. >&

Re: svn commit: r1849737 - in /subversion/trunk/subversion/bindings/cxx: include/svnxx.hpp include/svnxx/exception.hpp src/aprwrap/pool.hpp src/exception.cpp src/private/exception-private.hpp tests/te

ven't reviewed the rest of the patch, nor the mapping of >>>>> svn_error_t::apr_err values to this hierarchy. >>>> There is just one exception type that encapsulates all of svn_error_t, >>>> including the apr_err bit; that's 'svn::error'. I

Re: svn commit: r1849737 - in /subversion/trunk/subversion/bindings/cxx: include/svnxx.hpp include/svnxx/exception.hpp src/aprwrap/pool.hpp src/exception.cpp src/private/exception-private.hpp tests/te

public constructors. > > I would hope a smart IDE would notice, or else at least a smart user > > will. :) > > > > But yes, I hear you. stop_iteration is a good suggestion. > > > Out of interest ... where is SVN_ERR_STOP_ITERATION defined? I can't > find it on trunk. Sorry, SVN_ERR_ITER_BREAK. StopIteration is a Python exception class. Cheers, Daniel

Re: svn commit: r1849737 - in /subversion/trunk/subversion/bindings/cxx: include/svnxx.hpp include/svnxx/exception.hpp src/aprwrap/pool.hpp src/exception.cpp src/private/exception-private.hpp tests/te

f > >>> svn_error_t::apr_err values to this hierarchy. > >> There is just one exception type that encapsulates all of svn_error_t, > >> including the apr_err bit; that's 'svn::error'. I have no intention of > >> going down the rabbit hole of hav

Re: svn commit: r1849737 - in /subversion/trunk/subversion/bindings/cxx: include/svnxx.hpp include/svnxx/exception.hpp src/aprwrap/pool.hpp src/exception.cpp src/private/exception-private.hpp tests/te

On 26.12.2018 23:21, Daniel Shahaf wrote: > Branko Čibej wrote on Wed, 26 Dec 2018 22:41 +0100: >> On 26.12.2018 19:50, Daniel Shahaf wrote: >>> Haven't reviewed the rest of the patch, nor the mapping of >>> svn_error_t::apr_err values to this hierarchy. >>

Re: svn commit: r1849737 - in /subversion/trunk/subversion/bindings/cxx: include/svnxx.hpp include/svnxx/exception.hpp src/aprwrap/pool.hpp src/exception.cpp src/private/exception-private.hpp tests/te

Branko Čibej wrote on Wed, 26 Dec 2018 22:41 +0100: > On 26.12.2018 19:50, Daniel Shahaf wrote: > > Haven't reviewed the rest of the patch, nor the mapping of > > svn_error_t::apr_err values to this hierarchy. > > There is just one exception type that encapsulates all o

Re: svn commit: r1849737 - in /subversion/trunk/subversion/bindings/cxx: include/svnxx.hpp include/svnxx/exception.hpp src/aprwrap/pool.hpp src/exception.cpp src/private/exception-private.hpp tests/te

On 26.12.2018 22:41, Branko Čibej wrote: > On 26.12.2018 19:50, Daniel Shahaf wrote: >> br...@apache.org wrote on Wed, 26 Dec 2018 04:28 +: >>> Reimplement exceptions in SVN++. >>> >>> Instead of extracting error messages from the svn_error_t when th

Re: svn commit: r1849737 - in /subversion/trunk/subversion/bindings/cxx: include/svnxx.hpp include/svnxx/exception.hpp src/aprwrap/pool.hpp src/exception.cpp src/private/exception-private.hpp tests/te

On 26.12.2018 19:50, Daniel Shahaf wrote: > br...@apache.org wrote on Wed, 26 Dec 2018 04:28 +: >> Reimplement exceptions in SVN++. >> >> Instead of extracting error messages from the svn_error_t when the exception >> is created, keep the svn_error_t embedded i

Re: svn commit: r1849737 - in /subversion/trunk/subversion/bindings/cxx: include/svnxx.hpp include/svnxx/exception.hpp src/aprwrap/pool.hpp src/exception.cpp src/private/exception-private.hpp tests/te

br...@apache.org wrote on Wed, 26 Dec 2018 04:28 +: > Reimplement exceptions in SVN++. > > Instead of extracting error messages from the svn_error_t when the exception > is created, keep the svn_error_t embedded in the exception and use its > contents > only when needed.

Re: New canonicalization functions [was: Subversion Exception!]

On 15.12.2018 12:24, Branko Čibej wrote: > On 14.12.2018 19:05, Branko Čibej wrote: >> On Fri, 14 Dec 2018, 18:14 Julian Foad > >>> Julian Foad wrote: Are you willing to add random-input testing for them? >>> The attached patch 'dirent-uri-test-random-2.patch' tests rules like: >>> >>> * eve

Re: New canonicalization functions [was: Subversion Exception!]

On 14.12.2018 19:05, Branko Čibej wrote: > On Fri, 14 Dec 2018, 18:14 Julian Foad >> Julian Foad wrote: >>> Are you willing to add random-input testing for them? >> The attached patch 'dirent-uri-test-random-2.patch' tests rules like: >> >> * every result should pass an X_is_canonical() test (ob

Re: New canonicalization functions [was: Subversion Exception!]

Branko Čibej wrote: > What inconsistencies? A canonical URI has the scheme and host name in > lowercase, but the path, query, fragment and user info parts are case- > sensitive.> > Similarly, I think we (or APR?) make drive letters lowercase. In both cases I found examples where is_canonical said

Re: New canonicalization functions [was: Subversion Exception!]

On Fri, 14 Dec 2018, 18:14 Julian Foad Julian Foad wrote: > > Are you willing to add random-input testing for them? > > The attached patch 'dirent-uri-test-random-2.patch' tests rules like: > > * every result should pass an X_is_canonical() test (obvious by code > inspection); > * every other

Re: New canonicalization functions [was: Subversion Exception!]

On Fri, 14 Dec 2018, 16:18 Julian Foad Branko Čibej wrote: > > r1848943, for review. [...] > > Woo hoo! Thanks, Brane. > > Are you willing to add random-input testing for them? > > Minor comments: > * the 'relpath' one is not needed because, AFAIK, it's possible to > canonicalize any relpath and

Re: New canonicalization functions [was: Subversion Exception!]

Julian Foad wrote: > Are you willing to add random-input testing for them? The attached patch 'dirent-uri-test-random-2.patch' tests rules like: * every result should pass an X_is_canonical() test (obvious by code inspection); * every other input should produce SVN_ERR_CANONICALIZATION_FAILE

Re: New canonicalization functions [was: Subversion Exception!]

Branko Čibej wrote: > r1848943, for review. [...] Woo hoo! Thanks, Brane. Are you willing to add random-input testing for them? Minor comments: * the 'relpath' one is not needed because, AFAIK, it's possible to canonicalize any relpath and we already do; * the non-canonical 'result' and scr

New canonicalization functions [was: Subversion Exception!]

On 13.12.2018 17:00, Branko Čibej wrote: > On 13.12.2018 16:53, Michael Pilato wrote: >> On 12/13/18 10:45 AM, Branko Čibej wrote: >>> Uh. I forgot about the malfunction handler. However this doesn't really >>> help, other than putting possibly sensitive paths into the crash handler >>> info? We re

Re: Subversion Exception!

On Fri, 14 Dec 2018, 05:41 Nathan Hartman On Thu, Dec 13, 2018 at 11:59 AM Branko Čibej wrote: > >> I never said that it's a good idea to abort in a library. We made a >> mistake in the early days of this project to allow such patterns. > > >> >> I am quite angry at the contrariness and stubbornn

Re: Subversion Exception!

On Thu, Dec 13, 2018 at 11:59 AM Branko Čibej wrote: > I never said that it's a good idea to abort in a library. We made a > mistake in the early days of this project to allow such patterns. > > I am quite angry at the contrariness and stubbornness of one TSVN > developer, who is *also* a Subve

Re: Subversion Exception!

On 13.12.2018 17:39, Mark Phippard wrote: >> On Dec 13, 2018, at 11:26 AM, Branko Čibej wrote: >> >> On 13.12.2018 17:09, Mark Phippard wrote: On Dec 13, 2018, at 10:53 AM, Michael Pilato wrote: > On 12/13/18 10:45 AM, Branko Čibej wrote: > Uh. I forgot about the malfunction han

Re: Subversion Exception!

> On Dec 13, 2018, at 11:30 AM, Daniel Shahaf wrote: > > Mark Phippard wrote on Thu, 13 Dec 2018 11:09 -0500: >> FWIW, I agree with Stefan on all of this. We should not be doing abort >> from a library. Whether TSVN could do more to avoid it seems like a >> separate issue. I do not see why

Re: Subversion Exception!

> On Dec 13, 2018, at 11:26 AM, Branko Čibej wrote: > > On 13.12.2018 17:09, Mark Phippard wrote: >>> On Dec 13, 2018, at 10:53 AM, Michael Pilato wrote: >>> On 12/13/18 10:45 AM, Branko Čibej wrote: Uh. I forgot about the malfunction handler. However this doesn't really help,

Re: Subversion Exception!

Daniel Shahaf wrote: > At the same time, I think Brane had a valid point. It is not > users@subversion's job to triage TortoiseSVN error reports; It's a valid point of view but please let's stop pushing that point, especially don't ask Stefan to go over it again. Please let's concentrate on what

Re: Subversion Exception!

Mark Phippard wrote on Thu, 13 Dec 2018 11:09 -0500: > FWIW, I agree with Stefan on all of this. We should not be doing abort > from a library. Whether TSVN could do more to avoid it seems like a > separate issue. I do not see why the library cannot just return a > useful error and allow the

Re: Subversion Exception!

Daniel Shahaf wrote: > [...] If you have > found a value for which svn_foo_is_canonical(svn_foo_canonicalize(value)) > returns false, please tell us what that value is. Daniel, some examples: path = "foo"; -> assertion 'svn_uri_is_canonical(svn_uri_canonicalize(f, pool), pool)' failed #define S

Re: Subversion Exception!

On 13.12.2018 17:09, Mark Phippard wrote: >> On Dec 13, 2018, at 10:53 AM, Michael Pilato wrote: >> >>> On 12/13/18 10:45 AM, Branko Čibej wrote: >>> Uh. I forgot about the malfunction handler. However this doesn't really >>> help, other than putting possibly sensitive paths into the crash handler

Re: Subversion Exception!

Branko Čibej wrote on Thu, 13 Dec 2018 17:00 +0100: > On 13.12.2018 16:53, Michael Pilato wrote: > > On 12/13/18 10:45 AM, Branko Čibej wrote: > >> Uh. I forgot about the malfunction handler. However this doesn't really > >> help, other than putting possibly sensitive paths into the crash handler >

Re: Subversion Exception!

> On Dec 13, 2018, at 10:53 AM, Michael Pilato wrote: > >> On 12/13/18 10:45 AM, Branko Čibej wrote: >> Uh. I forgot about the malfunction handler. However this doesn't really >> help, other than putting possibly sensitive paths into the crash handler >> info? We really shouldn't do it this way

Re: Subversion Exception!

On 13.12.2018 16:53, Michael Pilato wrote: > On 12/13/18 10:45 AM, Branko Čibej wrote: >> Uh. I forgot about the malfunction handler. However this doesn't really >> help, other than putting possibly sensitive paths into the crash handler >> info? We really shouldn't do it this way, users *will* jus

Re: Subversion Exception!

On 12/13/18 10:45 AM, Branko Čibej wrote: > Uh. I forgot about the malfunction handler. However this doesn't really > help, other than putting possibly sensitive paths into the crash handler > info? We really shouldn't do it this way, users *will* just copy and > paste the output tot he 'net. Ahem

Re: Subversion Exception!

Branko Čibej wrote: > On 13.12.2018 16:42, Johan Corveleyn wrote: > >> [...] assertion failed > >> (svn_dirent_is_absolute(local_abspath='C:ImNotAbsolute')) > > Nice :-). I'm not sure what others think, but IMHO that would make > > these error reports a lot more useful ... > > [...] this doesn't

Re: Subversion Exception!

On 13.12.2018 16:42, Johan Corveleyn wrote: > On Thu, Dec 13, 2018 at 4:05 PM Julian Foad wrote: >> Johan Corveleyn wrote: >>> Just thinking out loud here, but could we perhaps log the >>> non-canonical value as part of the assertion output? >>> [...] >>> something like >>> >>> line 10238: assert

Re: Subversion Exception!

On Thu, Dec 13, 2018 at 4:05 PM Julian Foad wrote: > > Johan Corveleyn wrote: > > Just thinking out loud here, but could we perhaps log the > > non-canonical value as part of the assertion output? > > [...] > > something like > > > > line 10238: assertion failed > > (svn_dirent_is_absolute(local_

Re: Subversion Exception!

Johan Corveleyn wrote: > Just thinking out loud here, but could we perhaps log the > non-canonical value as part of the assertion output? > [...] > something like > > line 10238: assertion failed > (svn_dirent_is_absolute(local_abspath='C:ImNotCanonical')) Yes, Johan, we could do that. The atta

Re: Subversion Exception!

On 13.12.2018 14:15, Johan Corveleyn wrote: > On Wed, Dec 12, 2018 at 10:23 PM Daniel Shahaf > wrote: >> Stefan Kueng wrote on Wed, 12 Dec 2018 21:16 +0100: >>> And as I repeatedly said: TSVN does validate the input as good as it >>> can. But if svn does neither describe the *exact* specs in the

Re: Subversion Exception!

On Wed, Dec 12, 2018 at 10:23 PM Daniel Shahaf wrote: > Stefan Kueng wrote on Wed, 12 Dec 2018 21:16 +0100: > > And as I repeatedly said: TSVN does validate the input as good as it > > can. But if svn does neither describe the *exact* specs in the docs nor > > provide any APIs that do that, then T

Re: Subversion Exception!

Stefan Kueng wrote on Wed, 12 Dec 2018 21:16 +0100: > And as I repeatedly said: TSVN does validate the input as good as it > can. But if svn does neither describe the *exact* specs in the docs nor > provide any APIs that do that, then TSVN has to guess. > And no: specifying that paths/uris have t

Re: Subversion Exception!

*exact* specs in the docs > nor provide any APIs that do that, then TSVN has to guess. > And no: specifying that paths/uris have to be "canonicalized" is not > enough because I do that, using the svn APIs. > So apparently that's not enough. Get one of the dumps the

Re: Subversion Exception!

On 12.12.2018 21:12, Branko Čibej wrote: On 12.12.2018 19:07, Stefan Kueng wrote: On 12.12.2018 13:55, TortoiseSVN-dev on behalf of Julian Foad wrote: Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list […] https://subversion.apach

Re: Subversion Exception!

On 12.12.2018 19:07, Stefan Kueng wrote: > > > On 12.12.2018 13:55, TortoiseSVN-dev on behalf of Julian Foad wrote: Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list >> […] https://subversion.apache.org/mailing-lists.html >>

Re: Subversion Exception!

3117@%3Cdev.subversion.apache.org%3E if svn_xxx_canonicalize() don't guarantee that a path/uri is correct and won't throw an exception (or return an error), then how can I in an UI client guarantee that before passing the user input to the library? Since I can't (only the svn lib and specifi

Re: Subversion Exception!

>> Subversion encountered a serious problem. >> Please take the time to report this on the Subversion mailing list […] >> https://subversion.apache.org/mailing-lists.html >It is likely that this is a problem specific to TortoiseSVN, and not >to core SVN. TortoiseSVN has its own mailinglists, so yo

Re: Subversion Exception!

On Mon, Dec 10, 2018 at 9:47 AM Peta Miller wrote: > > Hello, > > > > i got following exception at trying to start the tortoisesvn Project Monitor > with a doubleclick on the tray icon. > > System: WIN 10, Build 15063 > > -

Subversion Exception!

Hello,   i got following exception at trying to start the tortoisesvn Project Monitor with a doubleclick on the tray icon.  System: WIN 10, Build 15063 --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time

Re: Re[2]: Subversion Exception on commit wirth pathfile

gt;>> "C:\Program Files\TortoiseSVN\bin\TortoiseProc.exe" /command:commit >>>> /pathfile:"d:\SVN\Work\Source\Project\f2.txt" >>>> >>>> File f2.txt contains two strings: >>>> >>>> d:\SVN\Work\S

Re[2]: Subversion Exception on commit wirth pathfile

tains two strings: > > d:\SVN\Work\Source\Source\Project.Client > d:\SVN\Work\Source\Source\Project.Server > > And I received such result: > > --- > Subversion Exception! > --- > Subversion encountered a serious problem.

Re: Subversion Exception on commit wirth pathfile

; > File f2.txt contains two strings: > > > > d:\SVN\Work\Source\Source\Project.Client > > d:\SVN\Work\Source\Source\Project.Server > > > > And I received such result: > > > > --- > > Subversion Exception! > >

Re: Subversion Exception on commit wirth pathfile

gt; > d:\SVN\Work\Source\Source\Project.Client > d:\SVN\Work\Source\Source\Project.Server > > And I received such result: > > --- > Subversion Exception! > --- > Subversion encountered a serious problem. > Please take the

Subversion Exception on commit wirth pathfile

received such result: --- 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 m

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: Subversion Exception!

[Top-posting on purpose] Would it make sense to require other clients, such as TortoiseSVN, to change the text and links in this exception message? It would be better for everyone if the authors of the distro (in this case, TSVN) were the first to get these error reports. This particular one

Re: Subversion Exception!

Dear Andreas if someone should encounter this error, point to the eventual existence of the zepto virus which has encrypted some of my .svn files Alfred On 9/13/2016 1:55 PM, Andreas Stieger wrote: Hi, Alfred Ultsch wrote: In file 'D:\Development\SVN\Releases\TortoiseSVN-1.9.3\ext\s

Re: Subversion Exception!

Hi, Alfred Ultsch wrote: > In file > > 'D:\Development\SVN\Releases\TortoiseSVN-1.9.3\ext\subversion\subversion\libsvn_client\cleanup.c' > line 227: assertion failed (svn_dirent_is_absolute(dir_abspath)) Upgrade to 1.9.4 and try again. Andreas

Subversion Exception!

In file 'D:\Development\SVN\Releases\TortoiseSVN-1.9.3\ext\subversion\subversion\libsvn_client\cleanup.c' line 227: assertion failed (svn_dirent_is_absolute(dir_abspath))

Subversion Exception!

Hi there! Just FYI --- 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

Re: Exception reporting

On Thu, Oct 9, 2014 at 7:04 PM, Branko Čibej wrote: > On 09.10.2014 12:32, Stefan Fuhrmann wrote: > > On Thu, Oct 9, 2014 at 6:53 AM, Branko Čibej wrote: > >> On 08.10.2014 09:02, Kumar Krishnamoorthy wrote: >> >> Just reporting it because by subversion client asked me to report it :-) >> >>

Re: Exception reporting

On 09.10.2014 12:32, Stefan Fuhrmann wrote: > On Thu, Oct 9, 2014 at 6:53 AM, Branko Čibej > wrote: > > On 08.10.2014 09:02, Kumar Krishnamoorthy wrote: >> >> Just reporting it because by subversion client asked me to report >> it :-) >> > > I'm beginning

Re: Exception reporting

On Thu, Oct 9, 2014 at 2:34 PM, Bert Huijben wrote: > > > > -Original Message- > > From: Stefan Sperling [mailto:s...@elego.de] > > Sent: donderdag 9 oktober 2014 12:05 > > To: Branko Čibej > > Cc: Subversion Development > > Subject: Re: Except

RE: Exception reporting

> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: donderdag 9 oktober 2014 12:05 > To: Branko Čibej > Cc: Subversion Development > Subject: Re: Exception reporting > > On Thu, Oct 09, 2014 at 06:53:00AM +0200, Branko Čibej wrote: > &

Re: Exception reporting

On Thu, Oct 9, 2014 at 6:53 AM, Branko Čibej wrote: > On 08.10.2014 09:02, Kumar Krishnamoorthy wrote: > > Just reporting it because by subversion client asked me to report it :-) > > > I'm beginning to wonder if we should ask the TSVN devs to field these > crash reports. > Maybe it would have

Re: Exception reporting

On Thu, Oct 09, 2014 at 06:53:00AM +0200, Branko Čibej wrote: > On 08.10.2014 09:02, Kumar Krishnamoorthy wrote: > > > > Just reporting it because by subversion client asked me to report it :-) > > > > I'm beginning to wonder if we should ask the TSVN devs to field these > crash reports. It's conf

Re: Exception reporting

On 08.10.2014 09:02, Kumar Krishnamoorthy wrote: > > Just reporting it because by subversion client asked me to report it :-) > I'm beginning to wonder if we should ask the TSVN devs to field these crash reports. It's confusing and not very productive for us to get reports of crashes in Tortoise;

[compile for windows] gen-make.py raise exception

I tried to compile subversion trunk, and running gen-make.py, but raise exception at build\generator\gen_win_dependencies.py. build\generator\gen_win_dependencies.py tries to find LIBINTL_VERSION from libintl.h, but libintl.h doesn't contain LIBINTL_VERSION. Where can I get libintl.h whic

Subversion Exception!

Hello, I find an Subversion exception, I just update code by [SVN Update] and it happens. FYI --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much

Re: [PATCH] fix exception of gen-make.py using --with-libintl [Re: svn commit: r1504501 - in /subversion/trunk: build.conf build/generator/gen_win.py build/generator/gen_win_dependencies.py gen-make.p

Does anybody review my patch? Let me know a reason if my patch is not approprite I re-create a patch for the lastest revison. Regards. -- Masaru Tsuchiyama Index: build/generator/gen_win_dependencies.py === --- build/generator/gen

Re: [PATCH] fix exception of gen-make.py using --with-libintl [Re: svn commit: r1504501 - in /subversion/trunk: build.conf build/generator/gen_win.py build/generator/gen_win_dependencies.py gen-make.p

Hi. Does anybody comment my patch? -- Masaru Tsuchiyama Masaru Tsuchiyama wrote: Hi. Does anybody comment my patch? (2013/07/31 21:53), Masaru Tsuchiyama wrote: Hi. Running gen-make.py with --with-libintl option raises AttributeError exception when using svn-win32-libintl.zip at http

Re: [PATCH] fix exception running gen-make.py

t;> still be wrong if args[0] were a dangling symlink. And so on. >> >> Calling open() will detect all those potential problems. > > Thank you for the commit. > > But I think you should catch a exception which parser.readfp() throws, > and print approprite error mes

Re: [PATCH] fix exception running gen-make.py

those potential problems. Thank you for the commit. But I think you should catch a exception which parser.readfp() throws, and print approprite error mesage. I think Users who don't know Python prefer an well-formatted error message to stack trace. Regards. -- Masaru Tsuchiyama

Re: [PATCH] fix exception running gen-make.py

Daniel Shahaf wrote on Sun, Aug 18, 2013 at 16:30:45 +0300: > Masaru Tsuchiyama wrote on Sun, Aug 18, 2013 at 22:13:54 +0900: > > Daniel Shahaf wrote: > >> I think that's the wrong fix. Input validation should be done by > >> checking that the input is valid, not by ruling out every known invalid

Re: [PATCH] fix exception running gen-make.py

Masaru Tsuchiyama wrote on Sun, Aug 18, 2013 at 22:13:54 +0900: > Daniel Shahaf wrote: >> I think that's the wrong fix. Input validation should be done by >> checking that the input is valid, not by ruling out every known invalid >> value.[1] In this case: by checking os.path.exists() at the poin

Re: [PATCH] fix exception running gen-make.py

Daniel Shahaf wrote: I think that's the wrong fix. Input validation should be done by checking that the input is valid, not by ruling out every known invalid value.[1] In this case: by checking os.path.exists() at the point in the code that tries to interpret the argument as a filename. Fixed

Re: [PATCH] fix exception running gen-make.py

> Index: gen-make.py > === > --- gen-make.py (revision 1514179) > +++ gen-make.py (working copy) > @@ -278,6 +278,9 @@ if __name__ == '__main__': >except getopt.GetoptError, e: > _usage_exit(str(e)) > > + if arg

Re: [PATCH] fix exception running gen-make.py

(2013/08/08 0:15), Daniel Shahaf wrote: masaru tsuchiyama wrote on Thu, Aug 01, 2013 at 00:11:30 +0900: * gen-make.py () : use default value as conf when args[0] is line ending. I don't use windows, but I think the right fix in this case is to prevent ("\n" in sys.argv) from becoming true

Re: [PATCH] fix exception running gen-make.py

masaru tsuchiyama wrote on Thu, Aug 01, 2013 at 00:11:30 +0900: > * gen-make.py >() : use default value as conf when args[0] is line ending. I don't use windows, but I think the right fix in this case is to prevent ("\n" in sys.argv) from becoming true in the first place.

Re: [PATCH] fix exception running gen-make.py

Hi. Does anybody comment my patch? (2013/08/01 0:11), masaru tsuchiyama wrote: Hi I attach a patch to fix exception when running gen-make.py by the attached bat file which contains line ending after last ^. ( I rename the bat file to txt for security reason) [[[ Fix exception when the

Re: [PATCH] fix exception of gen-make.py using --with-libintl [Re: svn commit: r1504501 - in /subversion/trunk: build.conf build/generator/gen_win.py build/generator/gen_win_dependencies.py gen-make.p

Hi. Does anybody comment my patch? (2013/07/31 21:53), Masaru Tsuchiyama wrote: Hi. Running gen-make.py with --with-libintl option raises AttributeError exception when using svn-win32-libintl.zip at http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=2627&expandFolde r=

[PATCH] fix exception running gen-make.py

Hi I attach a patch to fix exception when running gen-make.py by the attached bat file which contains line ending after last ^. ( I rename the bat file to txt for security reason) [[[ Fix exception when the argument of gen-make.py is line ending. * gen-make.py () : use default value as conf

[PATCH] fix exception of gen-make.py using --with-libintl [Re: svn commit: r1504501 - in /subversion/trunk: build.conf build/generator/gen_win.py build/generator/gen_win_dependencies.py gen-make.py wi

Hi. Running gen-make.py with --with-libintl option raises AttributeError exception when using svn-win32-libintl.zip at http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=2627&expandFolde r=2627&folderID=260 _find_libintl in SVNCommonLibrary assumes libintl.h has the def

gen-make.py gets exception "AttributeError: 'NoneType' object has no attribute 'group'" with --with-libintl option

Hi. gen-make.py gets the following exception at r1506773. Traceback (most recent call last): File "D:\svnwork\exception\gen-make.py", line 330, in main(conf, gentype, skip_depends=skip, other_options=rest.list) File "D:\svnwork\exception\gen

Re: AW: Subversion Exception!

der or Folder1 I got this exception. I removed Folder1 in repository using Repo-browser, tried to update again and got the same exception. So the only way to quick solve this problem was recreate repository. I don't know what led to this exception, but my teammate haven't any probl

AW: Subversion Exception!

Hi, Alexander, Von: Alexander A. Boyko [mailto:alexander.bo...@gmail.com] > > --- > Subversion Exception! > --- > Subversion encountered a serious problem. > Please take the time to report this on the Subversion mailing l

  1   2   >