Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of jcorvel@gmail.com designates
 209.85.210.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1925822.W2HtcYFXhn@etoile>
References: <510A8FAA.2020903@mu.org> <201302041154.22334.stilor@att.net>
 <20130204211729.GI32109@byrne.stsp.name> <1925822.W2HtcYFXhn@etoile>
From: Johan Corveleyn <jcorvel@gmail.com>
Date: Tue, 5 Feb 2013 12:59:43 +0100
Message-ID: 
 <CAB84uBWw1rczgfD8YDjZGvVc92Ry8duM4kwX+MCBuYP-L=bQ0Q@mail.gmail.com>
Subject: Re: FreeBSD project and subversion.
To: Alexey Neyman <stilor@att.net>
Cc: Stefan Sperling <stsp@elego.de>, users@subversion.apache.org,
	Alfred Perlstein <bright@mu.org>
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Feb 5, 2013 at 1:39 AM, Alexey Neyman <stilor@att.net> wrote:
> On Monday, February 04, 2013 10:17:29 PM Stefan Sperling wrote:
>
>> On Mon, Feb 04, 2013 at 11:54:21AM -0800, Alexey Neyman wrote:
>
>> > On Thursday, January 31, 2013 09:08:20 am Stefan Sperling wrote:
>
>> > > BTW, I went over one of FreeBSD's svn wiki pages a while back, and
>> > > added
>
>> > > answers to open questions on this page:
>
>> > > https://wiki.freebsd.org/SubversionMissing
>
>> >
>
>> > Speaking of which:
>
>> >
>
>> > Is there a reason why it is necessary to use "the svn diff --old
>
>> > ^/somebranch --new ." instead of the intuitive "svn ^/somebranch ."?
>
>>
>
>> Would "svn diff ^/somebranch ." be synopsis 1?
>
>>
>
>> svn diff -rN:M ^/somebranch@HEAD .@HEAD
>
>
>
> It cannot be "synopsis 1", as its description states that "TARGETs may be
> all working copy paths or all URLs". In this case, we have one of each.
> Moreover, synopsis 1 says that for URLs, -r or -c must be present - and my
> example has no -r/-c option.

Sorry, that's not true. From 'svn help diff' of 1.7:

diff (di): Display the differences between two revisions or paths.
usage: 1. diff [-c M | -r N[:M]] [TARGET[@REV]...]
       2. diff [-r N[:M]] --old=OLD-TGT[@OLDREV] [--new=NEW-TGT[@NEWREV]] \
               [PATH...]
       3. diff OLD-URL[@OLDREV] NEW-URL[@NEWREV]

So for usage 1 the -c and -r are optional.

Also, the condition "may be all working copy paths or all URLs" is
pretty weak for deciding to use usage 1, because for usage 2
(--old/--new) you can just as well use two working copy paths or two
URLs. I think it would be even more confusing if 'svn diff A B' would
decide to use usage 1 if they are both URLs or both wc paths, and use
usage 2 if only one of them is a URL and the other a wc path (even
though usage 2 can just as well accomodate two URLs and two wc paths).

>
> So, the only possible use of this syntax would be synopsis 2:
>
>
>
>> svn diff --old ^/somebranch@HEAD --new .@HEAD
>
>> (i.e. show the difference between the two (path, revision) pairs
>
>> somebranch@HEAD and .@HEAD) ?
>
>>
>
>> > It has bugged me for a while until I discovered this --old/--new trick.
>
>>
>
>> I agree that --old --new syntax isn't intuitive at all.
>
>
>
> What adds oil to the fire is that the error message, which claims that
> "Target lists to diff may not contain both working copy paths and URL". If
> instead it said that the supplied syntax is ambiguous and suggested to use
> --new/--old for disambiguation, this would have saved a lot of frustration
> and would eliminate the need of "svn compare" subcommand :)
>
>
>
> For example:
>
> svn: Ambiguous target list (contains both work copy paths and URLs). Use
>
> --old/--new syntax to disambiguate.
>

Given what I said above, this can't be done in general (not if you
give two URLs or two wc paths, because then both synopsis 1 and 2 are
possible -- it would obviously break backwards compatibility if we
would now start erroring out on these, while these used to work fine
with automatically picking usage 1 before). Only if one of them is a
URL and the other a WC path, because we give an error message then
anyway.

-- 
Johan