next planned release

Hi, I was wondering if there are any plans to make a new release of Subversion? I'm asking because until now I made new TSVN releases in sync with Subversion. But now with Win11 out I'd like to make a new release so users can make use of some new features which are helpful for Win11. It's been

Re: Hide experimental APIs to unblock 1.11 release

On Thu, Sep 20, 2018 at 10:13 PM Julian Foad wrote: > Julian Foad wrote: > > Stefan Kueng wrote: > > > but then that would mean I wouldn't get any compiler > > > error if I actually use a private and not just an experimental API. > > > > That's part of the point -- [...] > > there's no real

Re: handling of reparse points

On Sat, May 26, 2018 at 7:35 AM Stefan Küng wrote: > Next try, patch attached. > Basically what this does is to never check for soft/hard links on Windows > ever. Since Subversion doesn't really handle those on Windows anyway, > checking for them doesn't make sense and causes proble

Re: handling of reparse points

. Stefan On Fri, May 25, 2018 at 8:30 PM Stefan Kueng <tortoise...@gmail.com> wrote: > > > On 25.05.2018 18:07, Daniel Shahaf wrote: > > Stefan Küng wrote on Fri, 25 May 2018 17:37 +0200: > >> Can anyone comment on this please? > > > > I'm not familiar w

Re: wish for new API or extended one

On Sat, Feb 4, 2017 at 8:25 PM, Stefan Kueng <tortoise...@gmail.com> wrote: > > > On 04.02.2017 19:52, Stefan Sperling wrote: > >> On Sat, Feb 04, 2017 at 07:21:50PM +0100, Stefan Sperling wrote: >> >>> On Sat, Feb 04, 2017 at 04:57:45PM +0100, Stef

Re: wish for new API or extended one

On Sat, Feb 4, 2017 at 4:41 PM, Stefan Kueng wrote: > > > On 04.02.2017 14:12, Stefan Sperling wrote: > >> On Sat, Feb 04, 2017 at 01:45:10PM +0100, Stefan Kueng wrote: >> >>> On 04.02.2017 11:16, Stefan Sperling wrote: >>> On Sat, Feb 04, 2017 at 09:23:06AM +0100,

Crash when reverting

Hi, here's a short way to trigger a crash: svn co http://server/svn/trunk wcfolder svn mkdir wcfolder/folder echo file1 wcfolder/folder/file svn add wcfolder svn ci -m wcfolder svn mv wcfolder/folder/file wcfolder/file svn rm wcfolder/folder crash here: svn revert -R wcfolder/folder This

export fails without error for file externals

Hi, The following command fails without an error: $ svn export -rBASE fileexternal exportedfile with 'fileexternal' being an svn:external to a file. Shouldn't that at least report an error that nothing is done at all instead of just exit silently? Stefan -- ___ oo // \\ De

Re: crash in svn_ra_serf__credentials_callback

On 09.08.2013 21:02, Lieven Govaerts wrote: Hi, these crashes can be explained by serf issue 120: Error with ssl tunnel over proxy with KeepAlive off and Basic authentication. We're assuming here that these users were using a proxy with KeepAlive Off active (at least for the CONNECT request),

Re: Crash when committing in 1.8.1

This one is now the top crash in 1.8.1, counting at 128 crashes so far. Can someone please have a closer look? https://www.crash-server.com/Problem.aspx?ClientID=tsvnProblemID=31454 On Mon, Jul 29, 2013 at 7:53 PM, Stefan Küng tortoise...@gmail.com wrote: Hi, Another strange crash when

Re: Crash still happening in 1.8.1

This crash is coming in second, counting 78 crashes so far. Please have a look: https://www.crash-server.com/Problem.aspx?ClientID=tsvnProblemID=31431 Stefan On Fri, Jul 26, 2013 at 6:15 PM, Stefan Küng tortoise...@gmail.com wrote: Hi, Another crash that's climbing up the ranks

crash when merging in 1.8.1

Hi, a crash happens when merging in 1.8.1 with the following stack trace: libsvn_tsvn.dll!filter_log_entry_with_rangelist(void * baton=0x005513aabf38, svn_log_entry_t * log_entry=0x005513a919b8, apr_pool_t * pool=0x8080808080808080) Line 1400C

crash in 1.8.1 on commit

