On Thu, 03 Aug 2006, Madan S. wrote:
> On Tue, 01 Aug 2006 22:07:57 +0530, Daniel Rall <firstname.lastname@example.org> wrote:
> >On Tue, 01 Aug 2006, Madan S. wrote:
> >>>>yeah, and I think we can use the existing update_wc_merge_info()
> 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
> - 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 -
> 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
> 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.
Received on Fri Aug 4 05:01:19 2006
- application/pgp-signature attachment: stored