Bug 3145 - spaces in repository names causing problems: % codes made in local directory name upon cloning
Summary: spaces in repository names causing problems: % codes made in local directory ...
Status: RESOLVED FIXED
Alias: None
Product: Mercurial
Classification: Unclassified
Component: Mercurial (show other bugs)
Version: unspecified
Hardware: All All
: normal bug
Assignee: Bugzilla
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-09 09:13 UTC by Garrett Mitchener
Modified: 2012-12-22 18:50 UTC (History)
10 users (show)

See Also:
Python Version: ---


Attachments
(34 bytes, text/html)
2011-12-09 20:27 UTC, Frank Kingswood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Garrett Mitchener 2011-12-09 09:13 UTC
Copy of issue 2983: There are two problems with remote repository spaces with 
names: The command

hg clone "ssh:server/foo bar"

does several arguably wrong things depending on the exact revision.

This issue is about how the local directory is created with % codes in place 
of spaces.
Comment 1 Garrett Mitchener 2011-12-09 09:14 UTC
Sort of.  I think that if

hg clone '/path/foo bar'

clones a repository into 'foo bar', then

hg clone 'ssh:server/foo bar'

should do the same.  Or if that's not possible, then

hg clone ssh:server/'foo\ bar'

ought to work.

Here's what I see with hg 1.9.2 as distributed with fedora 16

$ hg clone 'ssh://grograman/tmp/foo bar'
remote: hg: unknown command 'bar'
abort: no suitable response from remote hg!

$ hg clone ssh://grograman/tmp/foo%20bar
remote: hg: unknown command 'bar'
abort: no suitable response from remote hg!

$ hg clone 'ssh://grograman/tmp/foo\ bar'
destination directory: foo%5C%20bar
requesting all changes
adding changesets
adding manifests
adding file changes
added 8 changesets with 8 changes to 1 files
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

which puts the repository into foo%5C%20bar.  Same with "" quotes. Same if I 
put the quotes just around 'foo\ bar'.  None of this consistent with the 
rsync or ssh examples you posted.

When I use the hg development version,

$ hg clone 'ssh://grograman/tmp/foo bar'

puts the repository into foo%20bar, again, not quite right.

$ hg clone 'ssh://grograman/tmp/foo\ bar'
remote: abort: There is no Mercurial repository here (.hg not found)!
abort: no suitable response from remote hg!

So it's not so much the quoting I have to do to the ssh URL, but whether the 
destination on the local machine is what's expected.
Comment 2 Thomas Arendsen Hein 2011-12-09 09:18 UTC
adjusting attributes
Comment 3 Frank Kingswood 2011-12-09 20:27 UTC
I think the solution is to let hg.defaultdest parse the URL correctly.

--- a/mercurial/hg.py	Fri Dec 09 17:58:12 2011 +0100
+++ b/mercurial/hg.py	Sat Dec 10 10:23:49 2011 +0800
@@ -105,7 +105,7 @@

  def defaultdest(source):
      '''return default destination of clone if none is given'''
-    return os.path.basename(os.path.normpath(source))
+    return os.path.basename(os.path.normpath(util.url(source).path))

  def share(ui, source, dest=None, update=True):
      '''create a shared repository'''
Comment 4 Bugzilla 2012-05-12 09:26 UTC

--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:26 EDT  ---

This bug was previously known as _bug_ 3145 at http://mercurial.selenic.com/bts/issue3145
Imported an attachment (id=1610)
Comment 5 HG Bot 2012-10-19 17:12 UTC
Fixed by http://selenic.com/repo/hg/rev/b32e55e6c3c7
Matt Mackall <mpm@selenic.com>
clone: don't %-escape the default destination (issue3145)

(please test the fix)