On 27.07.2011 20:43, Lieven Govaerts wrote:
On Wed, Jul 27, 2011 at 4:23 PM, Stefan Küng<tortoise...@gmail.com> wrote:
On Tue, Jul 26, 2011 at 22:56, Mark Phippard<markp...@gmail.com> wrote:
I have been using 1.7 exclusively now on all systems. I am using it from
Subclipse, command line and TortoiseSVN. I am very happy with it from my
own usage and I would be +1 on a RC.
I have not been following all of the items that have gone through STATUS. I
know there have been a LOT of nice bugs and fixes caught and there will
likely be more. But I do not recall any of the type that we would have had
to overly rush to get a 1.7.1 out if they had made into a release.
I personally think that Neon should be our default for 1.7 and would like to
see us make that change. However, given that just about everyone that
produces binaries for download seems likely to patch the code so that Neon
is the default anyway, it is not something I am going to fight for. It
might even give us the best of both worlds. Most users will still be using
Neon but given that Serf is the default in the source code there will still
be a lot more users using it and filing bugs.
Just as an info:
I too had to switch back to neon for the TSVN nightly builds. The beta
release of TSVN was built with serf as the default, and we already had
a lot of reports where checkouts failed, listing repositories failed,
authentication crashed (found from sent crash dump files), ....
Hm, I don't seem to find those reports on the tsvn-devs, tsvn-users
mailing lists or issue tracker (at a glance).
this one:
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2804543
got magically fixed once he used a nightly where neon is the default.
also got two crash dumps where serf was used. Contacted the users who
sent the reports, asked them to retry with neon and that then worked.
Also one user from who tested the beta for his company had suddenly
problems with authentication (SSPI, Kerberos) and switching to neon
solved that as well (not on the mailing list, I guess some people just
are more comfortable mailing me directly).
Can you forward ra_serf-related core dumpts to svn-dev?
Here's the stack trace of the two dumps I got for serf (stack trace is
identical, but two different users and urls):
> libsvn_tsvn32.dll!checkout_dir(dir_context_t * dir=0x0225ac50) Line
380 + 0x1b bytes C
libsvn_tsvn32.dll!do_item_commit(void * * dir_baton=0x02ddfa00, void
* parent_baton=0x0225ac50, void * callback_baton=0x02ddfa58, const char
* path=0x021924c0, apr_pool_t * pool=0x02258c08) Line 1577 + 0x26 bytes C
libsvn_tsvn32.dll!svn_delta_path_driver(const svn_delta_editor_t *
editor=0x021ba850, void * edit_baton=0x021ba6a0, long revision=-1, const
apr_array_header_t * paths=0x021ba960, svn_error_t * (void * *, void *,
void *, const char *, apr_pool_t *)* callback_func=0x10007de0, void *
callback_baton=0x02ddfa58, apr_pool_t * pool=0x02187870) Line 257 +
0x13 bytes C
libsvn_tsvn32.dll!svn_client__do_commit(const char *
base_url=0x021923e0, const apr_array_header_t * commit_items=0x021ba960,
const svn_delta_editor_t * editor=0x021ba850, void *
edit_baton=0x021ba6a0, const char * notify_path_prefix=0x00000000,
apr_hash_t * * md5_checksums=0x00000000, apr_hash_t * *
sha1_checksums=0x00000000, svn_client_ctx_t * ctx=0x0145bc68, apr_pool_t
* result_pool=0x02187870, apr_pool_t * scratch_pool=0x02187870) Line
1805 + 0x35 bytes C
libsvn_tsvn32.dll!wc_to_repos_copy(const apr_array_header_t *
copy_pairs=0x021878b0, int make_parents=0, const apr_hash_t *
revprop_table=0x00000000, svn_error_t * (const svn_commit_info_t *, void
*, apr_pool_t *)* commit_callback=0x0051723d, void *
commit_baton=0x0012ef98, svn_client_ctx_t * ctx=0x0145bc68, apr_pool_t *
pool=0x00000000) Line 1460 + 0x1b bytes C
libsvn_tsvn32.dll!try_copy(const apr_array_header_t *
sources=0x00000000, const char * dst_path_in=0x011cf868, int is_move=0,
int make_parents=0, int ignore_externals=0, const apr_hash_t *
revprop_table=0x00000000, svn_error_t * (const svn_commit_info_t *, void
*, apr_pool_t *)* commit_callback=0x0051723d, void *
commit_baton=0x0012ef98, svn_client_ctx_t * ctx=0x0145bc68, apr_pool_t *
pool=0x02187870) Line 2278 C
libsvn_tsvn32.dll!svn_client_copy6(const apr_array_header_t *
sources=0x01445ce8, const char * dst_path=0x011cf868, int
copy_as_child=0, int make_parents=0, int ignore_externals=0, const
apr_hash_t * revprop_table=0x00000000, svn_error_t * (const
svn_commit_info_t *, void *, apr_pool_t *)* commit_callback=0x0051723d,
void * commit_baton=0x0012ef98, svn_client_ctx_t * ctx=0x0145bc68,
apr_pool_t * pool=0x02175520) Line 2311 + 0x2d bytes C
crash is in libsvn_ra_serf\commit.c, line 380:
dir->parent_dir->checkout is NULL.
The copy operation was WC->Url, i.e. creating a branch from a working
copy. The one user who responded to my questions mentioned that the
working copy had local modifications. But I couldn't get more info out
of him.
Another crash dump with serf didn't show much info because it corrupted
the heap, so only the first few lines of the stacktrace were actually valid.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
