[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-10-28 20:02:10 CET

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
Received on Sun Oct 28 20:02:21 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.