[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 17:02:07 CEST

Mark Phippard wrote:
> I came up with a scenario where the recent API change to add the new
> suggestMergeSources API and possibly remove getCopySource has caused a
> problem.
>
> In the GUI merge client I am working on we recently added support to
> merge to multiple projects at the same time. Basically, this is a UI
> feature where we figure out the common root of the selected projects,
> base the UI off that, and then run merge once for each selected
> project.
>
> Here are the problems:
>
> 1) The new API does not work with a URL. In our scenario, the common
> local path is not a WC, so we need to use the common URL of the
> selections to get the suggested merge information.
>
> 2) If we do not remove the getCopySource() API we could just go back
> to using that since it did work OK with a URL. As of last night, the
> plan was to remove this API as we did not see a need for it.
>
> It does not matter to me which way we want to go with this. I think
> that this is a valid scenario and suggestMergeSources probably ought
> to be modified to support a URL.
>

Here's another problem that maybe someone can help me to understand:

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?

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Tue Aug 28 16:59:23 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.