Hi, crash reports for 1.8.1 are coming in now. Top crash right now is this: https://www.crash-server.com/Problem.aspx?ClientID=tsvnProblemID=31426 libsvn_tsvn.dll!svn_path_join_internal(const char * base=0xfcfcc6f7, const char * component=0x, apr_pool_t *

Crash still happening in 1.8.1

Hi, Another crash that's climbing up the ranks in the crash reports is one I've reported for 1.8.0 here: http://thread.gmane.org/gmane.comp.version-control.subversion.devel/142982 https://www.crash-server.com/Problem.aspx?ClientID=tsvnProblemID=31431 libapr_tsvn!utf8_to_unicode_path+0x23

config dir and svn_config_walk_auth_data

Hi, In TSVN I'm using the API svn_config_walk_auth_data(). Unfortunately, I'm passing NULL as the first parameter (the config dir path). Back when I implemented this, passing NULL worked just fine. Now it doesn't anymore - I forgot to test this with the 1.8.0 release, my fault. The reason

crash in svn_ra_serf__credentials_callback

Hi, And yet another crash, this time in svn_ra_serf__credentials_callback: https://www.crash-server.com/Problem.aspx?ClientID=tsvnProblemID=31507 libsvn_tsvn.dll!svn_ra_serf__credentials_callback(char * * username=0x, char * * password=0x0191, serf_request_t *

Re: crash in svn_ra_serf__credentials_callback

On 26.07.2013 19:34, Lieven Govaerts wrote: On Fri, Jul 26, 2013 at 7:24 PM, Stefan Küng tortoise...@gmail.com wrote: Hi, And yet another crash, this time in svn_ra_serf__credentials_callback: https://www.crash-server.com/Problem.aspx?ClientID=tsvnProblemID=31507 libsvn_tsvn.dll

Re: config dir and svn_config_walk_auth_data

On 26.07.2013 19:32, Branko Čibej wrote: On 26.07.2013 19:19, Stefan Küng wrote: Hi, In TSVN I'm using the API svn_config_walk_auth_data(). Unfortunately, I'm passing NULL as the first parameter (the config dir path). Back when I implemented this, passing NULL worked just fine. Now it doesn't

Re: [PATCH] Crash in TSVN with directory property conflict during update (was Re: Another crash in ra_serf in 1.8.0)

On 23.06.2013 15:07, Lieven Govaerts wrote: Stefan, this issue is unrelated to ssl tunnelling or authentication, or more in general unrelated to ra_serf. The particular scenario here is a user updating a directory with both local property changes and incoming property changes. Svn then calls

crash showing log in 1.8.0

Hi, Another one from the crash reports: in libsvn_client\log.c, line 715, function run_ra_get_log(): matching_segment = bsearch(younger_rev, log_segments-elts, log_segments-nelts, log_segments-elt_size, compare_rev_to_segment);

Re: Another crash in ra_serf in 1.8.0

On 20.06.2013 23:05, Lieven Govaerts wrote: Looks like it's the authentication handling when setting up a SSL tunnel that's at fault here, at least I can easily reproduce it with an apache http proxy connetion to a https repo. The ssl tunnel is started by a CONNECT request created by serf.

Re: error checking out in TortoiseSVN

On 20.06.2013 16:20, Daniel Shahaf wrote: Does Tortoise apply any patches to its binaries? That is, the svn.exe Bart used contain any code not in our tag? No, it's a plain svn.exe without any patches. The only difference is how it's built: instead of a dll for each lib there's only one dll

Re: error checking out in TortoiseSVN

