> -----Original Message-----
> From: Stefan Küng <tortoisesvn_at_gmail.com> [mailto:=?ISO-8859-
> Hi,
>
> When I updated today, I discovered that the API
> svn_client_mergeinfo_get_merged() got removed from the 1.5.x branch. I
> was using this API in TSVN to mark already merged revisions in the log
> dialog.
>
> Is there a reason why this was removed? And why from an .x branch? I
> now
> have to either find another way to get that feature back, or drop it
> completely :(
svn_error_t *
svn_client_mergeinfo_log_merged(const char *path_or_url,
const svn_opt_revision_t *peg_revision,
const char *merge_source_url,
const svn_opt_revision_t *src_peg_revision,
svn_log_entry_receiver_t receiver,
void *receiver_baton,
svn_boolean_t discover_changed_paths,
const apr_array_header_t *revprops,
svn_client_ctx_t *ctx,
apr_pool_t *pool);
and
svn_error_t *
svn_client_mergeinfo_log_eligible(const char *path_or_url,
const svn_opt_revision_t *peg_revision,
const char *merge_source_url,
const svn_opt_revision_t
*src_peg_revision,
svn_log_entry_receiver_t receiver,
void *receiver_baton,
svn_boolean_t discover_changed_paths,
const apr_array_header_t *revprops,
svn_client_ctx_t *ctx,
apr_pool_t *pool);
Are the replacement methods for svn_client_mergeinfo_get_merged() and
svn_client_mergeinfo_get_available()
The log messages talk about cleaning up the api, but I see some problem in
using the new api's over the old ones.
The new ones always call svn_client_log*() to get the results, which has at
least some and in some cases a major performance impact. (And in the case of
your new TortoiseSVN doesn't allow re using the existing knowledge in the
log message cache).
If I look at the implementation the number of log messages retrieved from
the server is far larger than the number of messages returned to the
receiver. (It receives all log messages between the first and last listed
revisisions).
I would assume in a few months a
# svn mergeinfo http://svn.collab.net/repos/svn/branches/trunk
http://svn.collab.net/repos/svn/branches/1.5.x
Will take minutes extra to complete because of this api change.
(svn_client_log without retrieving properties or paths is not that bad as it
would seem; but skipping that part makes it possible to optimize the user
performance in applications like TortoiseSVN and AnkhSVN)
Just for fun I tried to call:
# svn-win32 mergeinfo http://svn.collab.net/repos/svn/trunk
http://svn.collab.net/repos/svn/branches/1.4.x
svn: '&V' is not a working copy
svn: Can't open file '&V\.svn\entries': The system cannot find the path
specified.
Which didn't give me the very slow call I expected but only some new bug
triggering instantly
Could we get the old 1.5 api's back?
(Not just the old calling convention as previously in trunk please; as that
would give you the speed impact of the new version with just the calling
options of the old)
Bert
>
> Stefan
>
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-06 10:55:15 CEST