Mark Phippard wrote:
>> Also, now that I've finished typing the above, I'm wondering how these APIs
>> deal with recursion and children of directories which have differing
>> mergeinfo than their parents. Does the API not care, and calling program
>> handle recursing and such? Does the API take a depth flag and move to a
>> callback model (one call per unique set of things to report)? Since files
>> and directories could have come into existence at different times, does this
>> mean we've got to do expensive history lookups for each individual item? Am
>> I so completely off-base with the ideas behind these APIs answering these
>> questions would be more costly than just whacking me with a clue stick?
>
> Forgetting the gory details and focusing on the user perspective. I
> have presented you this dialog which is a filtered list of revisions
> that are available to merge. I would say that any revision that was
> not completely merged should still appear in the list, as it is still
> available.
I agree with your user perspective. Now, what in the world does that mean
from an implementation standpoint? (Those "gory details" are the part I'm
rather most concerned with.)
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Tue Sep 11 16:12:24 2007