On 20.06.2013 17:02, Bart van Oerle wrote: I created and uploaded a dump file (damn it's big), I hope this will help you guys solving the problem. http://www.sendspace.com/file/8m1osy Here's the stack trace: BowPad TortoiseProc.exe!svn_error_handle_malfunction(int can_return=0, const char *

Another crash in ra_serf in 1.8.0

Hi, Another crash that's climbing up in the crash report statistics for TSVN. Seems to be related to the previously discussed problem with checkouts in TSVN. The stack trace: BowPad libsvn_tsvn.dll!svn_ra_serf__credentials_callback(char * * username=0x, char * *

Re: Should missing smart card support not be added in the release notes?

On 05.06.2013 09:11, Lieven Govaerts wrote: First, you have to compile OpenSSL with CAPI enabled. The default build does not use this. There are two build flags for the CAPI engine in OpenSSL. The first one simply activates the engine, but it only works if the smartcard has only one certificate

Re: svn commit: r1489203 - /subversion/trunk/subversion/libsvn_client/merge.c

On 04.06.2013 17:50, Julian Foad wrote: Greg Stein wrote: Would %s@%ld and %s@%ld must have a common ancestor be easier to translate? The term ancestrally related seems a bit complicated for translation :-P Your suggestion is a better message, I agree. The present error code and error

Re: Should missing smart card support not be added in the release notes?

On 04.06.2013 13:56, Lieven Govaerts wrote: You are referring to a configuration where OpenSSL uses MS's CryptoAPI to use the Windows certificate store. Never used it myself, but I see that TSVN has implemented this, with an extra dialog to select a client certificate if multiple were found. I

crash when diffing, using 1.8.x

Hi, Easy to reproduce: $ cd workingcopy $ svn diff . --internal-diff If you pass --internal-diff, then svn_config_set() is called with NULL as the value to remove it. However when doing the diff, config.c, make_string_from_option later uses that NULL value: if (strchr(opt-value, '%'))

segfault when reverse merging in trunk

Hi, using a build from todays trunk: $ svn co http://tortoisesvn.googlecode.com/svn/trunk/contrib/diff-scripts wc $ cd wc $ svn merge -r23995:23994 http://tortoisesvn.googlecode.com/svn/trunk/contrib/diff-scripts/diff-doc.js diff-doc.js this segfaults in libsvn_client/merge.c, line 7407

Re: segfault when reverse merging in trunk

On 15.03.2013 18:46, Paul Burba wrote: On Fri, Mar 15, 2013 at 1:23 PM, Stefan Küng tortoise...@gmail.com wrote: Hi, using a build from todays trunk: $ svn co http://tortoisesvn.googlecode.com/svn/trunk/contrib/diff-scripts wc $ cd wc $ svn merge -r23995:23994 http

Re: segfault when reverse merging in trunk

On 15.03.2013 18:59, Paul Burba wrote: On Fri, Mar 15, 2013 at 1:52 PM, Stefan Küng tortoise...@gmail.com wrote: On 15.03.2013 18:46, Paul Burba wrote: On Fri, Mar 15, 2013 at 1:23 PM, Stefan Küng tortoise...@gmail.com wrote: Hi, using a build from todays trunk: $ svn co http

Re: segfault when reverse merging in trunk

On 15.03.2013 19:29, Paul Burba wrote: [snip] C:\SVN\diff-scripts-1.8-devsvn merge -r24000:23999 http://tortoisesvn.googlecode.com/svn/trunk/contrib/diff-scripts/diff-xls.js diff-xls.js Argh! I forgot the --ignore-ancestry flag: you have to pass --ignore-ancestry when merging, then it

Re: svn_client_move7 and mixed-revisions

On 12.03.2013 20:48, Philip Martin wrote: Bert Huijben b...@qqmail.nl writes: To an api user that is halfway through a refactoring, you can’t say: you can’t move this file directory. Go undo everything you did before. Not undo, run update. If update brings in no changes and just bumps

svn add and inconsistent line endings

Hi, When auto-props are set up for e.g., cpp files that set the svn:eol-style property, adding those files is not possible if the file has inconsistent line endings. The --force flag won't help either, the only way to add the file is to first fix the line endings in an editor. Or add the

Re: svn add and inconsistent line endings

On 24.02.2013 16:47, Bert Huijben wrote: -Original Message- From: Stefan Küng [mailto:tortoise...@gmail.com] Sent: zondag 24 februari 2013 15:39 To: Subversion Development Subject: svn add and inconsistent line endings Hi, When auto-props are set up for e.g., cpp files that set

Re: svn add and inconsistent line endings

On 24.02.2013 18:56, Bert Huijben wrote: -Original Message- From: Stefan Küng [mailto:tortoise...@gmail.com] Sent: zondag 24 februari 2013 17:01 To: Bert Huijben Cc: 'Subversion Development' Subject: Re: svn add and inconsistent line endings On 24.02.2013 16:47, Bert Huijben wrote

Re: svn add and inconsistent line endings

On 24.02.2013 19:29, Bert Huijben wrote: Are you sure the file is adjusted? Looking at the code it appears we just skip the check (and many others for other properties). You're right. And I just tested: even if the property is set (indicating inconsistent eols should be either ignored or

Re: svn add and inconsistent line endings

On 24.02.2013 19:42, Branko Čibej wrote: Regarding automatcially changing line endings -- we don't do that for a very good reason: it's always been Subversion's policy to not touch file contents unless explicitly told to do so. The line endings could be inconsistent for reasons beyond

Re: svn add and inconsistent line endings

On 24.02.2013 20:45, Branko Čibej wrote: On 24.02.2013 19:47, Stefan Küng wrote: On 24.02.2013 19:42, Branko Čibej wrote: Regarding automatcially changing line endings -- we don't do that for a very good reason: it's always been Subversion's policy to not touch file contents unless explicitly

Re: problems with merging

On 30.01.2013 03:17, Julian Foad wrote: Stefan Küng wrote on 2013-01-27: using a build from the svn trunk (as of r1439016), I've discovered a few problems when merging. svn co -r23862 https://tortoisesvn.googlecode.com/svn/branches/1.7.x/src tsvnsrc cd tsvnsrc Now for the merge: svn merge

Error running context

Hi, Using an svn build of trunk from about two hours ago, I'm trying to commit a binary file to the TSVN repository on Google code. Tried several times, and others have the same problem when they try to commit this file. Here's how to reproduce: $ svn co

Re: problems committing with serf

On 23.11.2012 17:20, Philip Martin wrote: Stefan Küng tortoise...@gmail.com writes: Sending. svn: E175002: Commit failed (details follow): svn: E175002: MKACTIVITY request on '/svn/!svn/act/4b7f5c8e-5e27-f145-929b-dfe9f 7297de5' failed: 405 Method Not Allowed svn: E175002: DELETE

Re: serf in 1.8

On 13.11.2012 14:58, Mark Phippard wrote: We did some testing in our lab, and the KeepAlive settings help a lot here. Without any KeepAlive, then obviously every Serf request on every connection needed to be re-authenticated. With KeepAlive on and the connection limit set high enough then it

Re: serf in 1.8

On 13.11.2012 20:48, Mark Phippard wrote: On Tue, Nov 13, 2012 at 2:44 PM, Stefan Küng tortoise...@gmail.com wrote: On 13.11.2012 14:58, Mark Phippard wrote: We did some testing in our lab, and the KeepAlive settings help a lot here. Without any KeepAlive, then obviously every Serf request

Re: serf in 1.8

On 13.11.2012 21:03, Mark Phippard wrote: On Tue, Nov 13, 2012 at 2:48 PM, Mark Phippard markp...@gmail.com wrote: On Tue, Nov 13, 2012 at 2:44 PM, Stefan Küng tortoise...@gmail.com wrote: On 13.11.2012 14:58, Mark Phippard wrote: We did some testing in our lab, and the KeepAlive settings

segfault when merging

Hi, There were quite a few crash reports sent for TSVN which indicate a problem when merging. Until now I never really had a good crash dump and also no user to contact. But now that's changed: User report is here:

Re: Regular expressions in Subversion

On 17.10.2012 18:20, Hyrum K Wright wrote: There are several places where regular expressions would be useful in Subversion. Off hand, the new log --search feature and svn:ignore properties feel like they'd be use candidates for regexs, and they could probably also apply to authz rules

Re: Regular expressions in Subversion

On 17.10.2012 20:17, Stefan Sperling wrote: On Wed, Oct 17, 2012 at 12:20:20PM -0400, Hyrum K Wright wrote: There are several places where regular expressions would be useful in Subversion. Off hand, the new log --search feature and svn:ignore properties feel like they'd be use candidates for

Re: crash in latest release

On 09.10.2012 22:35, Johan Corveleyn wrote: I used a release build (I always test with a release build), built with Visual C Express 2008 on Windows XP. But indeed, it might depend on the build ... I was probably lucky, or unlucky, depending on how you look at it :-/ ... try this: $ svn log

Re: crash in latest release

On 10.10.2012 20:22, Bert Huijben wrote: -Original Message- From: Stefan Küng [mailto:tortoise...@gmail.com] Sent: woensdag 10 oktober 2012 18:40 To: Johan Corveleyn Cc: dev@subversion.apache.org Subject: Re: crash in latest release On 09.10.2012 22:35, Johan Corveleyn wrote: I

crash in latest release

Hi, Just got the first crash report for the TSVN 1.7.10 release (svn 1.7.7). Considering that the release is only an hour old, that indicates that I will get a lot more of those... Problem in libsvn_subr/win32_crypto.c, function windows_password_decrypter(svn_boolean_t *done, ...): ...

Re: crash in latest release

On 09.10.2012 22:15, Branko Čibej wrote: On 09.10.2012 21:49, Stefan Küng wrote: Hi, Just got the first crash report for the TSVN 1.7.10 release (svn 1.7.7). Considering that the release is only an hour old, that indicates that I will get a lot more of those... Problem in libsvn_subr

Re: crash in latest release

On 09.10.2012 22:25, Johan Corveleyn wrote: On Tue, Oct 9, 2012 at 10:15 PM, Branko Čibej br...@wandisco.com wrote: On 09.10.2012 21:49, Stefan Küng wrote: Hi, Just got the first crash report for the TSVN 1.7.10 release (svn 1.7.7). Considering that the release is only an hour old

Re: svn commit: r1382028 - in /subversion/trunk/subversion: include/svn_config.h libsvn_subr/cmdline.c libsvn_subr/config_file.c

On 07.09.2012 16:07, Mark Phippard wrote: On Fri, Sep 7, 2012 at 10:04 AM, C. Michael Pilato cmpil...@collab.net mailto:cmpil...@collab.net wrote: On 09/07/2012 09:57 AM, Mark Phippard wrote: Shouldn't this default to 'yes' to match the current behavior? I went with Joe Orton's

Re: svn commit: r1382028 - in /subversion/trunk/subversion: include/svn_config.h libsvn_subr/cmdline.c libsvn_subr/config_file.c

On 07.09.2012 16:51, C. Michael Pilato wrote: On 09/07/2012 10:14 AM, Stefan Küng wrote: On 07.09.2012 16:07, Mark Phippard wrote: On Fri, Sep 7, 2012 at 10:04 AM, C. Michael Pilato cmpil...@collab.net mailto:cmpil...@collab.net wrote: On 09/07/2012 09:57 AM, Mark Phippard wrote

Re: thread safe

On Wed, Sep 5, 2012 at 1:14 AM, Branko Čibej br...@wandisco.com wrote: On 04.09.2012 22:24, Stefan Küng wrote: Attached is my first draft of the new svn_config_dup() API. * it does not return an svn_error_t but the duplicate hash directly. The only API call that could return an error

Re: thread safe

On Wed, Sep 5, 2012 at 3:54 PM, Branko Čibej br...@wandisco.com wrote: As I said, the return value must be a svn_config_t*. More comments below (I'll ignore coding style). Why must it be an svn_config_t* ? That makes no sense: we want to duplicate the config hash. Ah, I begin to understand;

Re: thread safe

Here's my attempt to implement two new APIs to duplicate an svn_config_t and a hash of those. I factored out some code from svn_config_set into two new helper functions which I then used in the new dup functions. Please review. Stefan -- ___ oo // \\ De Chelonian Mobile

Re: thread safe

On 04.09.2012 20:31, Branko Čibej wrote: On 04.09.2012 19:33, Stefan Küng wrote: On 03.09.2012 22:21, Branko Čibej wrote: On 03.09.2012 22:16, Stefan Küng wrote: On 03.09.2012 22:11, Branko Čibej wrote: Either that, or add a new API that creates a deep-copy of the in-memory svn_config_t

Re: thread safe

Attached is my first draft of the new svn_config_dup() API. * it does not return an svn_error_t but the duplicate hash directly. The only API call that could return an error is svn_config_create() but that API also returns SVN_NO_ERROR unconditionally (for now at least). * no error checking is

thread safe

Hi, It seems that the svn_config_t structure isn't thread safe, i.e. can't be shared among multiple threads. See here for a detailed report on what problems this causes: http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757dsMessageId=3003152 Is this by design? I assumed that all svn

Re: thread safe

On 03.09.2012 21:09, Bert Huijben wrote: -Original Message- From: Stefan Küng [mailto:tortoise...@gmail.com] Sent: maandag 3 september 2012 20:48 To: Subversion Development Subject: thread safe Hi, It seems that the svn_config_t structure isn't thread safe, i.e. can't be shared

applying git patches

Hi, I'm trying to fix a problem when applying certain git patches. While analyzing the code, I found a part that I don't quite understand: in libsvn_diff\parse-diff.c, line 1287 there's this little bit of code: /* Run the state machine. */ for (i = 0; i (sizeof(transitions) /

Re: [Issue 4124] New - Give servers sufficient means to disallow commits from clients based on version numbers

On Thu, Aug 16, 2012 at 4:46 PM, Cedric JP. Brasey cedric.bra...@planet-side.co.uk wrote: Just my two pence worth... From a hooking point; I would have to say that i would only really care about what the client level is. For example. On pre-commit i would like to know if the client is at

identical repository uuid

Hi, Just stumbled upon something that shouldn't happen: both neon and serf repositories have the very same repository uuid: 61a7d7f5-40b7-0310-9c16-bb0ea8cb1845 you can check yourself with svn info http://serf.googlecode.com/svn and svn info http://svn.webdav.org/repos/projects Since the

Re: identical repository uuid

On 08.08.2012 21:45, Mark Phippard wrote: On Wed, Aug 8, 2012 at 3:40 PM, Stefan Küng tortoise...@gmail.com wrote: Just stumbled upon something that shouldn't happen: both neon and serf repositories have the very same repository uuid: 61a7d7f5-40b7-0310-9c16-bb0ea8cb1845 you can check

crash dumps

Hi, Since there are quite a few crash reports sent for TSVN which are due to bugs/problems in the svn library, I've set up a page where all the svn related bugs are shown in one place: https://www.crash-server.com/SearchResult.aspx?ClientID=tsvnBugOwnerID=26 Please have a look at least at

Re: why does tortoise, wcng and cygwin break from icon caching?

On 06.07.2012 14:41, Johan Corveleyn wrote: Ok, but I suppose that's mainly because of eol-style=native issues: your cygwin client may have a different idea about what the native eol-style is ... I don't think locking of the working copy (or working copy database) has been considered when this

crash in svn_client_url_from_path2

Hi, There's an access violation happening in svn_client_url_from_path2(). Stacktrace attached. Seems there's a situation where work_del_relpath can be NULL. Can't figure out however what that situation exactly is. Crash dump available here:

Re: crash in svn_client_url_from_path2

On 18.06.2012 21:37, Daniel Shahaf wrote: I think it's a bug to pass url=NULL to svn_client_url_from_path2(). Are you saying there is another bug here? I never pass NULL. Even if the call to svn_dirent_canonicalize() would return NULL I still pass an empty string in that situation. Stack

access violation fetching status

Hi, An access violation (strlen() for NULL) happens when fetching the status. Stacktrace attached. 16 crash dumps available here: https://www.crash-server.com/Problem.aspx?ClientID=tsvnProblemID=1504 Stefan -- ___ oo // \\ De Chelonian Mobile (_,\/ \_/ \ TortoiseSVN \

Re: access violation fetching status

On 10.06.2012 12:55, Bert Huijben wrote: When I look at the stack trace in this mail it appears that you call the status function with a NULL path. Why shouldn’t that fail at some level? You are supposed to provide a path, not NULL to our api  (I’m not sure if we can trust the rest of the

Re: multiple crashes

On Fri, May 25, 2012 at 3:43 PM, Stefan Küng tortoise...@gmail.com wrote: On 25.05.2012 10:54, Philip Martin wrote: Stefan Küngtortoise...@gmail.com  writes: libsvn_tsvn32!svn_relpath_join+0x10 libsvn_tsvn32!svn_wc__internal_get_origin+0x1b2 libsvn_tsvn32!svn_client_commit5+0x14d3

crash in 'svn st -u'

Hi, here's another one from the crash reports sent for TSVN: When doing an 'svn st -u' there's a crash happening in svn_relpath_join(). Stacktrace attached. in status.c:1579, make_file_baton() there's this: f-repos_relpath = svn_relpath_join(find_dir_repos_relpath(pb, pool),

abort on 'svn st'

Hi, Another one from the TSVN crash reports: Several reports because of a call to SVN_ERR_MALFUNCTION_NO_RETURN() when doing an 'svn st'. Stacktrace attached. The call is in libsvn_subr/token.c:51 int svn_token__from_word_strict(const svn_token_map_t *map, const

crash when upgrading wc

Hi, Again a post about some crash dumps that were sent for TSVN: When upgrading a working copy, there's an abort() called here: subversion\subversion\libsvn_wc\util.c, 300： (svn_uri_is_canonical(repos_url, pool) svn_relpath_is_canonical(path_in_repos) SVN_IS_VALID_REVNUM(peg_rev)) problem

Re: multiple crashes

On 25.05.2012 10:54, Philip Martin wrote: Stefan Küngtortoise...@gmail.com writes: libsvn_tsvn32!svn_relpath_join+0x10 libsvn_tsvn32!svn_wc__internal_get_origin+0x1b2 libsvn_tsvn32!svn_client_commit5+0x14d3 libsvn_tsvn32!svn_client__harvest_committables+0x26a

Re: Compiling SVN on Windows using Windows SDK

On 24.05.2012 21:55, Mark Phippard wrote: I know we have done work in recent versions so that you can compile SVN on Windows using just the freely available Windows SDK. Note that Microsoft is changing things so that this will no longer be possible. This is just a heads-up for anyone who is

multiple crashes

Hi, Our crash reporting tool already gathered a few crashes in the svn library. 22 reports are already in with access violations in svn_relpath_join(). those 22 reports are in two crash groups, but from the stack traces there are four problems that cause these crashes:

crash in commit

Hi, There's a crash happening when committing. The stacktrace: libsvn_tsvn!svn_relpath_join+0x35 libsvn_tsvn!svn_wc__internal_get_origin+0x270 libsvn_tsvn!svn_wc__node_get_origin+0x6e libsvn_tsvn!svn_client_commit5+0x197c libsvn_tsvn!svn_client__harvest_committables+0x2a7

Re: crash in commit

On 04.05.2012 21:06, Greg Stein wrote: svn_relpath_join() takes two strings and a pool. What are the pointer values for those parameters? I'm assuming one of those strings is NULL. Which? The first one is NULL: apr_size_t blen = strlen(base); is where the access violation accessing 0x000

Re: Use 1.7.7 for next release

. To summarize, the next release will be called 1.7.5 and Stefan Küng will change tsvn's versioning scheme to %d.%d.%d-%d % (SVN_VER_MAJOR, SVN_VER_MINOR, SVN_VER_PATCH, tsvn_counter++). Thanks for raising this (and thanks Stefan for the fix his end). Ahem: as I said I can not go back a version

Re: Use 1.7.7 for next release

On 14.04.2012 21:31, Blair Zajac wrote: On 4/14/12 12:24 PM, Konstantin Kolinko wrote: 2012/4/12 Daniel Shahafdanie...@apache.org: We released 1.6.18 today and 1.7.4 just over a month ago. There are a few useful items merged already, and STATUS has a truckload of pending changes. Shall we

Re: Use 1.7.7 for next release

On 14.04.2012 22:28, Greg Stein wrote: I have a proposal: Skip several numbers and name the next release as 1.7.7. Justification: to align with TortoiseSVN, which is 1.7.6 now. There is a lot of Subversion exception! threads on users@ where TortoiseSVN version is visible. For example [1]. I

Re: Use 1.7.7 for next release

On 14.04.2012 22:40, Hyrum K Wright wrote: On Sat, Apr 14, 2012 at 3:36 PM, Stefan Küngtortoise...@gmail.com wrote: On 14.04.2012 22:28, Greg Stein wrote: I have a proposal: Skip several numbers and name the next release as 1.7.7. Justification: to align with TortoiseSVN, which is 1.7.6

Re: Use 1.7.7 for next release

On 14.04.2012 23:46, Greg Stein wrote: So I'll keep the first three version numbers the same in the future for interim releases (in case I have to create one). But I guess if you want to improve the current situation, there's not much I can do. Hyrum is suggesting we release 1.7.5, and

Re: SVN_ERR_ASSERT with reintegrate

On 27.03.2012 12:06, Julian Foad wrote: Stefan Küngtortoise...@gmail.com wrote: There's an SVN_ERR_ASSERT when reintegrating. From the crash statistics I get this happens quite often. The stack trace: libsvn_tsvn!svn_ra_get_location_segments+0x12

SVN_ERR_ASSERT with reintegrate

Hi, There's an SVN_ERR_ASSERT when reintegrating. From the crash statistics I get this happens quite often. The stack trace: libsvn_tsvn!svn_ra_get_location_segments+0x12 libsvn_tsvn!svn_client__repos_location_segments+0x9f libsvn_tsvn!svn_client_merge4+0xff8

crash when commiting

Hi, I'm going through some crash reports sent for TSVN and I found a crash that happens when committing, and the wc has some incomplete entries: libsvn_wc/node.c, svn_wc__internal_get_origin(). SVN_ERR(svn_wc__db_scan_addition(status, op_root_abspath, NULL,

Re: crash when commiting

On 09.03.2012 20:06, Philip Martin wrote: Stefan Küngtortoise...@gmail.com writes: I'm going through some crash reports sent for TSVN and I found a crash that happens when committing, and the wc has some incomplete entries: libsvn_wc/node.c, svn_wc__internal_get_origin().

crash when committing

Hi, I'm going through some crash reports sent for TSVN and I found a crash that happens when committing, and the wc has some incomplete entries: libsvn_wc/node.c, svn_wc__internal_get_origin(). SVN_ERR(svn_wc__db_scan_addition(status, op_root_abspath, NULL,

Re: [patch] applying patch can fail with dry_run

On 16.01.2012 11:34, Philip Martin wrote: Philip Martinphilip.mar...@wandisco.com writes: Now I can reproduce the error. So the problem occurs when we have a patch file with one item that adds two levels of directories and another item that deletes a file: Index: wc/A/B/f

Re: [patch] applying patch can fail with dry_run

On 12.01.2012 22:34, Philip Martin wrote: Stefan Küngtortoise...@gmail.com writes: $ svn co https://triplea.svn.sourceforge.net/svnroot/triplea/trunk wc -r3375 $ svn patch test.patch wc --dry-run No error on my machine, it would simply create wc/src, and does without --dry-run. why would

[patch] applying patch can fail with dry_run

Hi, When applying a patch in dry-run mode, svn can return an error even if the patching would work just fine. The returned error is then: The Node /newDirectory was not found If you want to reproduce this, here's the mailing list thread on the TSVN mailing list:

Re: [patch] applying patch can fail with dry_run

On 12.01.2012 21:13, Philip Martin wrote: Stefan Küngtortoise...@gmail.com writes: Question is: do we need the notifications for deleting empty dirs in a dry-run? If yes, then this get's complicated: the error is thrown from svn_wc_walk_status() called in check_dir_empty. I could just not

Re: svn ls performance

On 05.01.2012 01:25, Philip Martin wrote: Konstantin Kolinkoknst.koli...@gmail.com writes: 2012/1/5 Stefan Küngtortoise...@gmail.com: Hi, Due to a report on the TSVN mailing list I found that the CL client has the same problem: 'svn list' takes forever in some situations. I don't know what

Crash when updating

Hi, From a crash report dump sent for TSVN for an update the attached stack trace happened. libsvn_wc\props.c, svn_wc__merge_props() to_val = incoming_change-value ? svn_string_dup(incoming_change-value, result_pool) : NULL; if (! from_val) /* adding a new property

Re: [RFC] Server Dictated Configuration

On 03.01.2012 23:58, Paul Burba wrote: Mike Pilato and I have been kicking around some ideas on server dictated configuration recently and have put our thoughts into a wiki (full disclosure: this wiki was initially based on Hyrum's thoughts on the subject in

svn ls performance

Hi, Due to a report on the TSVN mailing list I found that the CL client has the same problem: 'svn list' takes forever in some situations. I don't know what the problem exactly is, but it's easily reproducable: svn ls http://plugins.svn.wordpress.org/ -v --depth=immediates prints one entry,

Re: crash fetching status

On Thu, Dec 29, 2011 at 16:57, Stefan Küng tortoise...@gmail.com wrote: On 29.12.2011 16:43, Hyrum K Wright wrote: On Wed, Dec 28, 2011 at 1:01 AM, Stefan Küngtortoise...@gmail.com  wrote: I looked at similar places elsewhere, and they seemed to follow a pattern.  The following patch

  1   2   3   >