GitLab CEO here, we're very excited that we just enabled free use of git-annex on GitLab.com. We think it is the best solution to version control large files when Dropbox doesn't cut it anymore. What do other people use for large file versioning?
We haven't found a solution as we have given ourselves requirements to store revisions of large binary files (PSDs), but we don't have the ability to effectively manage 8GB repos (and I don't know whether anyone does.)
It seems like ultimately, versioning software will need to grow to understand more file types than text in order to keep track of changes to many large files. I imagine Git plugins available by filetype and perhaps automatically sourced by Gitlab when needed, but I know that would be an enormous task.
Unrelated: can you possibly work with Atlassian to get Gitlab integration for SourceTree? It would be very convenient for us. :)
Versioning large files is hard. The way to do it is not to put them in the git repository itself but to manage symlinks to the SHA-1 of the large file in git. This way your git repo stays under 1GB but you can request the file from a server. GitLab EE uses the open source Git Annex for this but adds code to check your project permissions. All you need to do to get the files is a git clone and 'git annex sync --content'. Read more about this on https://about.gitlab.com/2015/02/17/gitlab-annex-solves-the-... Please let me know if you have any other questions.
We would love to see better support for GitLab in SourceTree and so would many others https://answers.atlassian.com/questions/47020/comments/26160... The response from Atlassian in that thread indicates they are less inclined to do it. Since GitLab is an open source alternative for their Stash+JIRA+Confluence+Bamboo products I understand their stance on this. Of course it never hurts to ask in that thread.
... actually, versioning large files is easy, but not directly in git.
https://github.com/bup/bup strategically breaks files to chunks of ~8k length, in a way that makes small changes to a big file become a small change to a small number of chunks (ideally, changing one byte in a 80GB file would change exactly one such 8KB chunk -- and that is often the case, though it's common than 3 or 4 would change).
bup then puts[0] the chunks into git, together with a "reconstruction map". As a result, you can efficiently put huge files in git and only pay for the real deltas in storage.
[0] It doesn't actually use git or libgit - it writes git packs directly.
I agree git-annex is the best solution for now - I just wish some effort would go into versioning binary files by creating projects that mimic the behavior of the programs that generate them in some way.
Probably the closest thing to what I am optimistically hoping to see someday is how developers save DB migration files instead of versioning copies of the database tables, and then run the migrations as part of the merge process to sync the databases.
Thinking about it more, it seems like a general project to create 'migration' specifications to generate binary files would be more appropriate than a project to modify version control.
I agree that it would be nice to have more files being created algorithmically instead of being binary. You can diff an svg image but you can't diff a jpeg. Although the svg diff could be presented better than how we currently do it.
And you're welcome, more than 700 contributors made GitLab what it is today.
Binary files (large or not) generally can't be merged, and thus working with them in a version control system effectively requires support for exclusive locking. Is this supported (I don't think it is) and/or in the radar?
Hi Panzerboy. We understand the desire to have this in CE but this is one of the few features that is requested by a lot of large organizations and not many small ones. Of course we understand that smaller organizations and individuals like you would like it too. But there has to be extra value in GitLab Enterprise Edition (EE). We have to make hard decisions about what is EE only and we currently have no plans to port this to CE. As a workaround you can setup a separate git-annex server. It will be more work to setup, add the remotes, and you don't have the access control that the GitLab integration brings. But if you're a single user you might be able to live without the access control.
Of course, if it's an option for you consider using GitLab.com, it offers unlimited repositories and collaborators. Right now we don't limit the amount of annex data but we might in the future.
Unfortunately that's not an option for our (small) company. I'm already using gitlab.com for my own personal stuff, but for the company's, we have to stay on-premise.
Our pricing takes into account that not everyone is a developer, we have one price per user to keep it simple. Assuming you have 5 non-dev's the cost for GitLab EE would be less than 4 dollars per user per month or less than 7 dollars per developer per month.
GitLab CTO here. You can easily update your GitLab at Digital Ocean because it uses omnibus package. We recommend updating GitLab for performance updates, security updates and new features. Please use this guide for update https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc...
I have migrated yesterday from 7.3 to 7.8 and all went smoothly, I really appreciate the migration guide and especially the "what to do if things go south" which is always my biggest concern.
My only little problem is that now the list of merge request display the assignee instead of the creator. It does not really make sense to me as there's already the filter "assigned to me". It breaks a little my workflow because I do code reviewing for a dozen of person across several project, and when they tell me on skype "pushed" , now i need to ask them "errrr which MR number?"
Glad to hear your upgrade went OK. I made the change to show the assignee. We think it is more important to show what has to be done than to show what has been done. But I agree that for your use case it might be a small step back. What about filtering the MR's by author as you can do on https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests ?
I understand the logic, but however it does not stand to the fact that on the homepage when I click on MR I already see a filtered version of "only those assigned to me" , which in that case make the display of the assignee redundant, and I hardly specifically go on the project page then on MR.
EDIT: I would have nothing against a middle ground of displaying both.
It makes sense that if you go to https://gitlab.com/dashboard/merge_requests?assignee_id=1 it shows the author instead of the assignee. Same for other places where you filter on assignee. Feel free to create a merge request for this. We can't display both since it will look messy.
yes your solution of displaying author when assignee is already filtered.
I don't know ruby at all, but I guess I can try, as you're the one who made the change to put assignee instead of author, I would not be against some guidance on where to look for the modification :)
thank you, I'm a bit confused by the code (the fact I know nothing about ruby, let alone rails, without talking about haml may be part of it)
in my naive understanding, in order to implement the feature as you said, it would require from the controller to send to the view a variable "isFilteredByAssignee"
How can one find the corresponding controller, I've tried grepping for _merge_request.html.haml or just _merge_request without finding anything.
I guess the index.html.haml in the folder do something magic to render the list of merge_request with the @merge_requests ?
I just discussed this with some other team-members. The consensus is that changing what information is displayed is confusing. We don't have a lot of space to work but but we can add 'by' and an avatar. So go from:
#337 assigned to Sytse Sijbrandij
=>
#337 by AVATAR assigned to AVATAR Sytse Sijbrandij
When you hover over the avatar it should show the name of the author in a tooltip.
I dont quite understand the GitLab model.And why GitLab.com is free.
Shouldn't GitLab.com cost something, and its revenue will be used to support the hosting as well as building a sustainable business model? The idea is for those who want to own their data or the fear of vendor lock in they could use the Community version.
The current offering looks like those Free Webhosting long time ago that offers unlimited bandwidth and webspace.
Thanks for asking ksec. GitLab has an open core model. The open source GitLab Community Edition has an MIT license. GitLab Enterprise Edition contains extra features and you have to get a subscription to use it. The most common subscription costs $50 per user per year. You can find more about the feature difference on https://about.gitlab.com/features/#compare
We think that repository hosting will be like email hosting. Most people will have an account for free with only forum support (similar to gmail and outlook.com). For the next few years we expect the on-premises subscriptions to bring in more than enough money to pay for hosting. Because code hosting is a central hub for many services we think that long term revenue model will be a marketplace for additional services.
If you don't distribute the product you don't have to share your contributions if I understand the AGPL correctly. Most users of GitLab use it internally and never distribute the code outside of the organization. If they do so they will share the source code anyway since almost all of it is written in interpreted languages like Ruby.
I've been using GitLab since version 5.0. When we decided to start using GitLab - it didn't have a lot of needed features and we found ways to live without them, but with time they added them and added more useful features which we enjoy and use daily. You're doing great work, guys!
I have been wanting to self-host GitLab for quite some time, but it doesn't support the workflow my team uses on Bitbucket.
We have a team and by default all the members of the team have read access to all the team repositories (unless overridden at a repo level) and write access to the repositories they created or forked. Developers can create forks within the team namespace and send pull requests between themselves and to the official "blessed" repo from which releases are done. Those with write access to some repositories can commit to those repos and also merge pull requests. Admin can basically do everything within the team namespace.
That said, congratulations on keeping GitLab rolling forward with more and more features and bugfixes every release.
Internally, you can create the /path/to/v3/ part using either a snapshot-capable filesystem with periodic snaps (in which case v3 might become a datetime string in yyyymmdd type format) or a script that creates incrementing version numbers of symlinks to the same when filesystem contents change -- using inotify() or similar.
I can't sing the praises of Gitlab loud enough - we (Infoxchange) started using Gitlab and Gitlab-CI around 8 months ago or so and haven't thought twice about our decision.
It's a really solid project using great technology that's easy to support and use!
It's great to have a community of people using and building GitLab, that contributes new features, critizes decisions and helps everyone else stay sharp.
GitLab Developer here, have you tried GitLab CI https://about.gitlab.com/gitlab-ci/? It's not as feature packed as some of the SaaS providers' offerings, but it does the job, runs on your own server, is fully integrated with GitLab.
Thanks Douwe. If people want a CI Saas they can also use Magnum CI that supports GitLab or ci.gitlab.com. The latter is completely free, even for private projects, as long as you bring your own runner to execute the tests.
We use Strider for CI with Gitlab and it's been excellent. Self-hosting is a priority for our code for many reasons. StriderCD documentation is still lacking a bit but it reminds me of a young Gitlab. More and more CI providers are supporting Gitlab since the API is so close to Github so make sure to ask!
Gitlab also offers CI but we are a Node shop so I stuck with what I could modify best. That being said I've been able to modify and contribute to Gitlab easily over the years.
Great job Gitlab team! I'm so glad to see the remote team and open model succeed so well.
Thanks for contributing to GitLab doublerebel! Strider CI looks nice. Just wanted people to know there is a GitLab runner for Node https://www.npmjs.com/package/gcr
We are very heavy users of Gitlab-CI and have integrated it into a Docker build environments which has worked really well for us. A project to keep an eye on is DockCI - https://github.com/RickyCook/DockCI
Glad to hear that. Interesting to read about DockCI. What do you or others think about using Apache Mesos for spinning up Docker containers with GitLab Runners?
At this point, no. GitLab runs very well on Unix machines and is easy to install. It is literally three commands and doesn't require some arcane unix magic to setup and keep running.
Starting a VM is easier than ever nowadays and installing GitLab no harder.
I'm so comfortable saying this, that if you have any problems getting it setup, email me at job [at] gitlab dot com and I'll help you get rolling.
As an addendum to that, I was able to get a basic Gitlab up and running with Docker in a very short order on Windows. Might be worth recommending: https://github.com/sameersbn/docker-gitlab
