GitLab 6.3 released: open-source software to collaborate on code(blog.gitlab.org) |
GitLab 6.3 released: open-source software to collaborate on code(blog.gitlab.org) |
3.0 release (Oct. 2012): https://news.ycombinator.com/item?id=4687455
4.0 release (Dec. 2012): https://news.ycombinator.com/item?id=4959417
5.0 release (Mar. 2013): https://news.ycombinator.com/item?id=5422950
6.0 release (Aug. 2013): https://news.ycombinator.com/item?id=6270446
For those who already use it, this is a good time to upgrade, because multiple security vulnerabilities were recently fixed [1]. (You can upgrade to a patch version within the same major/minor release, e.g. 6.2.3 to 6.2.4, but it's not too much more effort to just upgrade to the latest 6.3 release).
[1] http://blog.gitlab.org/multiple-critical-vulnerabilities-in-...
"Digital Ocean 1-Click Application Install Have a new server up in 55 seconds. Digital Ocean uses SSD disks which is great for an IO intensive app as GitLab. Look for GitLab under 'Select Image' => 'Applications' when creating a droplet."
GitLab, on the other hand, has two advantages over Stash. Firstly it's open source (+free). Secondly and most importantly, GitLab is under active development and there is a new release with reasonable amount of content every month.
I haven't installed Stash, but for what it's worth GitLab installation and upgrades have been really straightforward.
At the current state, Stash is better than GitLab
GitLab, on the other hand, has two advantages over Stash ... GitLab is under active development and there is a new release with reasonable amount of content every month.
Stash 2.9 was just released [1] about seven weeks after Stash 2.8 [2] about seven weeks after Stash 2.7 [3].
[1] https://confluence.atlassian.com/display/STASH/Stash+2.9+rel...
[2] https://confluence.atlassian.com/display/STASH/Stash+2.8+rel...
[3] https://confluence.atlassian.com/display/STASH/Stash+2.7+rel...
Stash seem to have a larger team behind it, with more features, documentation and snappier responses, but GitLab is promising too. I hope they all can be profitable and keep up the speed of improvements in all of the products.
Few pain points about Gitlab, large diffs cannot be merged or diffed through a merge request which is our preferred way to merge branches since you can autoclose the branches from there and provide the per line comments on the diff. The diff display currently has no option to hide whitespace (though they are open to pull requests that implement the `?w=1` convention github does.
Other than that thought I can't say I've had a negative experience with Gitlab.
One of the reasons that we chose Gitlab is because it's open source. We've made some tweaks to it so that it better fits our needs.
1) It's a resource hog. Big time.
2) It's incredibly hard to set up. The installation instructions and the development instructions are essentially the same. Key point, an end user should never have to `bundle install`, ever.
looks like its quite feature rich - federation, verdict integration, plugins, active directory integration, etc and doesn't look like a github clone.
I had the similar "omg, it just works" experience.
http://www.reddit.com/r/programming/comments/1rbgpr/gitlab_6...
We enjoy using it, but to new users I would recommend looking into gitbucket
https://github.com/takezoe/gitbucket
written in scala and no install necessary!
Oh... it's made in ruby.
https://github.com/gitlabhq/gitlabhq/tree/master/app/control...
self comment: this post isn't gonna end well :P
(Late) Edit: any problems I've ever had with upgrades have been related to not properly adjusting settings when moving new config files around. For example, in upgrading to 6.3 I failed to copy over my custom listen lines in unicorn for a non-standard port.
IMHO GitLab is easy to set up compared to something like Postfix. Making a GitLab server do what it's supposed to do is straightforward. You just follow all the steps. Making Postfix work as a proper mail server is kinda a mess.
[1]: https://github.com/phunehehe/chef-cookbooks/tree/master/gitl...
Heh, I feel exactly the opposite.
It could (and should) be more streamlined, I admit, but using diff et al. on the two affected configuration files makes the process fast. One could do it by hand w/o issues, but I wouldn't like it.