News for hackers. Stuff that matters.
Re:Mercurial 4.0 Sprint Notes by marcinkuzminski on Tuesday October 18, 2016 @04:00PM (#12738117)
What's you best KILN feature ? I wonder if we can adopt it at RhodeCode
Re:Mercurial 4.0 Sprint Notes by shoover on Tuesday October 18, 2016 @04:33PM (#12738386)
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)

Re:Mercurial 4.0 Sprint Notes by marcinkuzminski on Tuesday October 18, 2016 @04:44PM (#12738501)
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.

Re:Mercurial 4.0 Sprint Notes by johnjuuljensen on Wednesday October 19, 2016 @12:56AM (#12741184)
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.

Re:Mercurial 4.0 Sprint Notes by gecko on Wednesday October 19, 2016 @01:07PM (#12745574)
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.

Re:Mercurial 4.0 Sprint Notes by shoover on Wednesday October 19, 2016 @10:20AM (#12743988)
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.
Re:Mercurial 4.0 Sprint Notes by PretzelFisch on Tuesday October 18, 2016 @07:51PM (#12739781)
KILN and Fogbugz have a nice integration.