[Patch] RE: Why was svn_client_mergeinfo_get_merged removed?

        Hi,

Here is a patch that reintroduces the svn_client_mergeinfo_get_merged() and
svn_client_mergeinfo_get_eligible() (former
svn_client_mergeinfo_get_available()) API's.

I extended the svn_client_mergeinfo_get_available() API with the peg
revision introduced in the new api's.

(I tested the implementation of the commands in the SharpSvn development
environment in that they return the same data as before on the collab merge
demo repository).

An other change is that svn_client_suggest_merge_sources() started returning
repository local paths instead of full urls, while the documentation still
says it should return full urls. (This change was merged to 1.5.x in the
same merge as the other changes)

        Bert

> -----Original Message-----
> From: Stefan Küng <tortoisesvn_at_gmail.com> [mailto:=?ISO-8859-
> 1?Q?Stefan_K=FCng_<tortoisesvn_at_gmail.com>?=]
> Sent: zondag 6 april 2008 11:05
> To: dev_at_subversion.tigris.org
> Cc: Bert Huijben (TCG)
> Subject: Re: Why was svn_client_mergeinfo_get_merged removed?
>
> Bert Huijben (TCG) wrote:
> >> -----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()
>
> These may be replacements, but they work and are used completely
> different. IMHO a replacement is something I can use instead of the
> replaced thing without changing too much. These are not replacements,
> these are alternatives.
>
> > 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).
>
> That's what I discovered too. Right now, I'm thinking of dropping the
> feature in TSVN.
>
> 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