4 ms·
What's you best KILN feature ? I wonder if we can adopt it at RhodeCode
by marcinkuzminski 10y ago
What's you best KILN feature ?
I wonder if we can adopt it at RhodeCode
- shoover 10y agoHmm. 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 agoThanks 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 agoKILN and Fogbugz have a nice integration.
- johnjuuljensen 10y agoKilns 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 agoTrue. 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 agoWhat'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.