You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@red-bean.com> on 2007/10/26 22:49:36 UTC
Re: svn commit: r27431 - trunk/subversion/libsvn_client
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?
Also, I didn't understand how the last clause of the last sentence
above fits in. Is a verb phrase missing or something?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r27431 - trunk/subversion/libsvn_client
Posted by "C. Michael Pilato" <cm...@collab.net>.
Karl Fogel wrote:
> "David Glasser" <gl...@davidglasser.net> writes:
>> On 10/26/07, Karl Fogel <kf...@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 <cm...@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
Re: svn commit: r27431 - trunk/subversion/libsvn_client
Posted by Karl Fogel <kf...@red-bean.com>.
"David Glasser" <gl...@davidglasser.net> writes:
> On 10/26/07, Karl Fogel <kf...@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r27431 - trunk/subversion/libsvn_client
Posted by David Glasser <gl...@davidglasser.net>.
On 10/26/07, Karl Fogel <kf...@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.)
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org