Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gitlab 9.0

about.gitlab.com

Post reply on HN
Print view View original

121–130 of 164 posts

Re: Gitlab 9.0

#121

Post by sytse »

jbk wrote: post #107
sytse wrote: post #98

Earlier quoted context omitted.

Thanks for using GitLab. We have open sourced features based on your request before https://news.ycombinator.com/item?id=10931690 I can't promise anything regarding these features. Especially custom fields are a typical EE feature in our perspective. The dependent issues feature proposal https://gitlab.com/gitlab-org/gitlab-ce/issues/4058#note_249... is still on the CE tracker but I'm not sure what it's future is.

Don't take me badly, Gitlab is the best thing around. We've tested many solutions... (too many) It's just that I really want to quit using trac, who is slow and not integrated with the rest of the infrastructure.

No worries, we love you too! Our Product Manager Victor Wu will email you to learn more.

Re: Gitlab 9.0

#122

Post by gooeyblob »

sytse wrote: post #6
ploggingdev wrote: post #3

The performance improvements are very noticeable : general page load times, pushing code to gitlab is as fast as github now and the commit messages load insanely fast, compared to a few months ago where loading commit messages in the UI used to take at least a couple of seconds. I don't follow gitlab development too closely, but they seem to have focused a lot on improving cache performance. But one change that I did…

Great to hear you notice the performance improvements. We're very happy with the improvements but we still have long way to go. We want the 99% latency under 1s and right now it is 2s: https://drive.google.com/file/d/0BzQDcBnEfNRZSTZYVXlyc1FGdEk... There are some controller timings that are red https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZZV... And the git access timings are a sea of red https://drive.go…

Looks like those last two screenshots are Grafana - do you mind sharing the dashboard JSON for those views? Very cool!

Re: Gitlab 9.0

#123

Post by newsat13 »

mydigitalself wrote: post #114
jbk wrote: post #93

We've been using gitlab for most VideoLAN projects, and are moving towards it for all of them (including vlc and x264). A lot of things are great, and going in the right direction, but the issues tracker is really lacking. The lack of custom fields, that you find in all other bugtrackers except github, and the lack of dependent issues are really blocking us to move full to gitlab. And the biggest issue is that they'r…

> non-open-source version, which we cannot use... is it a function of cost, or otherwise?

AFAIK, the EE code is also open source. So this is somehow a function of cost.

The massively insanely popular VLC project somehow has no money to pay for it's version control? How did it come down to this?

Re: Gitlab 9.0

#124

Post by jamesmiller5 »

sytse wrote: post #97
jamesmiller5 wrote: post #90

Earlier quoted context omitted.

Taking a look at Gitaly & the conversations around it, I don't see much in the way of consensus. Are you using Redis for the distributed lock or is this still a centralized system? My query being you can effectively use the native pre-receive hooks & wrap the git shell to allow consensus without needing to replace git with an RPC system like Gitaly.

Gitaly is still a centralized system. It shards the git repositories over multiple git servers in one datacenter. We looked into Git Ketch https://www.infoq.com/news/2016/02/google-kick-starts-git-ke... for a distributed system based on hooks. But this requires a sync per repository (very slow with 100k+ repos per server) and it is no longer actively being worked on by Google.

Thanks for the reply.

There are plenty of off-the-shelf consensus algorithms/services you could use in the git-hooks that don't have the git-ketch limitation. Zookeeper, etcd, consule, redis, etc. It really just matters your criteria and requirements, they all of trade-offs but I'm sure one fits.

To be frank I think your time is better spent looking into why one of these consensus packages isn't the right call for your needs. Since they could easily plug into the git-hooks & git-shell commands, it could avoid a massive investment of time from your team and you.

Re: Gitlab 9.0

#125

Post by allover »

buxtehude wrote: post #118
victorwu wrote: post #9

Earlier quoted context omitted.

The ongoing discussion regarding the sidebar/navigation is here: https://gitlab.com/gitlab-org/gitlab-ce/issues/29835 . Thanks again for the feedback.

