Daniel Rall wrote:
> Should we allow querying of merge sources by URL (doc string seems to
> indicate that we don't currently allow it)? If so, how are you assuming
> that the revision parameter will be passed now (e.g. in peg rev-style)?
> I think this needs a doc tweak either way to clarify things.
We query merge sources so we can perform a merge. We (currently) can't
merge *to* a URL, so there's no immediate use-case for querying potential
merge sources for one.
> The doc string on svn_client_suggest_merge_sources() (in svn_client.h)
> doesn't seem to reflect the fact that the suggestions are full URLs.
> Question: Are these URLs also peg rev-style?
Well, here's a question I had while making this change. They are full URLs
with no revision information attached to them, just as they were before I
abstracted out the code. But it does seem like they'd need at least some
kind of peg revision to be useful, doesn't it?
(As for the relative URL thing, that was another bit of lossage from my
corrupt working copy. I'll fix the docstring there.)
>> * subversion/libsvn_client/merge.c
>> (svn_client__get_repos_root): Was get_repos_root.
>> (svn_client_merge3): Update calls to svn_client__get_repos_root().
>> (svn_client_merge_peg3): Disallow missing source paths, and leave
>> merge source suggestion-taking to our caller. Update calls to
>> svn_client__get_repos_root().
>
> Are any doc string changes to svn_client_merge_peg3() necessary as a
> result of this change in behavior?
Oddly, no. That 'source' was made to be optional didn't seem to be
documented anywhere.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Tue Aug 28 15:34:06 2007