3 ms·

That was a busy meeting and the developer mailing list is very busy. It's great to see continued investment from so many interested parties. Judging by the not

by shoover 10y ago

That was a busy meeting and the developer mailing list is very busy. It's great to see continued investment from so many interested parties. Judging by the notes in the wiki [1], however, the purveyors of my preferred server, Kiln, are not so engaged lately: > Available hosting solutions: Bitbucket, Kallithea (self-hosted), Kiln (still exists?) I believe it is maintained and even if not maintained would continue to work for ages, but I suspect we will be held to 3.x for a while. [1]: https://www.mercurial-scm.org/wiki/4.0sprint https://www.mercurial-scm.org/wiki/4.0sprint

marcinkuzminski 10y ago
What's you best KILN feature ? I wonder if we can adopt it at RhodeCode
- shoover 10y ago
  Hmm. I haven't looked at RhodeCode. For me Kiln has provided a good UI and workflow and just worked ever since their v2.4 or so. I'm not sure there is a particular best feature, but roughly these features are what come to mind: - Code review UI including comment pane with one level of sub-threading and easy click and drag linking to lines of code, small changeset selection pane, and large scrolling code pane are simple and work well. By contrast, I'm less sure about github and bitbucket pull requests UI. - largefiles - Single sign-on and linking with FogBugz (if we reference a FogBugz case in a commit message, then the commits show up in the case notes)
  - marcinkuzminski 10y ago
    Thanks for sharing, actually those two first ones was our main focus from beginning. We worked back in the days with Unity which was using kiln to make the code-review workflows similar. If you miss kiln, you should check RhodeCode out, and our community edition is even open-sourced.
- PretzelFisch 10y ago
  KILN and Fogbugz have a nice integration.
- johnjuuljensen 10y ago
  Kilns biggest omission, which is what made me choose Bitbucket, is the lack of branch pull requests. Kilns commit-based PRs are useless in a feature branch workflow. Bitbuckets code review implementation doesn't handle big changes gracefully though, so I primarily inspect the changes in Beyond Compare.
  - shoover 10y ago
    True. As a workaround you can bridge your feature branch workflow to Kiln reviews by using the kiln extension locally with the push command to attach the changesets to a review, as in: hg push --review -r [REV|BOOKMARK|BRANCH] Theoretically. The extension seems to be broken with respect to hg 3.8 and with the Kiln API itself.
  - gecko 10y ago
    What's hilarious/sad to me is that Kiln started out (as the prototype that won Django Dash) doing only pull requests. That was literally all it did. Pushing directly to a repo would instead, behind-the-scenes, make a branch repo and put your commits there. When you accepted the review, it'd automatically get merged. Kiln would even warn you if you could safely do the merge without conflicts. This was all back in 2008, and I believe predated GitHub launching entirely, but certainly predated PRs being common. Hilariously, we concluded internally that doing things that way was too complicated/weird for people to use, while GitHub concluded the exact opposite, and the rest is what you see.
ngoldbaum 10y ago
Mercurial doesn't use semantic versioning. If tooling that depends on mercurial breaks in a mercurial update, this is often considered a mercurial regression, so long as the tooling isn't using mercurial's internal APIs which have no backward compatibility guarantees. I do know that the person primarily behind kiln harmony left a while ago and now works at Khan Academy.
neandrake 10y ago
Phabricator also supports hosting mercurial but there are some rough edges. Its need to do some basic monitoring of the wire protocol (primarily to determine whether actions are read/write for ACL and cluster resolving) have uncovered that interpreting the underlying wire protocol is difficult and challenging [0]. I wonder if Kiln or others have similar issues? I would guess that this sort of problem is one of the reasons hosted tooling around hg falls behind git even though touting a great extension API (aside from the large gap in user base). [0] https://secure.phabricator.com/T9548 https://secure.phabricator.com/T9548

by shoover 10y ago

marcinkuzminski 10y ago

What's you best KILN feature ? I wonder if we can adopt it at RhodeCode

shoover 10y ago
Hmm. I haven't looked at RhodeCode. For me Kiln has provided a good UI and workflow and just worked ever since their v2.4 or so. I'm not sure there is a particular best feature, but roughly these features are what come to mind: - Code review UI including comment pane with one level of sub-threading and easy click and drag linking to lines of code, small changeset selection pane, and large scrolling code pane are simple and work well. By contrast, I'm less sure about github and bitbucket pull requests UI. - largefiles - Single sign-on and linking with FogBugz (if we reference a FogBugz case in a commit message, then the commits show up in the case notes)
- marcinkuzminski 10y ago
  Thanks for sharing, actually those two first ones was our main focus from beginning. We worked back in the days with Unity which was using kiln to make the code-review workflows similar. If you miss kiln, you should check RhodeCode out, and our community edition is even open-sourced.
PretzelFisch 10y ago
KILN and Fogbugz have a nice integration.
johnjuuljensen 10y ago
Kilns biggest omission, which is what made me choose Bitbucket, is the lack of branch pull requests. Kilns commit-based PRs are useless in a feature branch workflow. Bitbuckets code review implementation doesn't handle big changes gracefully though, so I primarily inspect the changes in Beyond Compare.
- shoover 10y ago
  True. As a workaround you can bridge your feature branch workflow to Kiln reviews by using the kiln extension locally with the push command to attach the changesets to a review, as in: hg push --review -r [REV|BOOKMARK|BRANCH] Theoretically. The extension seems to be broken with respect to hg 3.8 and with the Kiln API itself.
- gecko 10y ago
  What's hilarious/sad to me is that Kiln started out (as the prototype that won Django Dash) doing only pull requests. That was literally all it did. Pushing directly to a repo would instead, behind-the-scenes, make a branch repo and put your commits there. When you accepted the review, it'd automatically get merged. Kiln would even warn you if you could safely do the merge without conflicts. This was all back in 2008, and I believe predated GitHub launching entirely, but certainly predated PRs being common. Hilariously, we concluded internally that doing things that way was too complicated/weird for people to use, while GitHub concluded the exact opposite, and the rest is what you see.

ngoldbaum 10y ago

Mercurial doesn't use semantic versioning. If tooling that depends on mercurial breaks in a mercurial update, this is often considered a mercurial regression, so long as the tooling isn't using mercurial's internal APIs which have no backward compatibility guarantees. I do know that the person primarily behind kiln harmony left a while ago and now works at Khan Academy.

neandrake 10y ago

Phabricator also supports hosting mercurial but there are some rough edges. Its need to do some basic monitoring of the wire protocol (primarily to determine whether actions are read/write for ACL and cluster resolving) have uncovered that interpreting the underlying wire protocol is difficult and challenging [0]. I wonder if Kiln or others have similar issues? I would guess that this sort of problem is one of the reasons hosted tooling around hg falls behind git even though touting a great extension API (aside from the large gap in user base). [0] https://secure.phabricator.com/T9548 https://secure.phabricator.com/T9548