httpd trunk broken with Subversion: ap_log_rerror busted
In r951893, httpd modified a #define for APLOG_MARK to add in a new parameter called APLOG_MODULE_INDEX (in addition to file and line info). This busts Subversion - specifically, mod_authz_svn which has a function called: static void log_access_verdict(const char *file, int line, const request_rec *r, int allowed, const char *repos_path, const char *dest_repos_path) it is called with: log_access_verdict(APLOG_MARK, r, 1, repos_path, dest_repos_path); Reading the very obtuse (unhelpful) commit log for r951893 as well as any comments in that general area of http_log.h (which are lacking unhelpful), I have no idea what this APLOG_MODULE_INDEX is or why it's even there. Furthermore, this error case is very very hard to track down because we're relying upon multiple levels of #define's and indirections (hidden static variables??, weird STDC wrappers, redefinitions of function names, etc, etc.). So, it's not going to be obvious to downstream developers what is going on and why it is broken. In general, I'm not quite sure it's a good idea to bust a #define that has been the same since the 1.3 days (if not earlier actually). If we want modules to use a new optimized log API, then we should introduce a new optimized log API and not bust the old one in a way that the failure case isn't obvious to track down. Yes, we could fix this by making mod_authz_svn conditional on the new MMN, but - again, it's about even figuring out that the API is changed and what to do about it. The root cause is just way too obscured, IMO. (I wish I could veto this whole commit just on over-complication alone - it's not an elegant solution at all.) My $.02. -- justin
Re: RFC: How should Subversion handle OS-deleted paths?
On Tue, 2010-08-24 at 20:50 +0200, Alan Barrett wrote: On Tue, 24 Aug 2010, Julian Foad wrote: the as-yet-unavailable svn mv --retrospectively command [1], Is this is just a special case of the as-yet-unavailable --metadata-only option, which would tell svn to adjust its metadata as if some operation were performed, but not to touch anything outside the .svn directory (or wherever metadata is kept)? Yes, that's basically what I meant, just aimed at the retrospective subset of the possible use cases. (For anyone not familiar with the history: neither of these options is a planned feature and neither of them yet has a well defined meaning; they are just made-up option names that are convenient reminders for talking about some ideas that have been suggested.) - Julian
RE: httpd trunk broken with Subversion: ap_log_rerror busted
-Original Message- From: justin.erenkra...@gmail.com Sent: Mittwoch, 25. August 2010 08:14 To: d...@httpd.apache.org Cc: Subversion Development Subject: httpd trunk broken with Subversion: ap_log_rerror busted In r951893, httpd modified a #define for APLOG_MARK to add in a new parameter called APLOG_MODULE_INDEX (in addition to file and line info). This busts Subversion - specifically, mod_authz_svn which has a function called: static void log_access_verdict(const char *file, int line, const request_rec *r, int allowed, const char *repos_path, const char *dest_repos_path) it is called with: log_access_verdict(APLOG_MARK, r, 1, repos_path, dest_repos_path); Reading the very obtuse (unhelpful) commit log for r951893 as well as any comments in that general area of http_log.h (which are lacking unhelpful), I have no idea what this APLOG_MODULE_INDEX is or why it's even there. It is needed for setting module specific log levels. Furthermore, this error case is very very hard to track down because we're relying upon multiple levels of #define's and indirections (hidden static variables??, weird STDC wrappers, redefinitions of function names, etc, etc.). So, it's not going to be obvious to downstream developers what is going on and why it is broken. In I admit the code is complex and it needs some time to understand it especially without the parallel information that was part of the discussion on the dev@ list. So improvement proposals to the documentation are welcome to make things easier to understand. Basicly all this stuff is done to use the advanced features of C99 compilers that allow us to check with low effort whether a call to the error logging function is needed at all given the currently configured loglevel. This should improve performance, especially as the new logging API encourages to log even more details as it is now possible to limit the level of log detail to specific modules or even requests. For the gory details the dev@ archives should be consulted. See various threads in March, April and May that all have loglevel in the subject. general, I'm not quite sure it's a good idea to bust a #define that has been the same since the 1.3 days (if not earlier actually). If we want modules to use a new optimized log API, then we should introduce a new optimized log API and not bust the old one in a way that the failure case isn't obvious to track down. The question is if we should consider APLOG_MARK as an isolated item of the logging API or something that works only fine in conjunction with the whole API. When you get through the archives you will see that a lengthy discussion with several patch iterations took place over several months in spring. It was discussed specifically how to keep the pain level low for existing modules that want 1. to use the new features of the API 2. that do not want to use the new features and just keep working as they are by just recompiling them against trunk. The outcome was the current solution that should work fine for 90% or more of the existing modules. Unfortunately mod_authz_svn falls into the 10% where it does not work painless. We have not found a way to do this painlessly for modules that have something like log_access_verdict. These modules need code changes, but as said these were seen as the minor number of cases. Yes, we could fix this by making mod_authz_svn conditional on the new MMN, but - again, it's about even figuring out that the API is changed and what to do about it. The root cause is just way too obscured, IMO. Trunk has a major bump, a major bump was done for this specific change, there is an entry in the changelog for 2.3.6. The only thing that is missing is an entry in http://httpd.apache.org/docs/trunk/new_features_2_4.html in Module Developer Changes section. And yes it should be mentioned there with some hints. But as a whole I think there are a lot of pointers to this API change. (I wish I could veto this whole commit just on over-complication alone - it's not an elegant solution at all.) Please take yourself sometime to catch up with the discussion that took place on the list and you might understand the reasoning and motivations better (Which does not mean that you need to agree with tehm :-)). Hopefully this does not come across as the RTFA advice as it is not. It is just hard to present all facets of a monthlong discussion in this reply. Regards Rüdiger
Re: svn commit: r987869 - /subversion/branches/performance/subversion/libsvn_fs_fs/temp_serializer.c
Stefan Sperling stsp_at_elego.de mailto:stsp_at_elego.de?Subject=Re:%20svn%20commit:%20r987869%20-%20/subversion/branches/performance/subversion/libsvn_fs_fs/temp_serializer.c wrote: On Sun, Aug 22, 2010 at 11:37:38AM -, stefan2_at_apache.org wrote: / Author: stefan2 / / Date: Sun Aug 22 11:37:38 2010 / / New Revision: 987869 / / / / URL: http://svn.apache.org/viewvc?rev=987869view=rev http://svn.apache.org/viewvc?rev=987869view=rev / / Log: / / Fix VisualStudio build: memory size calculation for variable size / / arrays is not portable. / / / / * subversion/libsvn_fs_fs/temp_serializer.c / / (serialize_dir, serialize_txdelta_ops): fix array size calculation / / / / Modified: / / subversion/branches/performance/subversion/libsvn_fs_fs/temp_serializer.c / / / / Modified: subversion/branches/performance/subversion/libsvn_fs_fs/temp_serializer.c / / URL: http://svn.apache.org/viewvc/subversion/branches/performance/subversion/libsvn_fs_fs/temp_serializer.c?rev=987869r1=987868r2=987869view=diff http://svn.apache.org/viewvc/subversion/branches/performance/subversion/libsvn_fs_fs/temp_serializer.c?rev=987869r1=987868r2=987869view=diff / / == / / --- subversion/branches/performance/subversion/libsvn_fs_fs/temp_serializer.c (original) / / +++ subversion/branches/performance/subversion/libsvn_fs_fs/temp_serializer.c Sun Aug 22 11:37:38 2010 / / @@ -272,7 +272,7 @@ serialize_dir(apr_hash_t *entries, apr_p / / / / /* calculate sizes */ / / apr_size_t count = apr_hash_count(entries); / / - apr_size_t entries_len = sizeof(svn_fs_dirent_t*[count]); / / + apr_size_t entries_len = count * sizeof(svn_fs_dirent_t*[1]); / Do you really want the second asterisk in that line? It looks like you really want this: + apr_size_t entries_len = count * sizeof(svn_fs_dirent_t[1]); No, it actually is an array of pointers. So, every element can be serialized along with all its sub-elements as a single, contiguous chunk of memory. / / / /* copy the hash entries to an auxilliary struct of known layout */ / / hash_data.count = count; / / @@ -422,7 +422,7 @@ serialize_txdelta_ops(svn_temp_serialize / / /* the ops form a simple chunk of memory with no further references */ / / svn_temp_serializer__push(context, / / (const void * const *)ops, / / - sizeof(svn_txdelta_op_t[count])); / / + count * sizeof(svn_txdelta_op_t[1])); / Because you're not using the extra asterisk here, either. I picked up the count*sizeof(T[1]) idiom from come STL implementations. They were probably working around some non-standard compiler behavior somewhere. Since that turned out to be unnecessary, I dropped the confusing [1] in r988898. -- Stefan^2.
Re: httpd trunk broken with Subversion: ap_log_rerror busted
On 25.08.2010 10:59, Plüm, Rüdiger, VF-Group wrote: -Original Message- From: justin.erenkra...@gmail.com Yes, we could fix this by making mod_authz_svn conditional on the new MMN, but - again, it's about even figuring out that the API is changed and what to do about it. The root cause is just way too obscured, IMO. Trunk has a major bump, a major bump was done for this specific change, there is an entry in the changelog for 2.3.6. The only thing that is missing is an entry in http://httpd.apache.org/docs/trunk/new_features_2_4.html in Module Developer Changes section. And yes it should be mentioned there with some hints. There's also a first stab about API changes at http://httpd.apache.org/docs/trunk/developer/new_api_2_4.html#http_log (new document, started by Nick in June) Regards, Rainer
RE: httpd trunk broken with Subversion: ap_log_rerror busted
-Original Message- From: Rainer Jung Sent: Mittwoch, 25. August 2010 11:15 To: d...@httpd.apache.org Cc: Subversion Development Subject: Re: httpd trunk broken with Subversion: ap_log_rerror busted On 25.08.2010 10:59, Plüm, Rüdiger, VF-Group wrote: -Original Message- From: justin.erenkra...@gmail.com Yes, we could fix this by making mod_authz_svn conditional on the new MMN, but - again, it's about even figuring out that the API is changed and what to do about it. The root cause is just way too obscured, IMO. Trunk has a major bump, a major bump was done for this specific change, there is an entry in the changelog for 2.3.6. The only thing that is missing is an entry in http://httpd.apache.org/docs/trunk/new_features_2_4.html in Module Developer Changes section. And yes it should be mentioned there with some hints. There's also a first stab about API changes at http://httpd.apache.org/docs/trunk/developer/new_api_2_4.html#http_log Maybe we should put a link to http://httpd.apache.org/docs/trunk/developer/new_api_2_4.html in the Module Developer Changes section in http://httpd.apache.org/docs/trunk/new_features_2_4.html Regards Rüdiger
Re: About character encoding of the text files
B Smith-Mannschott wrote on Wed, Aug 25, 2010 at 07:54:26 +0200: On Tue, Aug 24, 2010 at 21:19, Ivan Cenov i_ce...@botevgrad.com wrote: Hello, This is my first post in this list. I was pointed to post here in another thread ViewVC site (http://viewvc.tigris.org/issues/show_bug.cgi?id=11). The original reason was that ViewVC is unable to show correctly text files that contain Cyrillic characters (character set windows-1251). (The same issue is related for Western Europe's characters too.) People told me that ViewVC cannot do this because it lacks of encoding information. This information should come from Subversion and Subversion could have this information if the users have supplied it into Subversion. The last posts in above mentioned thread give more information about the problem. As I understood, information about character encoding may be supplied as svn: property, say, svn:encoding encoding_type. Par example: svn:encoding windows-1251. So, are there any intentions among the Subversion developers and users to be defined such property? Would it be reliable way for this task? If there is an issue about this problem, what is its priority? The property svn:mime-type carries charset information as an additional field: $ svn propset svn:mime-type text/plain;charset=Windows-1251 file1.txt file2.txt ... Ben, does svnbook document this syntax (and when to use it)? (or the $Keyword::$ syntax, while I'm at it) // ben
Re: git diff format support
Stefan Sperling wrote on Tue, Aug 24, 2010 at 23:03:24 +0200: On Tue, Aug 24, 2010 at 07:51:28PM +0300, anatoly techtonik wrote: Good to know. Is it worth to rename it to `svn diff --git` for unification with Mercurial? I suppose we could rename the option to --git, yes. Do you want to send a patch that does so? If yes, make sure to update all the tests too... See http://subversion.apache.org/docs/community-guide/general.html#patches Thanks, Stefan
Re: Performance branch - svnserve crash in fs_history_prev
Johan Corveleyn wrote: Hi, I've taken the performance branch for a spin. Some of performance increases are awesome (svn log is ~4 times faster on my machine (tested with a file with 300 revisions)). Try playing with the -c, -F and -M parameters. They should yield result in even better performance. With sufficient memory allotted to the server process, second runs of svn log, for instance, will be10x faster than the first run However, I also experienced a crash of svnserve, for both svn log and svn blame of a big file with 2000 revisions (so this is quite an extreme case). See both .log files in attachment. Something goes wrong in svn_fs_fs__id_deserialize, during processing of fs_history_prev. Hm, I couldn't reproduce that problem so far even with large repositories. Could you rerun your tests in debug mode? The stack trace should be more reliable then (e.g. data_len on level #3 is either bogus or the reason for the crash). I also have crash dump files of the crashes. If you want those, let me know and I'll send them via private email. This was on Windows XP, a release build with VCE 2008. Since I don't have the same binaries and PDB files that you used, the crash dumps will probably not tell me much more than the text files that you posted. Thanks for testing! -- Stefan^2.
Re: svn commit: r988956 - /subversion/trunk/subversion/libsvn_wc/update_editor.c
phi...@apache.org writes: Author: philip Date: Wed Aug 25 09:55:35 2010 New Revision: 988956 URL: http://svn.apache.org/viewvc?rev=988956view=rev Log: Fix some uses of unitialised variables identified by valgrind. * subversion/libsvn_wc/update_editor.c (add_directory, add_file): Set conflicted if svn_wc__db_read_info fails. Modified: subversion/trunk/subversion/libsvn_wc/update_editor.c Modified: subversion/trunk/subversion/libsvn_wc/update_editor.c URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/update_editor.c?rev=988956r1=988955r2=988956view=diff == --- subversion/trunk/subversion/libsvn_wc/update_editor.c (original) +++ subversion/trunk/subversion/libsvn_wc/update_editor.c Wed Aug 25 09:55:35 2010 @@ -2357,6 +2357,7 @@ add_directory(const char *path, svn_error_clear(err); wc_kind = svn_wc__db_kind_unknown; status = svn_wc__db_status_normal; + conflicted = FALSE; versioned_locally_and_present = FALSE; } @@ -3808,6 +3809,7 @@ add_file(const char *path, svn_error_clear(err); wc_kind = svn_wc__db_kind_unknown; status = svn_wc__db_status_normal; + conflicted = FALSE; versioned_locally_and_present = FALSE; } Could someone confirm that FALSE is correct here? -- Philip
Re: svn commit: r988627 - in /subversion/trunk/subversion: bindings/javahl/native/ include/ libsvn_client/ svn/
On Tue, 2010-08-24, hwri...@apache.org wrote: Log: Move the commit callback out of the client context and into the individual APIs which require it. Hurrah! Reviewed and looks good. - Julian * subversion/bindings/javahl/native/SVNClient.cpp (remove, commit, copy, move, mkdir, doImport, propertySet): Set the callback as a param, rather than in the client context. * subversion/svn/propdel-cmd.c, subversion/svn/move-cmd.c, subversion/svn/mkdir-cmd.c, subversion/svn/copy-cmd.c, subversion/svn/commit-cmd.c, subversion/svn/propset-cmd.c, subversion/svn/delete-cmd.c, subversion/svn/import-cmd.c, subversion/svn/propedit-cmd.c: Update API consumers to provide the commit callback. * subversion/svn/main.c (main): Don't set the commit callback context members. * subversion/include/svn_client.h (svn_client_ctx_t): Remove the commit callback and baton members. (svn_client_mkdir4, svn_client_delete4, svn_client_import4, svn_client_commit5, svn_client_copy6, svn_client_move6, svn_client_propset4): Add commit callback parameters. * subversion/libsvn_client/deprecated.c (capture_baton_t): Remove unneded members. (capture_commit_info): Just dup the commit info and exit. (svn_client_mkdir3, svn_client_import3, svn_client_delete3, svn_client_commit4, svn_client_copy5, svn_client_move5, svn_client_propset3): Remove the use of the shadow baton. * subversion/libsvn_client/delete.c, subversion/libsvn_client/prop_commands.c, subversion/libsvn_client/copy.c, subversion/libsvn_client/add.c, subversion/libsvn_client/commit.c: Explicitly pass around the commit callback and baton, rather than relying on the client context. [...]
Re: httpd trunk broken with Subversion: ap_log_rerror busted
On Tue, 24 Aug 2010, Justin Erenkrantz wrote: In r951893, httpd modified a #define for APLOG_MARK to add in a new parameter called APLOG_MODULE_INDEX (in addition to file and line info). This busts Subversion - specifically, mod_authz_svn which has a function called: static void log_access_verdict(const char *file, int line, const request_rec *r, int allowed, const char *repos_path, const char *dest_repos_path) it is called with: log_access_verdict(APLOG_MARK, r, 1, repos_path, dest_repos_path); I agree that the comments/documentation should be improved. I will write a how-to for adjusting modules to the new API. For now, see how mod_ssl was changed in r951194. The reasoning is that APLOG_MARK will work for the ap_log_*error functions, always (i.e. in both 2.2.x and trunk). If you define you own log functions that may accept different parameters, define your own SVNLOG_MARK that fits your functions. When you call ap_log*error without APLOG_MARK, you will have to do #ifdef based on MMN, though.
Re: Performance branch - svnserve crash in fs_history_prev
On Wed, Aug 25, 2010 at 11:34 AM, Stefan Fuhrmann stefanfuhrm...@alice-dsl.de wrote: Johan Corveleyn wrote: However, I also experienced a crash of svnserve, for both svn log and svn blame of a big file with 2000 revisions (so this is quite an extreme case). See both .log files in attachment. Something goes wrong in svn_fs_fs__id_deserialize, during processing of fs_history_prev. Hm, I couldn't reproduce that problem so far even with large repositories. Could you rerun your tests in debug mode? The stack trace should be more reliable then (e.g. data_len on level #3 is either bogus or the reason for the crash). Ok, here they are in attachment (one for blame and one for log). Reproduced with a debug build (of branches/performa...@now), on the same machine. Crashed with both blame and log of large file with large number of revisions (but I don't know if that's actually relevant, maybe it's not related). With blame it crashed much sooner as my release build. Cheers, -- Johan Process info: Cmd line: C:\research\svn\client_build\svn_branch_performance\dist\bin\svnserve.exe -d -r c:/research/svn/experiment/repos Working Dir: C:\research\svn Version: 1.7.0 (dev build), compiled Aug 19 2010, 00:50:40 Platform: Windows OS version 5.1 build 2600 Service Pack 3 Exception: ACCESS_VIOLATION Registers: eax=dc307ce7 ebx=00d31370 ecx=00db54eb edx=00db54eb esi=00f0f8d0 edi=00f0f930 eip=003bb02c esp=00f0f8b4 ebp=00f0f8b4 efl=00010216 cs=001b ss=0023 ds=0023 es=0023 fs=003b gs= Stacktrace: #1 0x003bb02c in svn_fs_fs__id_deserialize() buffer = 0x00db54e7 id = #2 0x003bb5ca in svn_fs_fs__noderev_deserialize() buffer = 0x00db54e8 noderev_p = noderev = #3 0x003bfaa9 in svn_fs_fs__dag_deserialize() out = data = data_len = 1e0 pool = node = #4 0x004bcdfe in membuffer_cache_get() cache = key = key_len = 31 item = deserializer = pool = buffer = 0x00db5308 group_index = faa to_find = entry = #5 0x004bcb64 in svn_membuffer_cache_get() svn_err__temp = value_p = found = 0x00f0f9e8 cache_void = 0x00d6bc40 key = pool = full_key = 0x00db52b8 cache = full_key_len = 31 #6 0x004bdc63 in svn_cache__get() value_p = found = 0x00f0f9e8 cache = key = pool = #7 0x003b1188 in dag_node_cache_get() svn_err__temp = node_p = root = path = pool = node = cache = key = found = 0 #8 0x003b1436 in open_path() svn_err__temp = inherit = err = copy_path = cached_node = entry = 0x00db5258 s9server next = child = parent_path_p = root = path = flags = 0 txn_id = pool = canon_path = fs = parent_path = rest = path_so_far = here = #9 0x003b85b3 in history_prev() svn_err__temp = baton = 0x00f0fbb4 pool = node = path = commit_rev = retpool = retry = 0 copyroot_path = fhd = history = revision = a1d1 fs = src_path = parent_path = copyroot_rev = commit_path = src_rev = dst_rev = root = reported = 1 prev_history = args = #10 0x003b83d0 in fs_history_prev() svn_err__temp = args = prev_history_p = history = cross_copies = 1 pool = fhd = fs = prev_history = #11 0x00395c26 in svn_fs_history_prev() prev_history_p = history = cross_copies = 1 pool = #12 0x00631c86 in find_interesting_revisions() svn_err__temp = tmp_pool = path_rev = path_revisions = repos = path = start = 0 end = 17831 include_merged_revisions = 0 mark_as_merged = 0 duplicate_path_revs = authz_read_func = authz_read_baton = 0x00f0fe9c pool = history = iter_pool = last_pool = root = kind = #13 0x00631706 in svn_repos_get_file_revs2() svn_err__temp = repos = path = start = 0 end = 17831 include_merged_revisions = 0 authz_read_func = authz_read_baton = 0x00f0fe9c handler = handler_baton = 0x00f0fdb0 pool = duplicate_path_revs = mainline_pos = -858993460 merged_path_revisions = merged_pos = -858993460 sb = mainline_path_revisions = #14 0x0040d45a in get_file_revs() conn
Re: svn commit: r987869 - /subversion/branches/performance/subversion/libsvn_fs_fs/temp_serializer.c
On Wed, Aug 25, 2010 at 11:13:17AM +0200, Stefan Fuhrmann wrote: I picked up the count*sizeof(T[1]) idiom from come STL implementations. They were probably working around some non-standard compiler behavior somewhere. Since that turned out to be unnecessary, I dropped the confusing [1] in r988898. Ok, thanks for clarifying! Stefan
RE: svn commit: r988956 - /subversion/trunk/subversion/libsvn_wc/update_editor.c
-Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: woensdag 25 augustus 2010 14:52 To: Philip Martin Cc: dev@subversion.apache.org Subject: Re: svn commit: r988956 - /subversion/trunk/subversion/libsvn_wc/update_editor.c On Wed, Aug 25, 2010 at 11:00:10AM +0100, Philip Martin wrote: phi...@apache.org writes: Author: philip Date: Wed Aug 25 09:55:35 2010 New Revision: 988956 URL: http://svn.apache.org/viewvc?rev=988956view=rev Log: Fix some uses of unitialised variables identified by valgrind. * subversion/libsvn_wc/update_editor.c (add_directory, add_file): Set conflicted if svn_wc__db_read_info fails. Modified: subversion/trunk/subversion/libsvn_wc/update_editor.c Modified: subversion/trunk/subversion/libsvn_wc/update_editor.c URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/upd ate_editor.c?rev=988956r1=988955r2=988956view=diff == --- subversion/trunk/subversion/libsvn_wc/update_editor.c (original) +++ subversion/trunk/subversion/libsvn_wc/update_editor.c Wed Aug 25 09:55:35 2010 @@ -2357,6 +2357,7 @@ add_directory(const char *path, svn_error_clear(err); wc_kind = svn_wc__db_kind_unknown; status = svn_wc__db_status_normal; + conflicted = FALSE; versioned_locally_and_present = FALSE; } @@ -3808,6 +3809,7 @@ add_file(const char *path, svn_error_clear(err); wc_kind = svn_wc__db_kind_unknown; status = svn_wc__db_status_normal; + conflicted = FALSE; versioned_locally_and_present = FALSE; } Could someone confirm that FALSE is correct here? Looks fine to me. Answered on IRC: No, this is not the correct value. A node can still be in conflict while _db_read_info() returns path not found. Currently delete-delete tree conflicts can be the exception. So in this case it's safer to set the conflicted variable to TRUE and thereby perform the more expensive checks, to verify if the node is really in conflict. Bert
Re: svn commit: r989108 - /subversion/trunk/subversion/libsvn_ra_local/ra_plugin.c
phi...@apache.org writes:
Author: philip
Date: Wed Aug 25 13:53:27 2010
New Revision: 989108
URL: http://svn.apache.org/viewvc?rev=989108view=rev
Log:
Stop writing to pool memory after the pool has been cleared, something
that started to happen when svn_ra_open4 introduced a session pool. The
problem was identified by valgrind.
* subversion/libsvn_ra/ra_plugin.c
(get_username): Use the session pool to allocate the svn_fs_access_t and
to setup the pool cleanup.
Modified:
subversion/trunk/subversion/libsvn_ra_local/ra_plugin.c
Modified: subversion/trunk/subversion/libsvn_ra_local/ra_plugin.c
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_ra_local/ra_plugin.c?rev=989108r1=989107r2=989108view=diff
==
--- subversion/trunk/subversion/libsvn_ra_local/ra_plugin.c (original)
+++ subversion/trunk/subversion/libsvn_ra_local/ra_plugin.c Wed Aug 25
13:53:27 2010
@@ -115,12 +115,12 @@ get_username(svn_ra_session_t *session,
if (*sess-username)
{
SVN_ERR(svn_fs_create_access(access_ctx, sess-username,
- pool));
+ session-pool));
SVN_ERR(svn_fs_set_access(sess-fs, access_ctx));
/* Make sure this context is disassociated when the pool gets
destroyed. */
- apr_pool_cleanup_register(pool, sess-fs, cleanup_access,
+ apr_pool_cleanup_register(session-pool, sess-fs, cleanup_access,
apr_pool_cleanup_null);
}
Mike, this was necessary to fix this problem:
$ svnadmin create repo
$ mkdir greek
$ valgrind -q subversion/svn/.libs/lt-svn import -mm greek file://`pwd`/repo
==6804== Invalid write of size 8
==6804==at 0x6C2A5BF: svn_fs_set_access (access.c:58)
==6804==by 0x67E4325: cleanup_access (ra_plugin.c:56)
==6804==by 0x5E3629A: run_cleanups (apr_pools.c:2071)
==6804==by 0x5E35398: pool_clear_debug (apr_pools.c:1409)
==6804==by 0x5E35599: pool_destroy_debug (apr_pools.c:1494)
==6804==by 0x5E3566D: apr_pool_destroy_debug (apr_pools.c:1536)
==6804==by 0x4E3EA13: svn_client_import4 (commit.c:825)
==6804==by 0x40D982: svn_cl__import (import-cmd.c:119)
==6804==by 0x4156E8: main (main.c:2329)
==6804== Address 0xa8ddc90 is 40 bytes inside a block of size 64 free'd
==6804==at 0x4C2130F: free (vg_replace_malloc.c:323)
==6804==by 0x5E35469: pool_clear_debug (apr_pools.c:1432)
==6804==by 0x5E35599: pool_destroy_debug (apr_pools.c:1494)
==6804==by 0x5E3537E: pool_clear_debug (apr_pools.c:1406)
==6804==by 0x5E35599: pool_destroy_debug (apr_pools.c:1494)
==6804==by 0x5E3566D: apr_pool_destroy_debug (apr_pools.c:1536)
==6804==by 0x4E3EA13: svn_client_import4 (commit.c:825)
==6804==by 0x40D982: svn_cl__import (import-cmd.c:119)
==6804==by 0x4156E8: main (main.c:2329)
It was caused by r965856 where svn_ra_open4 creates a pool and
allocates the returned session inside that pool. Ususally our
allocation functions allocate directly in the supplied pool. Why the
change?
--
Philip
Re: svn commit: r989108 - /subversion/trunk/subversion/libsvn_ra_local/ra_plugin.c
On 08/25/2010 10:00 AM, Philip Martin wrote: phi...@apache.org writes: Author: philip Date: Wed Aug 25 13:53:27 2010 New Revision: 989108 URL: http://svn.apache.org/viewvc?rev=989108view=rev Log: Stop writing to pool memory after the pool has been cleared, something that started to happen when svn_ra_open4 introduced a session pool. The problem was identified by valgrind. Good catch, Philip. Thanks for cleaning up after me. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: httpd trunk broken with Subversion: ap_log_rerror busted
On Wed, Aug 25, 2010 at 4:48 AM, Stefan Fritsch s...@sfritsch.de wrote: I agree that the comments/documentation should be improved. I will write a how-to for adjusting modules to the new API. Here is a constructive suggestion (*grin*): in APR, for some of the more complex declarations (see apr_pools.h and apr_pool_create), what we have done is to create a #ifdef DOXYGEN tag which indicates the normalized reduced form of the function declaration. The #else clause contains the optimized, macro-ized version. (In httpd, I don't know what the appropriate #ifdef should be though.) This way those reading http_log.h will be able to see what the declaration for ap_log_rerror actually reduces to without trying to go through several layers of indirection. -- justin
Re: About character encoding of the text files
На 25.8.2010 г. 08:54, B Smith-Mannschott написа: The property svn:mime-type carries charset information as an additional field: $ svn propset svn:mime-type text/plain;charset=Windows-1251 file1.txt file2.txt ... // ben Hi, I tried with * svn:*mime*-type* text/plain; charset=Windows-1251 and *svn:mime-type* text/plain; charset=windows-1251 and *svn:mime-type* text/plain;charset=windows-1251 and *svn:mime-type* text/plain; charset=Windows-1251 on a file d.c but without success. ViewVC continued to show instead of cyrillic letters. Well, Subversion supplies the information. It is up to ViewVC to deal with it... From my point of view, it would be better a dedicated property to be defined. svn:charset is only an example. -- Regards, Ivan Cenov OKTO-7 Co., Botevgrad, Bulgaria i_ce...@botevgrad.com, i...@okto7.com GSM: +359 888 76 10 80 phone: +359 723 6 61 20, +359 723 6 61 61 fax: +359 723 6 62 62
[PATCH] Rename --git-diff to --git for svn diff
Here is the patch. I've embedded log message inside and also opened
Rietveld issue if you like. http://codereview.appspot.com/2012048/
--
anatoly t.
On Wed, Aug 25, 2010 at 12:21 PM, Daniel Shahaf d...@daniel.shahaf.name wrote:
Stefan Sperling wrote on Tue, Aug 24, 2010 at 23:03:24 +0200:
On Tue, Aug 24, 2010 at 07:51:28PM +0300, anatoly techtonik wrote:
Good to know. Is it worth to rename it to `svn diff --git` for
unification with Mercurial?
I suppose we could rename the option to --git, yes.
Do you want to send a patch that does so?
If yes, make sure to update all the tests too...
See http://subversion.apache.org/docs/community-guide/general.html#patches
Thanks,
Stefan
[[[
Rename --git-diff option to --git for consistency with Mercurial and diff.
* subversion/svn/main.c: Replace git-diff option with git
* subversion/tests/cmdline/diff_tests.py: Fix to use new --git option
]]]
Index: subversion/tests/cmdline/diff_tests.py
===
--- subversion/tests/cmdline/diff_tests.py (revision 989090)
+++ subversion/tests/cmdline/diff_tests.py (working copy)
@@ -3394,7 +3394,7 @@
working copy, copyfrom=lambda_path)
svntest.actions.run_and_verify_svn(None, expected_output, [], 'diff',
- '--git-diff', wc_dir)
+ '--git', wc_dir)
def diff_git_format_url_wc(sbox):
create a diff in git unidiff format for url-wc
@@ -3433,7 +3433,7 @@
]
svntest.actions.run_and_verify_svn(None, expected_output, [], 'diff',
- '--git-diff',
+ '--git',
'--old', repo_url + '@1', '--new',
wc_dir)
@@ -3473,7 +3473,7 @@
]
svntest.actions.run_and_verify_svn(None, expected_output, [], 'diff',
- '--git-diff',
+ '--git',
'--old', repo_url + '@1', '--new',
repo_url + '@2')
@@ -3641,7 +3641,7 @@
delete=True, text_changes=False)
svntest.actions.run_and_verify_svn(None, expected_output, [], 'diff',
- '--git-diff', wc_dir)
+ '--git', wc_dir)
Index: subversion/svn/main.c
===
--- subversion/svn/main.c (revision 989090)
+++ subversion/svn/main.c (working copy)
@@ -368,7 +368,7 @@
N_(override diff-cmd specified in config file\n
[alias: --idiff])},
- {git-diff, opt_use_git_diff_format, 0,
+ {git, opt_use_git_diff_format, 0,
N_(use git's extended diff format\n)},
/* Long-opt Aliases
Re: About character encoding of the text files
On 25/08/2010 17:01, Ivan Cenov wrote:
25.8.2010 ??. 08:54, B Smith-Mannschott :
The property svn:mime-type carries charset information as an
additional field:
$ svn propset svn:mime-type text/plain;charset=Windows-1251
file1.txt file2.txt ...
// ben
Hi, I tried with
*
svn:*mime*-type* text/plain; charset=Windows-1251
and
*svn:mime-type* text/plain; charset=windows-1251
and
*svn:mime-type* text/plain;charset=windows-1251
and
*svn:mime-type* text/plain; charset=Windows-1251
on a file d.c but without success. ViewVC continued to show instead
of cyrillic letters.
Well, Subversion supplies the information. It is up to ViewVC to deal
with it...
From my point of view, it would be better a dedicated property to be
defined.
svn:charset is only an example.
Maybe, but doing it this way is consistent with the way that the charset
is included in the Content-Type http header alongside the mime type,
described eg. here:
http://www.w3.org/International/O-HTTP-charset
It makes sense to include it alongside the mime-type, because it's only
valid to set it if the document is of type 'text', eg. text/plain or
text/html.
Matthew
Re: About character encoding of the text files
На 25.8.2010 г. 19:27, Matthew Bentham написа: Maybe, but doing it this way is consistent with the way that the charset is included in the Content-Type http header alongside the mime type, described eg. here: http://www.w3.org/International/O-HTTP-charset It makes sense to include it alongside the mime-type, because it's only valid to set it if the document is of type 'text', eg. text/plain or text/html. Matthew Ok, I have understood. It does not make big difference, more important is that the information exists. It is better to be compliant with the existing norms and rules, so svn:mime-type is OK too. Well, I tested with svn:mime-type=text/plain; charset=windows1251. I tried to define it as auto property in [auto-props] section of Subversion config file (it resides in C:\Documents and Settings\username\Application Data\Subversion). This was not successful because ';' after 'plain' is a delimiter and so charset=windows1251 is truncated. This is argument against svn:mime-type. -- Regards, Ivan Cenov OKTO-7 Co., Botevgrad, Bulgaria i_ce...@botevgrad.com, i...@okto7.com GSM: +359 888 76 10 80 phone: +359 723 6 61 20, +359 723 6 61 61 fax: +359 723 6 62 62
Re: About character encoding of the text files
On 25.08.2010 18:54, Ivan Cenov wrote: На 25.8.2010 г. 19:27, Matthew Bentham написа: Maybe, but doing it this way is consistent with the way that the charset is included in the Content-Type http header alongside the mime type, described eg. here: http://www.w3.org/International/O-HTTP-charset It makes sense to include it alongside the mime-type, because it's only valid to set it if the document is of type 'text', eg. text/plain or text/html. Matthew Ok, I have understood. It does not make big difference, more important is that the information exists. It is better to be compliant with the existing norms and rules, so svn:mime-type is OK too. Well, I tested with svn:mime-type=text/plain; charset=windows1251. I tried to define it as auto property in [auto-props] section of Subversion config file (it resides in C:\Documents and Settings\username\Application Data\Subversion). This was not successful because ';' after 'plain' is a delimiter and so charset=windows1251 is truncated. This is argument against svn:mime-type. It's more an argument for fixing autoprops, IMHO :) -- Brane
Re: RFC: How should Subversion handle OS-deleted paths?
On Tue, Aug 24, 2010 at 7:25 AM, Julian Foad julian.f...@wandisco.com wrote: Hi Julian, Thanks for taking some time to think about this. Comments below. On Fri, 2010-08-20, Paul Burba wrote: I think we can all agree that when a user deletes part of their WC via the OS they have made a mistake of some sort. But which mistake exactly? The obvious answer is that they really intended 'svn del dirX/foo.c'. But possibly they intended something more akin to 'svn up --set-depth empty dirX'. Or maybe it was just a true mistake, and nothing was intended; they expect foo.c to be there! Or maybe the user *renamed* or *moved* the item to a different path, where it still exists complete with its local mods, and when the user realizes they should have used svn mv instead, they will want to issue the as-yet-unavailable svn mv --retrospectively command [1], or, failing that, they will want to move the item back into place and then issue the correct svn mv. Agreed, we simply can't be sure what the user's intention was...I'm beginning to be swayed to the idea that restoring the missing subtrees may not be the ideal approach... So there are several courses of action that the user might want. Is there an obvious, simple and safe default action that Subversion could take in order to resolve each missing item it encounters? I think there isn't. I originally came to this question when dealing with merge tracking and paths missing because they were deleted outside of Subversion, see http://svn.haxx.se/dev/archive-2010-08/0156.shtml. Somewhat tardily I realized the *first* question to be answered is not how merge tracking should deal with such paths, but how should Subversion in general deal with them. I see a few basic approaches: 1) Consistent Approach -- Restore the Missing Paths (unless there is really a compelling reason not too, but the default approach is to restore) WCNG's single DB allows us to simply restore these missing paths as we encounter them (the notable exception being 'svn st' of course, which just reports the missing state). For a file, the working properties (stored in ACTUAL_NODE table) are still known to Subversion, whereas its working text is NOT known to Subversion. So Subversion could restore the item by: * reverting the file text and keeping the working properties, or * reverting the file text and reverting the properties. For a directory, that applies to each versioned file inside it, as well as to the properties on the directories themselves. (Any unversioned items inside it would of course be lost.) Is either of those ways obviously the right way to restore? I would suggest neither is obviously the right one. Exhibit A of this behavior: In 1.6.x and 1.7 in multiple DB mode, svn revert skips missing directories. In single-DB mode they are restored. Here, they are restored in the second sense above - i.e. reverted. 2) Consistent Approach: Error out If we detect missing paths, simply throw an error asking that the user restore them before proceeding. Obviously for svn st/up/revert, the current behavior is fine, but for svn ci/sw/merge we could follow this route. I think this is a good approach for ci/sw/merge and in fact most commands. It is the simplest approach and that counts for a lot. 3) Case-by-Case Approach: Maybe there is *no* consistent approach, and sometimes we will want to restore, but other times we'll do something else. I'll leave what something else is as an open question for the moment. I think consistency is important, but I'm not seeing a single behaviour that's suitable for all commands. Let me see... svn revert should of course restore any missing thing back to its last versioned state, because that's it's job. (In 1.6 and earlier, it was unable to restore missing directories, which was always known as a deficiency.) svn status should of course report the problem, because that's its job. svn delete could throw an error, or it could ignore the inconsistency and just schedule the thing for deletion anyway. (I suppose we could consider the latter behaviour to be first restoring and then deleting, in one operation.) Same for any other UI that's able to make the node go away such as svn up --set-depth empty PARENT_PATH. svn diff and svn blame I think should throw an error if trying to access the missing text of the node. (Same for svn cat -rWORKING if we ever support that.) I don't see any good reason for read-only commands such as these to attempt to fix a problem. svn copy and svn move where the source is missing: throw an error. They could perhaps alternatively perform a copy or move in which the target working file/dir is still missing, but that's greater complexity and I see no benefit. svn export: throw an error. It could perhaps alternatively skip the missing node, on the basis that its job is to re-create the current working state of the WC, but I
Get latest file changes in repository
I am trying to get a list from the repository (not anyone's working copy) of the files and folders that have changed since the last revision. How do I do this? Thanks,
Re: About character encoding of the text files
On Wed, Aug 25, 2010 at 06:58:50PM +0200, Branko Čibej wrote: On 25.08.2010 18:54, Ivan Cenov wrote: Well, I tested with svn:mime-type=text/plain; charset=windows1251. I tried to define it as auto property in [auto-props] section of Subversion config file (it resides in C:\Documents and Settings\username\Application Data\Subversion). This was not successful because ';' after 'plain' is a delimiter and so charset=windows1251 is truncated. This is argument against svn:mime-type. It's more an argument for fixing autoprops, IMHO :) Looks more like auto-props documentation needs a fix. The escaping rules don't seem to be documented. You can write ';;' to get a literal ';'. So you can use this in your config for auto-props: svn:mime-type=text/plain;; charset=windows1251 Stefan
Re: Get latest file changes in repository
Steve, This is is about the development of Subversion. Your question about the usage of Subversion is more appropriately directed toward the users' list us...@subversion.apache.org. Thanks. On Wed, Aug 25, 2010 at 1:48 PM, Steve stroi...@live.com wrote: I am trying to get a list from the repository (not anyone's working copy) of the files and folders that have changed since the last revision. How do I do this? Thanks,
Re: Get latest file changes in repository
On Wed, Aug 25, 2010 at 10:48:30AM -0700, Steve wrote: I am trying to get a list from the repository (not anyone's working copy) of the files and folders that have changed since the last revision. How do I do this? Please post such questions to the users list. This list is about development of Subversion itself, not about usage questions. Thanks. See http://subversion.apache.org/mailing-lists.html (That said, here's a hint that might help you: Try the command 'svn log -v', and also see http://subversion.apache.org/faq.html#hidden-log) Stefan
Re: [PATCH] Fix community guide links to Writing log messages chapter (issue2016045)
On 08/25/2010 11:46 AM, techto...@gmail.com wrote: Reviewers: dev_subversion.apache.org, Message: Community guide contains broken links to Writing log messages chapter. Please, review this patch. Committed in r989320. Thanks! -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: [PATCH] Rename --git-diff to --git for svn diff
On Wed, Aug 25, 2010 at 07:13:15PM +0300, anatoly techtonik wrote: Here is the patch. I've embedded log message inside and also opened Rietveld issue if you like. http://codereview.appspot.com/2012048/ Thank you! Committed in r989327. I've tweaked the log message a bit, most importanly to mention the symbol names of things that have changed, which we usually do in our log messages so that it's easy to find changes made to a specific struct or function. Stefan
serf 0.7.0 released
Hi all, I'm pleased to announce the 0.7.0 release of serf. Below is a quick summary of changes (since the 0.6.1 release): Fix double free abort when destroying request buckets. Fix test server in unit test framework to avoid random test failures. Allow older Serf programs which don't use the new authn framework to still handle authn without forcing them to switch to the new framework. (r1401) Remove the SERF_DECLARE macros, preferring a .DEF file for Windows Barrier buckets now pass read_iovec to their wrapped bucket. Fix HTTP header parsing to allow for empty header values. Download details are at: http://code.google.com/p/serf/downloads/list Direct link: http://serf.googlecode.com/files/serf-0.7.0.tar.bz2 SHA1: 868fdb00e679dd84ed888ec77414698365530bae Enjoy! Cheers, -g
Re: [PATCH] Rename --git-diff to --git for svn diff
On Wed, Aug 25, 2010 at 10:58 PM, Stefan Sperling s...@elego.de wrote: Here is the patch. I've embedded log message inside and also opened Rietveld issue if you like. http://codereview.appspot.com/2012048/ Thank you! Committed in r989327. I've tweaked the log message a bit, most importanly to mention the symbol names of things that have changed, which we usually do in our log messages so that it's easy to find changes made to a specific struct or function. Thanks. Now I see how it should look like. -- anatoly t.
Re: serf 0.7.0 released
On 8/25/10 2:16 PM, Greg Stein wrote: Hi all, I'm pleased to announce the 0.7.0 release of serf. Below is a quick summary of changes (since the 0.6.1 release): Fix double free abort when destroying request buckets. Fix test server in unit test framework to avoid random test failures. Allow older Serf programs which don't use the new authn framework to still handle authn without forcing them to switch to the new framework. (r1401) Remove the SERF_DECLARE macros, preferring a .DEF file for Windows Barrier buckets now pass read_iovec to their wrapped bucket. Fix HTTP header parsing to allow for empty header values. Does it change the ABI? Do we need to wait for the next svn 1.6.x release before we can use it? I'm asking because I maintain the MacPorts serf package and don't want to break existing installs. Blair
Re: [serf-dev] serf 0.7.0 released
On Wed, Aug 25, 2010 at 2:16 PM, Greg Stein gst...@gmail.com wrote: Hi all, I'm pleased to announce the 0.7.0 release of serf. Thanks! -- justin
Re: [serf-dev] Re: serf 0.7.0 released
On Wed, Aug 25, 2010 at 4:01 PM, Peter Samuelson pe...@p12n.org wrote: Yeah but presumably he's asking because he's linking libsvn_ra_serf to serf 0.3.x now, so the question remains: is 0.7.0 ABI-compatible with 0.3.x? As far as I know, 0.3 is ABI-compatible with 0.2 and 0.1. Macports is at 0.6.1. IOW, it's already busted now. =( -- justin
Re: [serf-dev] Re: serf 0.7.0 released
On 8/25/10 4:16 PM, Justin Erenkrantz wrote: On Wed, Aug 25, 2010 at 4:01 PM, Peter Samuelsonpe...@p12n.org wrote: Yeah but presumably he's asking because he's linking libsvn_ra_serf to serf 0.3.x now, so the question remains: is 0.7.0 ABI-compatible with 0.3.x? As far as I know, 0.3 is ABI-compatible with 0.2 and 0.1. Macports is at 0.6.1. IOW, it's already busted now. =( -- justin Busted checkouts and operations are better than core dumps :) Can I get an answer to the question? Blair
Re: [serf-dev] Re: serf 0.7.0 released
On Wed, Aug 25, 2010 at 4:24 PM, Blair Zajac bl...@orcaware.com wrote: On 8/25/10 4:16 PM, Justin Erenkrantz wrote: On Wed, Aug 25, 2010 at 4:01 PM, Peter Samuelsonpe...@p12n.org wrote: Yeah but presumably he's asking because he's linking libsvn_ra_serf to serf 0.3.x now, so the question remains: is 0.7.0 ABI-compatible with 0.3.x? As far as I know, 0.3 is ABI-compatible with 0.2 and 0.1. Macports is at 0.6.1. IOW, it's already busted now. =( -- justin Busted checkouts and operations are better than core dumps :) Subversion 1.6.12 and serf 0.6.1 from Macports doesn't even do any type of a checkout - it always errors out immediately. Backing up, there are three faults: - API/ABI compatibility - this was broken way back in 0.4.0 - no current 1.6.x release of Subversion can work with anything from serf 0.4.0 or higher. You need the proposed backport to Subversion (1.6.x-r879757) to make 1.6.x work with the serf 0.4.0+ API. - Authn framework fix - this is fixed in 0.7.0. - Memory usage - this is also fixed in 0.7.0. 1.7.x/trunk of Subversion could work with 0.4.0-0.6.1 - this is what Stefan and others reported the memory leaks - but Subversion has never officially released a version that works with serf 0.4.0+. Can I get an answer to the question? I'm not sure there is any API/ABI changes between 0.6.1 and 0.7.0. Greg? Lieven? -- justin
Re: [serf-dev] Re: serf 0.7.0 released
On Wed, Aug 25, 2010 at 19:39, Justin Erenkrantz jus...@erenkrantz.com wrote: ... I'm not sure there is any API/ABI changes between 0.6.1 and 0.7.0. Greg? Lieven? -- justin 0.6.1 and 0.7.0 are effectively compatible. I think an unused function was removed, and the unused SERF_DECLARE stuff was removed. These latest releases are fully incompatible with 0.3.x and earlier releases, according to the pre 1.0 caveat of the versioning guidelines[1]. Cheers, -g [1] http://apr.apache.org/versioning.html#basics
Re: [serf-dev] Re: serf 0.7.0 released
On 26.08.2010 01:46, Greg Stein wrote: On Wed, Aug 25, 2010 at 19:39, Justin Erenkrantz jus...@erenkrantz.com wrote: ... I'm not sure there is any API/ABI changes between 0.6.1 and 0.7.0. Greg? Lieven? -- justin 0.6.1 and 0.7.0 are effectively compatible. I think an unused function was removed, and the unused SERF_DECLARE stuff was removed. IIRC replacing the #declspec with a .DEF file will change the ABI for DLLs on Windows. Shouldn't affect MacPorts or any other Unix-like system though. -- Brane
Re: [serf-dev] Re: serf 0.7.0 released
On Wed, Aug 25, 2010 at 21:53, Branko Čibej br...@xbc.nu wrote: On 26.08.2010 01:46, Greg Stein wrote: On Wed, Aug 25, 2010 at 19:39, Justin Erenkrantz jus...@erenkrantz.com wrote: ... I'm not sure there is any API/ABI changes between 0.6.1 and 0.7.0. Greg? Lieven? -- justin 0.6.1 and 0.7.0 are effectively compatible. I think an unused function was removed, and the unused SERF_DECLARE stuff was removed. IIRC replacing the #declspec with a .DEF file will change the ABI for DLLs on Windows. Shouldn't affect MacPorts or any other Unix-like system though. Ah. Thanks for the info. The macros didn't do anything though (never got that far), so the declarations/implementations were the default callspec. Not sure if that matters, and I don't really care :-P ... as long as Blair is set, then we're good. Background: serf used a set of DECLARE macros, much like Apache httpd and APR. But Subversion showed that it was unnecessary since you could just use a .def file instead of funky magic. And that it was easy to create that .def as long as your header files were regularized in their declaration formatting. So 0.7.0 drops the complexity and switched to a simple .def generation instead. Lesson learned: it doesn't pay to stick with old, tired idioms. Cheers, -g
Pascal bindings
Hello SVN people. As suggested by Hyrum K. Wright I'm forwarding the mail here. I'm wandering if there's an official Pascal (FreePascal or Delphi) bindings for the Subversion. I've converted C-headers (1.5.6 tag) for my own needs, and I guess it would be easy for me to catch up with the trunk as well. If they're acceptable, I would like to contribute them for the project, as well as support and update the bindings with the new product releases. Any suggestions? Do you need to have Pascal bindings? thanks, Dmitry
