Re: [merge-tracking] record mergeinfo on wc to wc copy

On Tue, 01 Aug 2006 22:07:57 +0530, Daniel Rall <dlr@collab.net> wrote:

> On Tue, 01 Aug 2006, Madan S. wrote:
> ...
>> >>yeah, and I think we can use the existing update_wc_merge_info()
>> >>function.

[snip]

> We might be able to use something like update_wc_merge_info() for copy
> ops -- dunno yet.

IMHO, after reading through update_wc_merge_info(), I think it is the
right function. But for one problem, which is:

I just tried writing some code to call update_wc_merge_info() from
svn_wc_copy2(). But for this we need

- the client ctx in svn_wc_copy2() to pass to update_wc_merge_info(), and
hence...
- remove the cancel_func, cancel_baton, notify_func, notify_baton
parameters, introduce the svn_client_ctx_t parameter instead, creating
svn_wc_copy3() and deprecating svn_wc_copy2()

My concern was: Is it acceptable to use a svn_client_ctx_t structure in a
wc library?

(If yes, I will send across the patch that I just wrote. But I doubt it.)

If no, I have a bigger question. The above ctx is required by
update_wc_merge_info() to be passed to parse_merge_info(). IIUC,
parse_merge_info() will obtain the mergeinfo of the provided wcpath (we
dont need to recurse here). For this we should not need a client context -
logically.

But currently, parse_merge_info() calls svn_client__get_prop_from_wc (with
recurse = TRUE? why?), where the ctx is used.

Am wondering why parse_merge_info() cannot directly use
pristine_or_working_propval(). This would not only solve the problem of
having to pass client ctx from a wc call, but would also be, IMHO, the
logical thing - not using a client ctx for obtaining a wc information,
non-recursively.

Regards,
Madan U S
www.symonds.net/~madan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 2 19:58:07 2006