DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=Ke2pNmcxJp9/DU3o
	W7JY8g4BVJacctmzToFsNHuWlOmHXfgAG52pnTHP2vt5Y0EBNHkUVlJydw9e9nL7
	oB1b/z1BVA67tRfYxRJMwT36MrGOP0kVYkGuadrOYI8lIkDhEWWUQK6ZUXVRHtXt
	z9OkkvbMIoHO0HBa8xRGNbtLlpo=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Subject: Re: git svn -T svn://svn. ...
To: cygwin AT cygwin DOT com
References: <56DF1ABE DOT 9050007 AT gmail DOT com> <20160309194606 DOT GE29016 AT dinwoodie DOT org> <20160309195636 DOT GF29016 AT dinwoodie DOT org> <20160316183920 DOT GQ29016 AT dinwoodie DOT org>
From: cyg Simple <cygsimple AT gmail DOT com>
Message-ID: <56EC1660.2060601@gmail.com>
Date: Fri, 18 Mar 2016 10:53:20 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <20160316183920.GQ29016@dinwoodie.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

On 3/16/2016 2:39 PM, Adam Dinwoodie wrote:
> On Wed, Mar 09, 2016 at 07:56:36PM +0000, Adam Dinwoodie wrote:
>> On Wed, Mar 09, 2016 at 07:46:06PM +0000, Adam Dinwoodie wrote:
>>> On Tue, Mar 08, 2016 at 01:32:30PM -0500, cyg Simple wrote:
>>>> Using the latest production release 2.4.1(1) the command is removing the
>>>> / after the svn: leaving svn:/svn which isn't correct.  Using
>>>> 'svn://svn' doesn't help either.
>>>>
>>>> (2) $ git svn init -T 'svn://svn.code.sf.net/p/squirrelmail/code/trunk'
>>>> E: 'svn:/svn.code.sf.net/p/squirrelmail/code/trunk' is not a complete
>>>> URL  and a separate URL is not specified
>>>
>>> I'm seeing the same behaviour on local builds of both v2.7.0 and v2.2.0,
>>> and when using http:// URIs as well as svn:// ones.  Very sad.
>>>
>>> It's not immediately obvious what's going wrong here, and I don't
>>> currently have much spare time for digging, but I'll add it to my queue
>>> to investigate the problem / report it upstream to see if anyone else
>>> has any cunning ideas.
>>
>> I've found a work-around.  I'm surprised it works, but it evidently
>> does, so...
>>
>> If you do the `git svn init` without the `-T` argument, then set up the
>> branches to fetch explicitly using `git config`, everything seems to
>> work fine:
>>
>>     $ git svn init svn://svn.code.sf.net/p/squirrelmail/code
>>     Initialized empty Git repository in /home/add/tmp/.git/
>>
>>     $ git config svn-remote.svn.fetch trunk:refs/remotes/origin/trunk
>>
>>     $ git svn fetch
>>     r1 = 12dc820c417dc5f12723307a3fcfa4629ea972fb (refs/remotes/origin/trunk)
>>             A       squirrelmail/ATHORS
>>             A       squirrelmail/login.php3
>>             A       squirrelmail/signout.php3
>>     ...
> 
> A better work-around: don't specify the full URL in the -T argument:
> 
>     git svn init svn://svn.code.sf.net/p/squirrelmail/code -T trunk
> 
> The underlying bug here is that Git treats anything passed in a -T
> argument as if it were a directory, and attempts to "canonicalize" it,
> which includes squashing consecutive "/"s.
> 
> That doesn't match the Git SVN man page, which states "The Subversion
> URL may be specified as ...  full URL arguments to -T/-t/-b" and "[The
> -T flag] can point to a relative repository path ... or a full url", but
> it looks like all the test scripts in Git only handle relative paths in
> the -T argument.
> 
> Specifying the URL as a positional argument, and just the directory name
> in the -T argument is what all the Git test scripts do, which is
> presumably why this has never previously been spotted.
> 
> I'm in the process of writing this up to submit upstream.
> 
> As much for my own benefit: the reason I don't see this bug on my CentOS
> box is that it has Subversion 1.6; the canonicalization function in
> Subversion 1.6 (and earlier?) is different and doesn't cause this bug to
> manifest.

Thanks for the work on this and the upstream fixes.

-- 
cyg Simple

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple