On Thu, 03 Aug 2006, Madan S. wrote:
> 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.
...
> 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?
Good concern -- reference to the svn_client_ctx_t data type in
libsvn_wc is a no-go.
...
> 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.
The merge info of paths under TARGET_WCPATH will have bearing on how
merge info is updated; paths which have had local modifications in the
WC or which were modified by the merge must have their merge info
differences taken into consideration when updating the WC's merge
info.
> 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.
If we ended up not needing the recursion, a solution which combined
the "pristine or working value" behavior of pristine_or_working_propval()
with the "give me only one property value" behavior of svn_wc_prop_get()
would be ideal.
Assuming we need to call parse_merge_info() for 'copy' (and I think we
do), we should try stripping down the svn_client__get_prop_from_wc()
module-private API -- which I factored out especially for use on the
merge-tracking branch -- to an incarnation closer to the level of the
WC, preferably not polluted by the svn_client_ctx_t data type.
Basically, figure out how you can change those API to suite our needs,
since there are no compatibility concerns.
- Dan
- application/pgp-signature attachment: stored
Received on Fri Aug 4 05:01:19 2006