marcinkuzminski

This answer has soo much value in it, thanks for sharing this.

Here at RhodeCode we strongly believe in self-hosting, this is why we started as an on-premise product for source code management.

You should check out RhodeCode too for self-hosting your own code, with extra security features to make sure it's well protected

Have you looked at the rhodecode.com for svn/git?

We'll work on improving this! Thanks for the feedback, this needs more of our attention then :)

Can you give an example of that markdown rendering?

I think it's almost in pair on how Github renders markdown.

On a side note on this. I think Unity had their own fork of Kallithea with some changes that aren't in the official version ? Or those features are backported later from the Unity release

at RhodeCode we used to have a hosted Mercurial repositories service. Actually, it was a per-customer isolated instance that we hosted on digital ocean. We have all the logic and code still here, i wonder if we should bring that back to have people host their Mercurial repositories.

The multi-repository code review is an interesting concept. Here at RhodeCode we're actually working on such solution to implement. This is in first to solve our internal problem of release code-review spanning usually two projects at once.

This is a hard and complex problem. Especially how to make code-review not too messy if you target 5-8 repos at once.

In RhodeCode we have a similar concept that we call diff ranges. It's not available in pull-request view directly, however, users can see this on a source repo if they select a range from changelog view.

example: https://code.rhodecode.com/rhodecode-enterprise-ce/changeset...

I agree with the concept and it's sometimes very important to see how each commit produced the final combined diff.

Thanks, we'll discuss this and follow up!

This is exciting!

Thanks for your answer. Our product is actually also open-core. And the source is here: https://code.rhodecode.com/rhodecode-enterprise-ce

In this case, what's the best process to start, should we open an issue, or send support email?

Cheers

How is the process for that? I'd like to get that integrated into RhodeCode as well.

RhodeCode is open-source too and unfortunately looks like Kallithea is a dead project by now. It didn't have a feature release since 2015, only a few bugfixes.

Have you looked at RhodeCode ? It's very similar like Gitlab with free Community Edition version that is also open-sourced. It's dedicated for self-hosting.

Use Mercurial histedit extension, this is a game changer on all operations. Works like git rebase -i but just better combined with phases. So most likely your not-yet-pushed commits are marked as draft, so you can run hg histedit.

We use this ALIAS:

histamend = !$HG histedit $(hg log -l1 -r '(draft() or secret()) and branch(.)' --template={rev})

This shows you option to drop/squash re-order/edit messages on all draft or secret commits in the current checkout branch

For a self-hosted option please check out RhodeCode has the first-class support of Mercurial, including largefiles, evolve, phases etc.

You might want to check RhodeCode at some point. Because our main customers are in Healthcare/Insurance/Automotive, and all those industries require strong auditability. We built very advanced audi logs capabilities, every permissions change, every comment, is traced with IP user and old data is saved.

I don't agree with the author here. Over the years i read about using VCS to store underlying data, so it's all shared, and you keep the data. Reality is that building a complex source code management platform is not easy. Storing things inside GIT repo and not database would be a huge performance issue when we're talking about scaling such system. If you have 1 repo yeah, it's doable and easy, but if you're talking 100 000 projects that's another story.

This problem keeps returning onto HN again, and again. I think this simply wouldn't work for mentioned reason, and few others that come to my mind.

And i know a bit about building a source code management platform because I built RhodeCode.

I created RhodeCode, and know for sure Kallithea does not support SVN.

- RhodeCode is based on newer and more modern than turgobears2 framework, called Pyramid.

- RhodeCode had 20 releases since 2017, Kallithea had two.

- RhodeCode fixed many security issues that Kallithea didn't, not to mention dozen of features that RhodeCode has but Kallithea doesn't, e.g pull requests updates, integrations framework

How is that a better activity and release?

https://code.rhodecode.com also, hosting RhodeCode sources.

The list doesn't mention it, but i'd also put https://rhodecode.com/features into there.

You should check out RhodeCode as well. It integrates with Redmine/Jira/Jenkins/TeamCity etc quite well, and it's suited to work for teams of 100-1000+ with enterprise feature focus

There are plenty alternatives to use. Eg: https://www.reddit.com/r/technology/comments/8ofqf6/gitlab_i...

Kallithea doesn't support SVN, only RhodeCode does which Kallithea forked. SVN support amongst many other security fixes and features were added at a later stage into RhodeCode.

I think the bigger picture here is code hosting. You cannot fork that, and TBH the value of moving from Github to gitlab.com is hosting alternative which is not really open-source.

I'd say Github, Atlassian (Bitbucket server), RhodeCode, Perforce (after acquisition of Deveo)

You might want to look at RhodeCode then, it supports now git,mercurial and subversion via it's vcsserver. Adding more in the future shouldn't be a problem because of all the abstraction in place.

RhodeCode is one of projects that build their installer on top of nix package manager. Check out this blog post: https://rhodecode.com/blog/61/rhodecode-and-nix-package-mana...

I wonder if solution to `PR commentary is lost.` would be simply to dump all the information created during code-review into some metadata in the commit itself. We also have this problem at RhodeCode that basically code-review in pull request puts lots of valuable information into the code review tool rather then the source code itself.

Interesting idea to try out for us

That's where Mercurial phases and publishing repositories improve UX a lot. Developers can have their forks with non-publishing repositories that indicate commits that are not in public state and can be easily edited. This is such a great concept.