On 8/28/07, C. Michael Pilato <email@example.com> wrote:
> 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?
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.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Aug 28 17:01:51 2007