Re: svn commit: r27431 - trunk/subversion/libsvn_client

Karl Fogel wrote:
> "David Glasser" <glasser@davidglasser.net> writes:
>> On 10/26/07, Karl Fogel <kfogel@red-bean.com> wrote:
>>> cmpilato@tigris.org writes:
>>>> More work in issue #2953. Change the way merge source normalization
>>>> happens to account for the annoyance that given a segment of path FOO
>>>> and revision coverage from N to M (inclusive), you can't actually do
>>>> anything useful unless you expand the range to N-1 (exclusive) to M
>>>> (inclusive), and path location for N-1 (which might not be FOO, but
>>>> perhaps is whatever FOO was copied from in rN).
>>> I realize I'm stepping into a hornet's nest of complexity, but how is
>>>
>>> N(inclusive)-->M(inclusive)
>>>
>>> different from
>>>
>>> (N-1)(exclusive)-->M(inclusive)
>>>
>>> ...in an algebra following the normal rules?
>> I think it's about name resolution. (If a path is deleted in N, say.)
>
> That's the feeling I was getting, I just couldn't quite parse that
> from the above.

David's right. It matters only when something doesn't exist at the same
path in N-1 as it does in N, for the cases and code I'm looking it.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org