Question

Note: this issue has been completely resolved to my and my teams satisfaction. Thank you so much Kiln team!

---

Note: I did a major rewrite since it was getting long and fragmented

Here is a quote from one of the devs on my team:

Stupid fricking numbers. Prolly had something to do with checking into /8/ and publishing from /1/. Can we drop them or change them to something more meaningful? They seem hazardous.

In the 5 days sense we started using kiln among 5 developers, we have already have a bunch of problems with the way repo urls are formed. The key problem is that urls use the repository id instead of the name of the repository, even though both show up in the UI. Here is another quote from one of my team members:

I guess that's the thing, the use case they are optimizing for (moving things around in a UI I don't actually use) breaks a use case that I do care about (manually entering URLs into my tortoise client).

This gets at the root of the problem. All the talk about making sure that moving repos around doesn't break urls is not really a big deal for the users. If I move a file or a directory in windows, windows is smart enough to know that I meant to move it, if I didn't mean to, I can always move it back. Windows also know that I actually spend very little time moving stuff around.

Since the beginning of time (time didn't exist before source control), users have been doing 3 things: pulling changes, making new changes, and pushing changes. Kiln doesn't change that (and shouldn't try). I just want to do the job I love, and most of my user interaction with kiln is and will be from the command line or from tortoisehg. If I am going to be typing urls into either of those places, then the url should be easy to remember having something to do with the thing it points to, I should certainly not have to open my web browser to get a magic number.

I understand that since you make kiln, using kiln is a big part of your job, so you are going to move repos around a lot more than I am, but you also have to remember that 90% of the time users are going to use a program called mercurial to talk to kiln, and mercurial expects a url to get the conversation started. Kiln is first of all a mercurial hosting service and second a code review/management tool. I don't say this to denigrate it, because in order to be a good code review tool it has to get hosting right, because if we cannot have good urls, then no matter how good the review tool is 90% of our interaction with the product will still suck.

github, launchpad, bitbucket, hgweb, code.google.com, codeplex, sourceforge, and even just using ssh tunnelling all give me sane and usable urls, and I can't find any other hosting service that tries to magically be smarter than me with its urls.

Answer 1

(Logically a comment on Ben's answer, but too long to be posted as same.)

Ben, I hear what you are saying and there was a time (maybe even yesterday ;)) when I would have been inclined to agree with it. But... What are really the chances that you will rename repo 6 from Foo to Bar, then rename repo 9 from Quux to Foo, and then be upset that your link that used to point to 6 now points to 9? And, if you changed 6 from Foo to Bar, would you really be upset about needing to change the places where you have linked to it under the name Foo? Obviously there are merits to both approaches, but I'm leaning towards Stefan's view on this.

How would TortoiseHg respond if you 301'd Foo to Bar after the first part of that scenario?

(More difficult, but) Could TortoiseHg be extended to look for an X-Kiln-Repository-ID response header and bark if it ever gets a different one from the one it originally cloned from? If so, and if Kiln used named URLs but always served the repository ID in this header, it would solve the (edge?) case where 6 is renamed from Foo to Bar and then 9 is renamed from Quux to Foo, because anyone still fetching /Foo an expecting X-Kiln-Repository-ID: 6 would get X-Kiln-Repository-ID: 9 instead.

(Any argumentative tone in the above is not intended, just food for thought.)

Answer 2

Update: We've made this change, exactly as requested by our users:

Repository URLs are now guessable (Kiln/Repo/YourProject/YourGroup/YourRepo), and there's no more confusion about that one weird number and how it affects the rest of the URL.

The justification here is that we have quite often moved repositories within groups or even renamed them. It's something that can happen quite frequently, depending on your workflow.

If we take your suggestion, we either have to completely disallow all renaming/moving of repositories, or we have to be willing to break every repository that's cloned off of the one being renamed/moved.

I hear your frustration and will be discussing possible solutions with the team as soon as possible.

Answer 3

@admins: a small request. This question seems to be a fixed bug/feature request. Could it be possible to re-tag questions something like this:

http://meta.stackoverflow.com/questions/tagged/status-completed

You're keeping a close watch on this site, but for newbies like me it makes filtering and searching a bit faster. It could give a better 'view' on cases you've already closed.

Thanks!