On Sun, 01 Apr 2007, Paul Burba wrote:
...
> > > > Also, is there any overlap with svn_client__get_prop_from_wc()?
> > >
> > > To the extent we are getting props yes, but
> > > svn_client__get_prop_from_wc() only gets one prop and
> > doesn't tell us
> > > if it was modified.
> >
> > I was wondering how much implementation these routines are
> > sharing, and whether it would make sense for them to share more...
>
> See last comment below...
>
> > > > We call svn_client__get_prop_from_wc() from
> > > > svn_client__parse_merge_info(), which is in turn called
> > from a loop
> > > > inside get_wc_merge_info() (meaning we're probably doing some
> > > > redudant work here).
> > >
> > > Hmmm, maybe bulk up get_wc_merge_info() so it knows not only if
> > > mergeinfo was inherited, but also if it is locally modfied?
> >
> > This is a moot point now, yes?
>
> With r24058 indeed it is as far as get_wc_or_repos_merge_info() goes...
>
> ...But if you were still thinking that props.c:modifed_props() and
> prop_commands.c:svn_client__get_prop_from_wc() might be able to share
> some implmentation then it looks like that really comes down to
> svn_wc_get_props_diffs()/svn_wc_prop_get(), where the real work of
> svn_client__get_prop_from_wc() is done, using modified_props(). It
> looks like there might be something doable there, though to my mind it
> would result in modified_props() trying to do so much that the code
> becomes unnecessarily complex and difficult to understand in pursuit of
> some code consolidation. Dunno really, would welcome anyone's thoughts.
Too much complexity is a good reason not to touch it.
> I'm kinda deep in the merge tracking elision stuff at the moment and
> would like to finish that first, but will circle back to this at some
> point.
Sure thing -- that's a lot higher priority, IMHO.
- Dan
- application/pgp-signature attachment: stored
Received on Mon Apr 2 19:24:30 2007