Uploaded image for project: 'Bamboo Data Center'
  1. Bamboo Data Center
  2. BAM-7206

File notation is not working for the Hg Repository URL

      The Hg docs provide examples with 2 file notations:

      local/filesystem/path[#revision]
      AND
      file://local/filesystem/path[#revision]
      

      Only the first works.

      If the second is used, the attached error is reported.

            [BAM-7206] File notation is not working for the Hg Repository URL

            Monique Khairuliana (Inactive) made changes -
            Workflow Original: Bamboo Workflow 2016 v1 - Restricted [ 1438143 ] New: JAC Bug Workflow v3 [ 3381268 ]
            Status Original: Resolved [ 5 ] New: Closed [ 6 ]
            Owen made changes -
            Workflow Original: Bamboo Workflow 2016 v1 [ 1412149 ] New: Bamboo Workflow 2016 v1 - Restricted [ 1438143 ]
            Marek Went (Inactive) made changes -
            Workflow Original: Bamboo Workflow 2014 v2 [ 612700 ] New: Bamboo Workflow 2016 v1 [ 1412149 ]
            James Dumay made changes -
            Workflow Original: Bamboo Workflow 2014 [ 597005 ] New: Bamboo Workflow 2014 v2 [ 612700 ]
            James Dumay made changes -
            Workflow Original: Bamboo Workflow 2010 [ 257073 ] New: Bamboo Workflow 2014 [ 597005 ]
            SlawekA (Inactive) made changes -
            Resolution New: Invalid [ 6 ]
            Status Original: Open [ 1 ] New: Resolved [ 5 ]

            Indeed, the RFC-1738 does not mention the file:/path (single slash) as valid, although it does seem to work as expected. It is compatible with RFC-3986 uri syntax, though.

            To sum up:

            • if you use file:// (double slash), the next part is host name not the first element of absolute path.
            • if you mean absolute path on local machine, use 3 slashes (as per RFC) or single slash (as it also seems to work)
            • we pass it directly to hg command so all complaints should go to hg authors

            I'm closing this isse as "invalid"

            SlawekA (Inactive) added a comment - Indeed, the RFC-1738 does not mention the file:/path (single slash) as valid, although it does seem to work as expected. It is compatible with RFC-3986 uri syntax, though. To sum up: if you use file:// (double slash), the next part is host name not the first element of absolute path. if you mean absolute path on local machine, use 3 slashes (as per RFC) or single slash (as it also seems to work) we pass it directly to hg command so all complaints should go to hg authors I'm closing this isse as "invalid"
            SlawekA (Inactive) made changes -
            Assignee Original: Renan Battaglin [ rbattaglin ] New: SlawekA [ sginter ]

            AntonA added a comment - - edited

            Slawek and Piotr,

            I am not an expert on the subject of URLs, but I think there is a lot of confusion here.

            From what I know, in URLs the first part is <protocol_name>://. Where <protocol_name> is e.g. http, https, ssh, and file. the protocol name should be separated from the rest of the URL with ://. So, I think of the "file://" part of the URL, as the "protocol part". The rest of the URL starts from there. Does this make sense?

            So, file:///Users/amazkovoi/src/atlassian/fe-hg is a correct URL. Where "file://" is the protocol part, and "/Users/amazkovoi/src/atlassian/fe-hg" is the absolute path to the repository.

            The URL is actually a short form of file://localhost/Users/amazkovoi/src/atlassian/fe-hg

            The file://localhost/Users/amazkovoi/src/atlassian/fe-hg URL explicitly specifies the hostname, which is "localhost", and then it shows the absolute path, which is "/Users/amazkovoi/src/atlassian/fe-hg".

            With the "file://" protocol, "localhost" is the default host. It looks like hg ignores the hostname even if it is part of the URL and assumes localhost.

            So for me all of the following URLs worked:

            1. file:///Users/amazkovoi/src/atlassian/fe-hg
            2. file://localhost/Users/amazkovoi/src/atlassian/fe-hg
            3. file://blah/Users/amazkovoi/src/atlassian/fe-hg

            Of course, I have a Hg repo at the /Users/amazkovoi/src/atlassian/fe-hg path on my machine.

            Also, the "hg help urls" command on Mac for Hg version:
            Mercurial Distributed SCM (version 1.6.4+20101001)

            Is correct. It only talks about the file://local/filesystem/path[#revision] URLs form, which works fine, and as far as I know is perfectly allowed by the URL RFC.

            Please let me know if you think I am wrong about something here.

            Cheers,
            Anton

            AntonA added a comment - - edited Slawek and Piotr, I am not an expert on the subject of URLs, but I think there is a lot of confusion here. From what I know, in URLs the first part is <protocol_name>://. Where <protocol_name> is e.g. http, https, ssh, and file. the protocol name should be separated from the rest of the URL with ://. So, I think of the "file://" part of the URL, as the "protocol part". The rest of the URL starts from there. Does this make sense? So, file:///Users/amazkovoi/src/atlassian/fe-hg is a correct URL. Where "file://" is the protocol part, and "/Users/amazkovoi/src/atlassian/fe-hg" is the absolute path to the repository. The URL is actually a short form of file://localhost/Users/amazkovoi/src/atlassian/fe-hg The file://localhost/Users/amazkovoi/src/atlassian/fe-hg URL explicitly specifies the hostname, which is "localhost", and then it shows the absolute path, which is "/Users/amazkovoi/src/atlassian/fe-hg". With the "file://" protocol, "localhost" is the default host. It looks like hg ignores the hostname even if it is part of the URL and assumes localhost. So for me all of the following URLs worked: file:///Users/amazkovoi/src/atlassian/fe-hg file://localhost/Users/amazkovoi/src/atlassian/fe-hg file://blah/Users/amazkovoi/src/atlassian/fe-hg Of course, I have a Hg repo at the /Users/amazkovoi/src/atlassian/fe-hg path on my machine. Also, the "hg help urls" command on Mac for Hg version: Mercurial Distributed SCM (version 1.6.4+20101001) Is correct. It only talks about the file://local/filesystem/path[#revision ] URLs form, which works fine, and as far as I know is perfectly allowed by the URL RFC. Please let me know if you think I am wrong about something here. Cheers, Anton

            Actually, that's a mistake repeated so many times that it should be used as correct notation

            If you use file://Users/dir the Users part is treated as host part (ignored with file: protocol) and the dir part is /dir
            At least, this is how hg interpretes the url on Linux.
            The correct url is with 1 slash (file:/absolute/path) or none (file:relative/path)
            3 slashes work but don't make too much sense.

            I dare to say: hg help urls lies about file:// url syntax
            At least the 1.6.4 on Linux
            By lies I mean it does not handle the file://absolute/path as /absolute/path despite what description suggests.

            Questions:

            • should we warn the user when we see file://path url that is almost surely wrong?
            • should we transparently handle that and translate to file:/path ?

            SlawekA (Inactive) added a comment - Actually, that's a mistake repeated so many times that it should be used as correct notation If you use file://Users/dir the Users part is treated as host part (ignored with file: protocol) and the dir part is /dir At least, this is how hg interpretes the url on Linux. The correct url is with 1 slash ( file:/absolute/path ) or none ( file:relative/path ) 3 slashes work but don't make too much sense. I dare to say: hg help urls lies about file:// url syntax At least the 1.6.4 on Linux By lies I mean it does not handle the file://absolute/path as /absolute/path despite what description suggests. Questions: should we warn the user when we see file://path url that is almost surely wrong? should we transparently handle that and translate to file:/path ?

              sginter SlawekA (Inactive)
              rbattaglin Renan Battaglin
              Affected customers:
              0 This affects my team
              Watchers:
              0 Start watching this issue

                Created:
                Updated:
                Resolved: