git svn -T svn://svn. ...
Fri Mar 18 14:53:00 GMT 2016
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
Thanks for the work on this and the upstream fixes.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin