Hacker News: marcinkuzminski

New comment by marcinkuzminski in "Gitlab features that are moving to open source"

marcinkuzminski — Wed, 01 Apr 2020 09:32:02 +0000

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

New comment by marcinkuzminski in "GitHub shuts off access to Aurelia repository, citing trade sanctions"

marcinkuzminski — Fri, 20 Mar 2020 08:32:05 +0000

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

New comment by marcinkuzminski in "GitHub: Increased Error Rates"

marcinkuzminski — Thu, 20 Feb 2020 16:35:19 +0000

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

New comment by marcinkuzminski in "Show HN: OneDev – A Lightweight GitLab Alternative"

marcinkuzminski — Mon, 20 Jan 2020 10:20:05 +0000

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

New comment by marcinkuzminski in "Show HN: OneDev – A Lightweight GitLab Alternative"

marcinkuzminski — Sun, 19 Jan 2020 22:43:37 +0000

Can you give an example of that markdown rendering?

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

New comment by marcinkuzminski in "Sunsetting Mercurial Support in Bitbucket"

marcinkuzminski — Tue, 20 Aug 2019 14:47:28 +0000

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

New comment by marcinkuzminski in "Sunsetting Mercurial Support in Bitbucket"

marcinkuzminski — Tue, 20 Aug 2019 12:38:05 +0000

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.

New comment by marcinkuzminski in "Monorepos: Please don’t"

marcinkuzminski — Thu, 03 Jan 2019 15:08:54 +0000

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.

New comment by marcinkuzminski in "Stacked Diffs versus Pull Requests"

marcinkuzminski — Thu, 04 Oct 2018 15:22:32 +0000

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.

New comment by marcinkuzminski in "Sourcegraph is now open source"

marcinkuzminski — Wed, 03 Oct 2018 07:43:23 +0000

Thanks, we'll discuss this and follow up!

This is exciting!

New comment by marcinkuzminski in "Sourcegraph is now open source"

marcinkuzminski — Tue, 02 Oct 2018 20:11:28 +0000

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

New comment by marcinkuzminski in "Sourcegraph is now open source"

marcinkuzminski — Tue, 02 Oct 2018 19:52:02 +0000

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

New comment by marcinkuzminski in "Adding Mercurial support to Gitlab"

marcinkuzminski — Fri, 21 Sep 2018 07:12:35 +0000

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.

New comment by marcinkuzminski in "Adding Mercurial support to Gitlab"

marcinkuzminski — Thu, 20 Sep 2018 19:11:36 +0000

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.

New comment by marcinkuzminski in "Adding Mercurial support to Gitlab"

marcinkuzminski — Thu, 20 Sep 2018 08:48:08 +0000

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

New comment by marcinkuzminski in "Adding Mercurial support to Gitlab"

marcinkuzminski — Thu, 20 Sep 2018 05:03:30 +0000

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

Gitlab Gitaly v1.0

marcinkuzminski — Thu, 13 Sep 2018 06:19:03 +0000

Article URL: https://about.gitlab.com/2018/09/12/the-road-to-gitaly-1-0/

Comments URL: https://news.ycombinator.com/item?id=17976441

Points: 2

# Comments: 0

New comment by marcinkuzminski in "GitLab 11 released"

marcinkuzminski — Sat, 23 Jun 2018 11:23:30 +0000

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.

New comment by marcinkuzminski in "The single most important criteria when replacing GitHub"

marcinkuzminski — Wed, 06 Jun 2018 20:33:35 +0000

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.

New comment by marcinkuzminski in "Microsoft Is Said to Have Agreed to Acquire GitHub"

marcinkuzminski — Wed, 06 Jun 2018 14:50:19 +0000

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?