Mark Phippard wrote:
> On 8/28/07, C. Michael Pilato <cmpilato@collab.net> wrote:
>> Mark Phippard wrote:
>>>> suggestMergeSources() only returns URLs -- no peg revisions. Now, this
>>>> isn't anything new -- the code I abstracted into this API was always doing
>>>> this. But it does strike me as odd. If a merge target tells me that it has
>>>> merge info from /branches/somebranch, and that that location would make a
>>>> nice, sane, merge source, that's great. But what if /branches/somebranch
>>>> has been renamed to something else?
>>> In our GUI client, we are always using HEAD for peg revision. It is
>>> not a perfect solution, but the UI complexity of adding peg revision
>>> and then having to explain to users what it means just seems to high.
>>>
>>> You are obviously asking about the API level.
>> Indeed, I am. And a sane GUI client would get from a sane underlying API
>> URL@PEG, and verify that URL@HEAD and URL@PEG are suitably related before
>> trusting that result and presenting it to the user.
>
> That might be the sane thing to do, but it would be overly expensive
> in my opinion. In addition, whatever API might exist to do such a
> comparison is not exposed to me via the API I use.
Okay. Well, I can teach svn_client_suggest_merge_sources() to accept
path_or_url + revision easy enough, and am doing so now.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Tue Aug 28 18:57:34 2007