Issue #351: SSH for permanent repo reference
| Reported by: | Ross Thomas |
| State: | resolved |
| Created on: | 2020-01-20 21:59 |
| Updated on: | 2020-01-22 20:21 |
Description
In the https interface there is a ‘Permanent URL’ that references a repo by it’s internal ‘id’ (e.g. https://…/_1). This same repo reference fails when using the SSH interface (i.e. ssh://…/_1).
$ hg clone ssh://…/_1 my-name-for-repo
remote: abort: Access to '_1/' denied
abort: no suitable response from remote hg!
Not sure if this is a bug or a feature request.
Kallithea version: 0.5.0 (current head of repo: 155c52d8f210)
TIA.
Attachments
Comments
Comment by Ross Thomas, on 2020-01-20 22:03
Comment by Mads Kiilerich, on 2020-01-22 11:31
True. The UI got weird and complex when having both https and ssH URLs and readable and numeric URLs. We thus decided to keep numeric URLs for backward compatibility but not advocate them.
Also, I don’t see many relevant use cases for numeric URLs. If a repo name changes, any automation that use the repo should probably also be changed … or at least be updated to be explicit and consistent with the new name.
Can you say more about your use case vs the thoughts and design decisions outlined above?
Comment by Ross Thomas, on 2020-01-22 19:04
If this is a design decision then I’m happy and I’ll close this issue.
The numeric repo name was being bandied about here as a work-around for the two ‘inconvenient’ differences between BB & Kallithea wrt repo naming: flat name-space vs hierarchy enforcement; and case sensitivity.
None of us are really a fan of the numeric repo suggestion and it was only while investigating that as a least-best option that we tripped over the apparent discrepancy.
Comment by Ross Thomas, on 2020-01-22 19:05
Neither a bug nor a feature request.
Comment by Thomas De Schampheleire, on 2020-01-22 19:45
With respect to:
two ‘inconvenient’ differences between BB & Kallithea wrt repo naming: flat name-space vs hierarchy enforcement; and case sensitivity.
Can you clarify what is your ideal?
Kallithea can do both a flat namespace as a hierarchy (using repository groups).
I guess the repositories in Kallithea are case sensitive. Are they not in Bitbucket?
Comment by Ross Thomas, on 2020-01-22 20:10
We have adjusted to life in Kallithea (KT) so our ‘ideal’ is in line with it.
Well, I should say, re-adjusted as we were once on KT, then forced to use BB and are now (happily) back again. 
Kallithea can do both a flat namespace as a hierarchy (using repository groups).
In BB you can group repos into Projects but this does not affect the referential naming and all repos live in the ‘root’. This actually caused us issues when initially moving to BB previously.
I guess the repositories in Kallithea are case sensitive. Are they not in Bitbucket?
In BB all repos get created and presented in lower-case but you can reference a repo via https/ssh as any case mix and it will still find it. Your local clones end up with the case-mixed name, however. For example:
$ hg clone bb://Some-Repo
will find the repo called ‘some-repo' on BB and create a local repo called 'Some-Repo’.
Comment by Thomas De Schampheleire, on 2020-01-22 20:20
Thanks for the feedback!
Comment by Mads Kiilerich, on 2020-01-22 20:21
Kallithea make some efforts to avoid repos that only differ in casing.
I think that case ignoring repo access only depends on whether the database and the indices are case folding. I am not sure if it is a bug or a feature if it silently allow “sloppyness”. But if I remember correctly, it is tricky to make it performant and efficient across all databases.