[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problem with suggestMergeSources() API and getCopySource() removal

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-08-28 19:00:18 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.