From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113563 invoked by alias); 18 Mar 2016 14:53:27 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 113548 invoked by uid 89); 18 Mar 2016 14:53:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=1.6, subversion, H*r:sk:d27-96-, Subversion X-HELO: mail-ig0-f176.google.com Received: from mail-ig0-f176.google.com (HELO mail-ig0-f176.google.com) (209.85.213.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 18 Mar 2016 14:53:20 +0000 Received: by mail-ig0-f176.google.com with SMTP id ig19so23446621igb.1 for ; Fri, 18 Mar 2016 07:53:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=YyTVEjoSDr/2HJLSp3qtKKvTPprWWSl8DOjqKwVvkqw=; b=dG3BQvtBd7qPXmOayN3deGRSy/4VYfCFlo1clkJwKNnIfKuyhT0KGshc4Gf5vtCKd/ HLKNEvPTAPN/ekxrcDlqCHXn1kGoXmSZCaQmCnxN/TmIXEYMb7n4a4d8xzruOTCfBSmC dsZeMC8o/HEiPpqGbY/CQaLvgUE2Nx2BAdjdj4QsSNuKUwz6dEM+b9po7rqv1pBnPZ55 R6MlDOAw6+DjSAmrDIgMMuO7BPxt6EpCMzzZhGwYdmQZqUDWYuMN8mb3C+LY3g1Ee8t3 yLbItuUQfpG0ZmRJIM3oBJcv6E3KKX2tQxTItfVsOIFWYhsJID7kebLnuz7Ur6zX2Aux As8A== X-Gm-Message-State: AD7BkJI5FkJyHo+lvId2NPgoiAasZ3Iv3cCh6w89lmKNCGewd88T67QutZ3pR+JNAFQAlA== X-Received: by 10.50.50.9 with SMTP id y9mr43539948ign.18.1458312797965; Fri, 18 Mar 2016 07:53:17 -0700 (PDT) Received: from [192.168.0.8] (d27-96-48-76.nap.wideopenwest.com. [96.27.76.48]) by smtp.gmail.com with ESMTPSA id n8sm5774101igv.5.2016.03.18.07.53.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Mar 2016 07:53:17 -0700 (PDT) Subject: Re: git svn -T svn://svn. ... To: cygwin@cygwin.com References: <56DF1ABE.9050007@gmail.com> <20160309194606.GE29016@dinwoodie.org> <20160309195636.GF29016@dinwoodie.org> <20160316183920.GQ29016@dinwoodie.org> From: cyg Simple Message-ID: <56EC1660.2060601@gmail.com> Date: Fri, 18 Mar 2016 14:53:00 -0000 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 X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00388.txt.bz2 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