You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Näslund <da...@longitudo.com> on 2009/08/13 14:23:05 UTC
[PATCH] Use context_t for svn_wc_cleanup3
Hi!
[ I could not send this message through my ordinary MUA, mutt.
My webmail does unfortunately encode all attachments as binary
data. Sorry. ]
I have run make check with three FAILs:
external_tests.py 16: place a file external into a directory external.
switch_tests.py 18: switch shouldn't allow changing repos root
switch_tests.py 21: forced switch detectes tree conflicts.
Reverted all changes, recompiled and the three tests still failed! Can
anyone confirm that those tests are failing on trunk?
I have replaced all occurences of svn_wc_cleanup2 with cleanup3 in
libsvn_client. Is it bad to do two different things in one patch? Since
replacing all cleanup2 means that the wrapper in deprecated.c will not
be tested?
[[[
Use svn_wc_context_t and absolute paths in svn_wc_cleanup3. Make
libsvn_client use svn_wc_cleanup3. Remove diff3_cmd parameter.
* subversion/include/svn_wc.h
(svn_wc_cleanup3): New.
(svn_wc_cleanup2): Deprecate.
* subversion/libsvn_wc/deprecated.c
(svn_wc_cleanup2): Reinplement as a wrapper.
* subversion/libsvn_wc/log.c
(svn_wc_cleanup3): New. Use absolute paths. No diff3_cmd. Add
svn_wc_context_t parameter
(svn_wc_cleanup2): Remove.
* subversion/libsvn_client/cleanup.c
(svn_client_cleanup): Use svn_wc_cleanup3. Remove use of diff3_cmd
]]]
Mvh
Daniel Näslund
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383303
Re: [PATCH] Use context_t for svn_wc_cleanup3
Posted by Paul Burba <pt...@gmail.com>.
On Thu, Aug 13, 2009 at 10:46 AM, Julian Foad<ju...@btopenworld.com> wrote:
> On Thu, 2009-08-13 at 16:23 +0200, Daniel Näslund wrote:
>> Hi!
>>
>> [ I could not send this message through my ordinary MUA, mutt.
>> My webmail does unfortunately encode all attachments as binary
>> data. Sorry. ]
>>
>> I have run make check with three FAILs:
>> external_tests.py 16: place a file external into a directory external.
>> switch_tests.py 18: switch shouldn't allow changing repos root
>> switch_tests.py 21: forced switch detectes tree conflicts.
>>
>> Reverted all changes, recompiled and the three tests still failed! Can
>> anyone confirm that those tests are failing on trunk?
>
> Yes, I confirm these are failing, both in my own testing and on the
> debian build-bot
> <http://crest.ics.uci.edu/buildbot/builders/i686-debian-sarge1%20shared%
> 20gcc-3.3.5/builds/1145>, since last Sunday.
>
> - Julian
I was just looking at the the switch test failures. Both are failing
on Window too, but interestingly the switch fails correctly (i.e. with
no segfault) if the cwd is no higher than the WC's immediate parent:
C:\SVN\src-trunk\Release\subversion\tests\cmdline\svn-test-work\working_copies>svn
switch "file:///C%3A/SVN/src-trunk/Debug/subversion/tests/cmdline/svn-test-work/repositories/switch_tests-18.other/A"
switch_tests-18\A
..\..\..\subversion\libsvn_client\switch.c:180: (apr_err=170009)
..\..\..\subversion\libsvn_client\ra.c:491: (apr_err=170009)
..\..\..\subversion\libsvn_ra\ra_loader.c:497: (apr_err=170009)
..\..\..\subversion\libsvn_ra\ra_loader.c:497: (apr_err=170009)
svn: Repository UUID '40da6a90-8424-aa46-b11c-ee91a6e53134' doesn't
match expected UUID '6f764266-4b7f-9646-a0bd-7e8d6c022d56'
Go higher than the immediate parent (as the test suite does) and boom:
C:\SVN\src-trunk\Release\subversion\tests\cmdline\svn-test-work>svn
switch "file:///C%3A/SVN/src-trunk/Debug/subversion/tests/cmdline/svn-test-work/repositories/switch_tests-18.other/A"
working_copies\switch_tests-18\A
..\..\..\subversion\libsvn_client\switch.c:180: (apr_err=170009)
..\..\..\subversion\libsvn_client\ra.c:491: (apr_err=170009)
..\..\..\subversion\libsvn_ra\ra_loader.c:497: (apr_err=170009)
..\..\..\subversion\libsvn_ra\ra_loader.c:497: (apr_err=170009)
svn: Repository UUID '40da6a90-8424-aa46-b11c-ee91a6e53134' doesn't
match expected UUID '6f764266-4b7f-9646-a0bd-7e8d6c022d56'
This application has halted due to an unexpected error.
A crash report and minidump file were saved to disk, you can find them here:
C:\DOCUME~1\pburba\LOCALS~1\Temp\svn-crash-log20090813093953.log
C:\DOCUME~1\pburba\LOCALS~1\Temp\svn-crash-log20090813093953.dmp
Please send the log file to svn-breakage@subversion.tigris.org to help
us analyse
and solve this problem.
NOTE: The crash report and minidump files can contain some sensitive information
(filenames, partial file content, usernames and passwords etc.)
Looks like r38654* was the offending revision, specifically the change
in libsvn_client/switch.c:svn_client__switch_internal() where
svn_wc__adm_open_anchor_in_context() replaced
svn_wc_adm_open_anchor(). Trying out Daniel's patch right now.
Paul
* Bert - Have you looked into this at all?
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383317
Re: [PATCH] Use context_t for svn_wc_cleanup3
Posted by Julian Foad <ju...@btopenworld.com>.
On Thu, 2009-08-13 at 16:23 +0200, Daniel Näslund wrote:
> Hi!
>
> [ I could not send this message through my ordinary MUA, mutt.
> My webmail does unfortunately encode all attachments as binary
> data. Sorry. ]
>
> I have run make check with three FAILs:
> external_tests.py 16: place a file external into a directory external.
> switch_tests.py 18: switch shouldn't allow changing repos root
> switch_tests.py 21: forced switch detectes tree conflicts.
>
> Reverted all changes, recompiled and the three tests still failed! Can
> anyone confirm that those tests are failing on trunk?
Yes, I confirm these are failing, both in my own testing and on the
debian build-bot
<http://crest.ics.uci.edu/buildbot/builders/i686-debian-sarge1%20shared%
20gcc-3.3.5/builds/1145>, since last Sunday.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383311
Re: [PATCH v2] Use context_t in svn_wc_cleanup3
Posted by "Hyrum K. Wright" <hy...@hyrumwright.org>.
On Aug 14, 2009, at 4:14 AM, Daniel Näslund wrote:
> On Thu, Aug 13, 2009 at 10:03:11AM -0500, Hyrum K. Wright wrote:
>>> Index: subversion/include/svn_wc.h
>> ===================================================================
>> svn_error_t *
>> +svn_wc_cleanup3(const char *abspath,
>>
>> We've been calling these "local_abspath" in general, to distinguish
>> from a repos_abspath.
>
> I've changed the names.
>
>> + * @deprecated Provided for backward compability with the 1.2 API.
>>
>> Keep the @since tag here.
>
> Done
>
>> You want to manually destroy the wc_ctx here, and use
>> svn_error_return
>> (see other examples in deprecated.c).
>
> I wonder what I was thinking here? Something vague about the scrope
> of a
> scratch_pool? Changed it anyway.
>
>> Is cleanup_internal() fetching an absolute path internally? Can it
>> be
>> simplified now that we guarantee it's getting an absolute path?
>
> There is no logic in update_internal for checking absolute paths.
>
>> }
>> Index: subversion/libsvn_client/cleanup.c
>> ===================================================================
>>
>> Not a bit deal, but probably save this last bit for a separate patch.
>
> I will do that.
>
>
> A strange thing: After running make check I get 18 FAILS:s:
>
> trunk> cat tests.log | grep ^FAIL
> FAIL: depth_tests.py 32: make sure update handle svn_depth_exclude
> properly
> FAIL: log_tests.py 18: test 'svn log -g' on a non-branching revision
> FAIL: log_tests.py 19: test 'svn log -g' a path added before merge
> FAIL: log_tests.py 20: test log -c for a single change
> FAIL: log_tests.py 22: test log -c on comma-separated list of changes
> FAIL: log_tests.py 23: svn log of two wc paths is disallowed
> FAIL: log_tests.py 24: test revprop retrieval
> FAIL: log_tests.py 25: log --xml escapes non-utf8 data (issue #2866)
> FAIL: log_tests.py 26: 'svn log -g target_with_bogus_mergeinfo'
> FAIL: log_tests.py 27: log -g and explicit mergeinfo replacing
> inherited
> FAIL: log_tests.py 28: log -g and simple propmod to merge-
> inheriting path
> FAIL: merge_tests.py 1: performing a merge, with mixed results
> FAIL: merge_tests.py 2: merge and add new files/dirs with history
> FAIL: merge_tests.py 3: merge that deletes items
> FAIL: merge_tests.py 4: some simple property merges
> FAIL: merge_tests.py 5: merging a file w/no explicit target path
> using -r
> FAIL: switch_tests.py 18: switch shouldn't allow changing repos root
> FAIL: switch_tests.py 21: forced switch detects tree conflicts
Those are all consecutive tests. Where you doing something
(rebuilding the binary or a dependency) on the system at the time
which would case the svn binary to be unavailable?
In any case, I don't get these locally, except for depth 18, which
currently fails on a clean working copy.
> But when running ./log_tests.py and ./merge_tests.py I get no FAIL:s.
> How can that be? Does this mean that those are failing or not?
>
> But theese three tests still fail, both on trunk and with my patch
> applied.
> depth_tests.py 23: mkae sure update handle svn_depth_exclude properly
> swithch_tests.py 18
> switch_tests.py 21
>
> Can someone confirm that depth_tests.py 23 is failing on trunk? I
> assume
> that the two switch_tests haven't been fixed since yesterday.
Confirmed (see above).
> Assuming that the patch is ok, what could be a good next step? Could
> any
> of theese work or do you have better suggestions from the top of your
> head?
You can now update any callers to use the new API. On a more general
node, I'm busy removing calls to svn_wc_entry() in libsvn_client. The
pattern should be obvious enough, so pick a location, and just dive in.
> Theese are called in svn_wc_cleanup3:
> * subversion/libsvn_wc/log.c
> (cleanup_internal): Uses adm_access_t. Should those be changed?
> (run_existing_logs): Uses adm_access_t.
>
> * subversion/libsvn_wc/lock.c
> (svn_wc__adm_steal_write_lock): Uses adm_access_t
>
> The next untouched function in the file:
> * subversion/include/svn_wc.h
> (svn_wc_revert3): This feels heavy. Uses adm_access_t
I made a few changes in parameter ordering and the way you construct
the "dumby" working copy context in the deprecated wrapper. You may
want to take a look as hints for next time. Overall, the patch looks
good, and I committed it in r38752.
Thanks!
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383662
New log message
Posted by Daniel Näslund <da...@longitudo.com>.
I forgot to say that I removed the changes in libsvn_client. Thus, the
new log message:
[[[
Use svn_wc_context_t and absolute paths in svn_wc_cleanup3. Remove
diff3_cmd parameter.
* subversion/include/svn_wc.h
(svn_wc_cleanup3): New.
(svn_wc_cleanup2): Deprecate.
* subversion/libsvn_wc/deprecated.c
(svn_wc_cleanup2): Reinplement as a wrapper.
* subversion/libsvn_wc/log.c
(svn_wc_cleanup3): New. Use absolute paths. No diff3_cmd. Add
svn_wc_context_t parameter
(svn_wc_cleanup2): Remove.
]]]
Mvh
Daniel
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383577
[PATCH v2] Use context_t in svn_wc_cleanup3
Posted by Daniel Näslund <da...@longitudo.com>.
On Thu, Aug 13, 2009 at 10:03:11AM -0500, Hyrum K. Wright wrote:
> > Index: subversion/include/svn_wc.h
> ===================================================================
> svn_error_t *
> +svn_wc_cleanup3(const char *abspath,
>
> We've been calling these "local_abspath" in general, to distinguish
> from a repos_abspath.
I've changed the names.
> + * @deprecated Provided for backward compability with the 1.2 API.
>
> Keep the @since tag here.
Done
> You want to manually destroy the wc_ctx here, and use svn_error_return
> (see other examples in deprecated.c).
I wonder what I was thinking here? Something vague about the scrope of a
scratch_pool? Changed it anyway.
> Is cleanup_internal() fetching an absolute path internally? Can it be
> simplified now that we guarantee it's getting an absolute path?
There is no logic in update_internal for checking absolute paths.
> }
> Index: subversion/libsvn_client/cleanup.c
> ===================================================================
>
> Not a bit deal, but probably save this last bit for a separate patch.
I will do that.
A strange thing: After running make check I get 18 FAILS:s:
trunk> cat tests.log | grep ^FAIL
FAIL: depth_tests.py 32: make sure update handle svn_depth_exclude properly
FAIL: log_tests.py 18: test 'svn log -g' on a non-branching revision
FAIL: log_tests.py 19: test 'svn log -g' a path added before merge
FAIL: log_tests.py 20: test log -c for a single change
FAIL: log_tests.py 22: test log -c on comma-separated list of changes
FAIL: log_tests.py 23: svn log of two wc paths is disallowed
FAIL: log_tests.py 24: test revprop retrieval
FAIL: log_tests.py 25: log --xml escapes non-utf8 data (issue #2866)
FAIL: log_tests.py 26: 'svn log -g target_with_bogus_mergeinfo'
FAIL: log_tests.py 27: log -g and explicit mergeinfo replacing inherited
FAIL: log_tests.py 28: log -g and simple propmod to merge-inheriting path
FAIL: merge_tests.py 1: performing a merge, with mixed results
FAIL: merge_tests.py 2: merge and add new files/dirs with history
FAIL: merge_tests.py 3: merge that deletes items
FAIL: merge_tests.py 4: some simple property merges
FAIL: merge_tests.py 5: merging a file w/no explicit target path using -r
FAIL: switch_tests.py 18: switch shouldn't allow changing repos root
FAIL: switch_tests.py 21: forced switch detects tree conflicts
But when running ./log_tests.py and ./merge_tests.py I get no FAIL:s.
How can that be? Does this mean that those are failing or not?
But theese three tests still fail, both on trunk and with my patch
applied.
depth_tests.py 23: mkae sure update handle svn_depth_exclude properly
swithch_tests.py 18
switch_tests.py 21
Can someone confirm that depth_tests.py 23 is failing on trunk? I assume
that the two switch_tests haven't been fixed since yesterday.
Assuming that the patch is ok, what could be a good next step? Could any
of theese work or do you have better suggestions from the top of your
head?
Theese are called in svn_wc_cleanup3:
* subversion/libsvn_wc/log.c
(cleanup_internal): Uses adm_access_t. Should those be changed?
(run_existing_logs): Uses adm_access_t.
* subversion/libsvn_wc/lock.c
(svn_wc__adm_steal_write_lock): Uses adm_access_t
The next untouched function in the file:
* subversion/include/svn_wc.h
(svn_wc_revert3): This feels heavy. Uses adm_access_t
Mvh
Daniel
Re: [PATCH] Use context_t for svn_wc_cleanup3
Posted by "Hyrum K. Wright" <hy...@hyrumwright.org>.
On Aug 13, 2009, at 9:23 AM, Daniel Näslund wrote:
> Hi!
>
> [ I could not send this message through my ordinary MUA, mutt.
> My webmail does unfortunately encode all attachments as binary
> data. Sorry. ]
And we're sorry that tigris.org is giving you fits. :(
> I have run make check with three FAILs:
> external_tests.py 16: place a file external into a directory external.
> switch_tests.py 18: switch shouldn't allow changing repos root
> switch_tests.py 21: forced switch detectes tree conflicts.
>
> Reverted all changes, recompiled and the three tests still failed! Can
> anyone confirm that those tests are failing on trunk?
>
> I have replaced all occurences of svn_wc_cleanup2 with cleanup3 in
> libsvn_client. Is it bad to do two different things in one patch?
> Since
> replacing all cleanup2 means that the wrapper in deprecated.c will not
> be tested?
I tend to do it in two separate commits, since (theoretically) they
are logically separated changes, and it gives me a chance to run the
test suite using just the wrapper. (And with larger changes, the
"updating callers" patch can be quite significant and actually
introduce bugs of its own.)
>
> [[[
> Use svn_wc_context_t and absolute paths in svn_wc_cleanup3. Make
> libsvn_client use svn_wc_cleanup3. Remove diff3_cmd parameter.
>
> * subversion/include/svn_wc.h
> (svn_wc_cleanup3): New.
> (svn_wc_cleanup2): Deprecate.
>
> * subversion/libsvn_wc/deprecated.c
> (svn_wc_cleanup2): Reinplement as a wrapper.
>
> * subversion/libsvn_wc/log.c
> (svn_wc_cleanup3): New. Use absolute paths. No diff3_cmd. Add
> svn_wc_context_t parameter
> (svn_wc_cleanup2): Remove.
>
> * subversion/libsvn_client/cleanup.c
> (svn_client_cleanup): Use svn_wc_cleanup3. Remove use of diff3_cmd
> ]]]
>
> Mvh
Overall, the patch looks good. I've noted a few things that are
convention-related, and some that are more technical, but not any that
are fatal. I look forward to the updated version of this patch.
> Index: subversion/include/svn_wc.h
===================================================================
--- subversion/include/svn_wc.h (revision 38718)
+++ subversion/include/svn_wc.h (arbetskopia)
@@ -5558,12 +5558,10 @@
/**
- * Recurse from @a path, upgrading to the latest working copy format if
+ * Recurse from @a abspath, upgrading to the latest working copy
format if
* @a upgrade_wc is set, and cleaning up unfinished log business.
Perform
* any temporary allocations in @a scratch_pool. Any working copy
locks
- * under @a path will be taken over and then cleared by this
function. If
- * @a diff3_cmd is non-NULL, then use it as the diff3 command for any
- * merging; otherwise, use the built-in merge code.
+ * under @a path will be taken over and then cleared by this function.
*
* WARNING: there is no mechanism that will protect locks that are
still
* being used.
@@ -5572,9 +5570,23 @@
* various points during the operation. If it returns an error
* (typically @c SVN_ERR_CANCELLED), return that error immediately.
*
- * @since New in 1.2.
+ * @since New in 1.7.
*/
svn_error_t *
+svn_wc_cleanup3(const char *abspath,
We've been calling these "local_abspath" in general, to distinguish
from a repos_abspath.
+ svn_wc_context_t *wc_ctx,
+ svn_cancel_func_t cancel_func,
+ void *cancel_baton,
+ apr_pool_t *scratch_pool);
+
+/**
+ * Similar to svn_wc_cleanup3() but uses relative paths and creates
its own
+ * swn_wc_context_t.
Need @c in front of svn_wc_context_t.
+ *
+ * @deprecated Provided for backward compability with the 1.2 API.
Keep the @since tag here.
+ */
+SVN_DEPRECATED
+svn_error_t *
svn_wc_cleanup2(const char *path,
const char *diff3_cmd,
svn_cancel_func_t cancel_func,
Index: subversion/libsvn_wc/deprecated.c
===================================================================
--- subversion/libsvn_wc/deprecated.c (revision 38718)
+++ subversion/libsvn_wc/deprecated.c (arbetskopia)
@@ -2268,6 +2268,27 @@
/*** From log.c ***/
svn_error_t *
+svn_wc_cleanup2(const char *path,
+ const char *diff3_cmd,
+ svn_cancel_func_t cancel_func,
+ void *cancel_baton,
+ apr_pool_t *pool)
+{
+ svn_wc__db_t *db;
+ svn_wc_context_t *wc_ctx;
+ const char *abspath;
Again, local_abspath.
+
+ SVN_ERR(svn_wc__db_open(&db, svn_wc__db_openmode_readwrite,
+ NULL, pool, pool));
+
+ SVN_ERR(svn_dirent_get_absolute(&abspath, path, pool));
+
+ SVN_ERR(svn_wc__context_create_with_db(&wc_ctx, NULL, db, pool));
+
+ return svn_wc_cleanup3(abspath, wc_ctx, cancel_func, cancel_baton,
pool);
You want to manually destroy the wc_ctx here, and use svn_error_return
(see other examples in deprecated.c).
+}
+
+svn_error_t *
svn_wc_cleanup(const char *path,
svn_wc_adm_access_t *optional_adm_access,
const char *diff3_cmd,
Index: subversion/libsvn_wc/log.c
===================================================================
--- subversion/libsvn_wc/log.c (revision 38718)
+++ subversion/libsvn_wc/log.c (arbetskopia)
@@ -2388,37 +2388,31 @@
return svn_wc_adm_close2(adm_access, scratch_pool);
}
-
svn_error_t *
-svn_wc_cleanup2(const char *path,
- const char *diff3_cmd, /* ### OBSOLETE */
+svn_wc_cleanup3(const char *abspath,
+ svn_wc_context_t *wc_ctx,
svn_cancel_func_t cancel_func,
void *cancel_baton,
- apr_pool_t *scratch_pool)
+ apr_pool_t * scratch_pool)
{
- svn_wc__db_t *db;
- const char *local_abspath;
int wc_format_version;
- SVN_ERR(svn_wc__db_open(&db, svn_wc__db_openmode_readwrite,
- NULL /* ### config */, scratch_pool,
scratch_pool));
+ SVN_ERR_ASSERT(svn_dirent_is_absolute(abspath));
- SVN_ERR(svn_dirent_get_absolute(&local_abspath, path, scratch_pool));
-
- SVN_ERR(svn_wc__internal_check_wc(&wc_format_version, db,
local_abspath,
+ SVN_ERR(svn_wc__internal_check_wc(&wc_format_version, wc_ctx->db,
abspath,
scratch_pool));
/* a "version" of 0 means a non-wc directory */
if (wc_format_version == 0)
return svn_error_createf(SVN_ERR_WC_NOT_DIRECTORY, NULL,
_("'%s' is not a working copy
directory"),
- svn_dirent_local_style(path,
scratch_pool));
+ svn_dirent_local_style(abspath,
scratch_pool));
if (wc_format_version < SVN_WC__VERSION)
return svn_error_create(SVN_ERR_WC_UNSUPPORTED_FORMAT, NULL,
_("Log format too old, please use "
- "Subversion 1.6 or earlier"));
+ "Subversion 1.7 or earlier"));
This should stay as "1.6 or earlier". The reasons for this are beyond
the scope of the review, but that text is intentional. :)
- return svn_error_return(cleanup_internal(db, path, cancel_func,
cancel_baton,
- scratch_pool));
+ return svn_error_return(cleanup_internal(wc_ctx->db, abspath,
cancel_func,
+ cancel_baton,
scratch_pool));
Is cleanup_internal() fetching an absolute path internally? Can it be
simplified now that we guarantee it's getting an absolute path?
}
Index: subversion/libsvn_client/cleanup.c
===================================================================
--- subversion/libsvn_client/cleanup.c (revision 38718)
+++ subversion/libsvn_client/cleanup.c (arbetskopia)
@@ -44,17 +44,12 @@
svn_client_ctx_t *ctx,
apr_pool_t *scratch_pool)
{
- const char *diff3_cmd;
+ const char *abspath;
svn_error_t *err;
- svn_config_t *cfg = ctx->config
- ? apr_hash_get(ctx->config, SVN_CONFIG_CATEGORY_CONFIG,
- APR_HASH_KEY_STRING)
- : NULL;
- svn_config_get(cfg, &diff3_cmd, SVN_CONFIG_SECTION_HELPERS,
- SVN_CONFIG_OPTION_DIFF3_CMD, NULL);
+ SVN_ERR(svn_dirent_get_absolute(&abspath, path, scratch_pool));
- err = svn_wc_cleanup2(path, diff3_cmd, ctx->cancel_func,
+ err = svn_wc_cleanup3(abspath, ctx->wc_ctx, ctx->cancel_func,
ctx->cancel_baton, scratch_pool);
svn_io_sleep_for_timestamps(path, scratch_pool);
return svn_error_return(err);
Not a bit deal, but probably save this last bit for a separate patch.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383319