Mark Phippard wrote:
> On 8/28/07, C. Michael Pilato <cmpilato@collab.net> 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.
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.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Tue Aug 28 17:13:20 2007