What's sad is that this isn't the first time GitLab UX/UI peeps have tried to remove the sidebar. 9 months ago we went through a very similar version of this: https://gitlab.com/gitlab-org/gitlab-ce/issues/18542 Can we just all agree to keep the damn sidebar available - if UX wants to remove it, fine, as long as users have the ability to easily permanently pin it back open if they wish to do so. By now GitLab UX shou…

Perhaps the 'sad'/'damn sidebar'/'should realize' passive-aggressive entitlement doesn't help?

Re: Gitlab 9.0

#126

Post by jamesmiller5 »

eclark wrote: post #106
sytse wrote: post #97

Earlier quoted context omitted.

Gitaly is still a centralized system. It shards the git repositories over multiple git servers in one datacenter. We looked into Git Ketch https://www.infoq.com/news/2016/02/google-kick-starts-git-ke... for a distributed system based on hooks. But this requires a sync per repository (very slow with 100k+ repos per server) and it is no longer actively being worked on by Google.

Next time you think about distributing git, you should take a look at the combination of jgit and a distributed key value store. A little while ago I spent a night and I was able to get a fully distributed git http server up and running. I used HBase and was able to get it most things working. That allows the only contention to be around refs. Everything else is well distributed and spread across as many machines as…

> That allows the only contention to be around refs.

This is solved without modifying the git client using a distributed/shared lock wrapping the git-shell & git-hooks (pre-receive) . If you were to modify the git server behavior to say use epaxos, one could provide even better latency guaranties https://www.cs.cmu.edu/~dga/papers/epaxos-sosp2013.pdf .

I'm not sure about the GC operation though, did you use the DfsGarbageCollector that is part of Jgit? I thought that was provided as part of the DFS interface.

http://download.eclipse.org/jgit/docs/jgit-2.0.0.20120613090...

Re: Gitlab 9.0

#127

Post by machbio »

sytse wrote: post #80
machbio wrote: post #78

how is the CD in Gitlab complete without this issue being complete ( https://gitlab.com/gitlab-org/gitlab-ce/issues/28497 ) - is there any alternative if i want to use "gitlab.com" for hosting my code ?

Most of CD including deployments already works for private projects, it is only the auto deploy https://docs.gitlab.com/ee/ci/autodeploy/index.html that doesn't work yet. We would all like to see auto deploy working with private projects and it is scheduled for 9.1 If you don't want to use GitLab.com to host your code you can install GitLab yourself or use the mirroring function in GitLab to deploy code hosted elsewh…

will just wait for "Gitlab.com" to get the functionality - is there any lag between Gitlab version upgrade and "Gitlab.com" using the upgraded Gitlab version ?

Will wait it out for Gitlab 9.1 :) Thank you for the amazing work.

Re: Gitlab 9.0

#128

Post by FridgeSeal »

AsyncAwait wrote: post #110
recursive wrote: post #86

Earlier quoted context omitted.

What's a similar editor that's faster? VS Code?

Yes.

VSCode faster than Sublime? Are you sure of that?

VSCode is certainly nice and fast, but I've been able to do choke vscode a lot faster than Sublime.

Plus, you can't even open files above what, 100(?)mb in vscode whereas Sublime happily opens that in a snap.

Re: Gitlab 9.0

#130

Post by AsyncAwait »

FridgeSeal wrote: post #128
AsyncAwait wrote: post #110

Earlier quoted context omitted.

Yes.

VSCode faster than Sublime? Are you sure of that? VSCode is certainly nice and fast, but I've been able to do choke vscode a lot faster than Sublime. Plus, you can't even open files above what, 100(?)mb in vscode whereas Sublime happily opens that in a snap.

No, I meant that VS Code, (which is similar to Atom in both features, technology used and price), is (much) faster than Atom, (Electron vs Electron), it is obviously not faster than Sublime, (Electron vs Native).

I understood the OP's question as what is similar to Atom, but faster, is it VS Code?

Post reply on HN