On 10/17/07, David Glasser <glasser@davidglasser.net> wrote:
> While this code looks correct, it sure looks like you'd rather just be
> calling svn_wc__load_props instead of having svn_get_prop_diffs diff
> them and then undiff them yourself... This is suggesting more and
> more that you want to split the low-level application off into
> libsvn_wc, as we discussed a bit last night on IRC.
True, I've been feeling several times the need to use svn_wc__*
functions but couldn't because I was in libsvn_client. I think I'll
soon have to go the way you suggest if I keep bumping into this kind
of issue. The reason I'm not doing this right away is because
libsvn_client/merge -- which in logic is very similar to
libsvn_client/patch -- seems to sort this out pretty well (from where
it is, i.e. libsvn_client). Thus I suppose there's no reason
libsvn_client/patch can't do the same.
(Basically those scope problems I've met were because of differences
between merging and patching, like patch application takes place
offline, etc.)
> btw, have you looked at copy_file_administratively in
> libsvn_wc/copy.c? That's basically what you're trying to, um, copy
> (no pun intended).
Okay, just looked at it. Indeed, it does remind me those lines in
add_file_with_history :-) But hey, this is a static function, and the
only API that calls it is svn_wc_copy*, which I precisely couldn't use
and is the reason why I had to write such code. That sounds rather
paradoxical. Maybe I could modify svn_wc_copy2 and
copy_file_administratively to DTRT when src_path is svn_node_none? It
looks quite simple in fact. That would save some code redundancy and
minimize the code maintenance as well.
Should I work this out on the branch or send a patch?
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 17 23:03:16 2007