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

Re: [SVNMERGE][PATCH] handle -r X-Y, where X > Y

From: Madan U Sreenivasan <madan_at_collab.net>
Date: 2006-05-16 07:55:24 CEST

On Tue, 16 May 2006 07:43:26 +0530, Archie Cobbs <archie@dellroad.org>

> Giovanni Bajo wrote:
>> Madan U Sreenivasan <madan@collab.net> wrote:
>>>> [[[
>>>> Accept -rX-Y, for all svnmerge commands, where X > Y.
>>>> Before this patch, empty RevisionSet()s were created when X > Y.
>> Rationale? "svn merge" accepts the reversed order with a different
>> semantic
>> (reversed merge). I'm worried about the confusion that can issue. I am
>> +1 on a
>> patch that errors out when X > Y until there is agreement on how to
>> best handle
>> this.
> I agree... arguably revisions "456-123" more likely means "the empty
> set".

sorry, I beg to differ.

On a deeper aspect of revision range, revision range is X-Y which means
all numbers between X and Y (inclusive of X and Y). It does not
necessarily mean X->Y, meaning all number between X and Y, moving on the
positive scale - which would still NOT be an empty set.(For example, -r
45-30 in this case would be 'the set of all whole numbers -

I fail to understand this logic of empty set.

> Automated tools that use svnmerge might emit such reversed ranges,
> and they would probably expect the empty set too.

could you give some specific example for me to understand here pl.

> This reminds me of an annoying problem I discovered in MySQL today,
> which is that you can't say "... WHERE foo IN ( )" .. i.e, query
> membership in an empty set (this is what some automatically generated
> query strings may try to do).

ah the classic... I guess it is available in the latest versions (am not a
db guy... just hearsay)

But wrt svnmerge, we are talking of correct functionality and not lack of


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 16 07:25:08 2006

This is an archived mail posted to the Subversion Dev mailing list.