Pretty sure this product is just so you can store your code/repo for your project using Google's cloud services. It's part of a whole for their cloud offering.
The code delivery pipeline consists of issues, IDE, code hosting, CI, code review, configuration management, Continuous Delivery (CD) and a PaaS service. Code hosting is a first step and getting all the rest right is a lot of work. Services working on getting the IDE right are Koding, Nitrous.io, Cloud9, CodeAnywhere, Codio and CodeEnvy. And I suspect that GitHub Atom is running in a web-browser so they can effortlessly offer it online in the future. For configuration management you want to integrate with Chef, Puppet, Ansible, Salt and Docker.
At GitLab we offer CI and CD via GitLab CI. We hope for a multi-cloud future where organizations will deploy to different cloud providers. They will use PaaS software that spans the different IaaS providers. Cloud independent PaaS software offerings are CloudFoundry, OpenStack, OpenShift, Kubernetes, Mesos DCOS, Docker Swarm and Flynn. We want to ensure that GitLab is the best option to do code collaboration upstream from these offerings.
Currently we're thinking about solving this problem, but in our opinion it is more than a simple deployment. You need a build pipeline.
We're thinking about adding a build pipeline configuration to .gitlab-ci.yml file. Right now we're looking into how to deal with dependencies that trigger a build and how to allow for multiple environments (staging, preprod, prod) to be deployed.
We think that solving the build pipeline properly (like GoCD and Concourse already have) in a simple to setup way will offer a lot of value. What do you think?
A note about atom ... It does not run in a web browser and it would be damn hard to port it to the web since it runs on Node. It uses chromium for displaying the DOM but is not in a browser.
This article is only slightly more sensible than claiming that S3 is a GitHub competitor because you can git clone over HTTP.
But for everything that I really care about, I still maintain private repos on my home server.
Sorry, you'll have to be more specific.
I often wonder if the projects my team works on ends up that way. We A/B test a lot of changes and often find that it makes absolutely no difference in conversion. In the end we often don't change things that seem to be "obvious" improvements for fear that we'll just frustrate our customers by changing things in ways they don't care about.
UI design is hard :-)
Github's issue tracker is also very half baked, every real project has to has a Trac instance or so somewhere else.
But _it has critical mass_, and pull requests and the way commenting them and testing them etc works is really awesome, and it'll be hard for a new competitor to get people to move.
Granted, there are a lot of warts and confusing navigation and organization, but in many ways this is a function of trying to serve so many disparate use cases. Certainly it could be a lot better, but it's far from easy—certainly not the type of thing you could just throw a UX designer at, but something where you need a UX visionary who also happens to be a developer with deep understanding and practice using git.
I agree with you that Issues is terrible though. I tried to use it for my team, but the show-stopper was that you can't move issues between repos, and so there is no way to stay organized across a non-monolith architecture where you need to take issues in based on front-facing products and not just code-level concerns. If it wasn't for that, we probably would have tried to suffer through it just for the integration benefits.
I have been thinking, though, that I don't like the workflow associated with commenting out of band. I would really prefer that people comment by making a branch and modifying my PR (either with code comments or just fixing the problems directly). If I knew how to do that efficiently, I probably would have almost no attachment left to GH.
This enabled people to add new functions that are tested as part of the codebase so that plugins don't break on upgrades.
Are there any plugins you would like to see?
BTW We're considering renaming 'Project Services' to 'Add-ons'. Do you think that makes things clearer?
Does Google have too many siloed product managers? Maybe you can only advance up the corporate ladder by releasing new products, and fuck all if they get killed later, because you got your promotion?
No clue what the cause. Just seems weird looking on from the sidelines.
About once a year for the last several years I have spent a few hours/days migrating stuff off of Google because the project is being shut down. Maybe they are just cleaning house from the mass of project in 2005-2010, but the constant reminder that the stuff I create is in danger if it lives on Google's servers is probably not the lesson they want to be teaching me.
A number of features are listed, 'Source Code Editor' seems to be the other big one, the rest might fall into the other cloud offerings.
... and since the cloud product actually offers a direct way for Google to generate revenue from the service, I'd assume it'd live for awhile. ;)
Displaimer: i'm the CTO of RhodeCode
It has it's own code review workflow which is, in my opinion, superior to Github's.
A nice summary:
In Bitbucket, we don't support this yet, but we do allow branch restrictions to ensure only trusted users are able to merge sensitive branches and many teams find this to be a suitable proxy for that behavior.
can you elaborate a bit more what you are looking for?
What kind of structure do you need?
Without these informations, I'll just throw gitlab in the possible alternatives pool.
Please note that I'm biased since I'm on the gitlab core team. :)
Or email me - scott <at> atlassian.
the only thing I've found missing is the ability to render images inline. If someone submits a documentation update with SVG and PNG updates, you have to download the changeset to see the files. It would be nice if an option for "view this attachment inline" were available without installing extensions.
I always found Crucible much nicer and it integrates w/ Stash decently, but I worry it and Fisheye are on the backburner at Atlassian.
(Atlassian CEO here)
* Fisheye has crazy advanced searching (in commit messages, users, etc)
* Fisheye offers he ability to watch for changes on files and directories that happen in any branch
* Fisheye shows a file as it might look with all branches and tags together (though it doesn't always combine them well of course as might be expected w/out using the VCS's conflict resolution)
* Crucible shows you what changed since you last reviewed and has an awesome slider (though can be a bit buggy)
* Crucible live-notifies updates in the browser on changes
* Crucible offers reviews on patches to a repo that may not be committed
* Crucible differentiates comments and defects
* Crucible lets me see unread vs read comments on files
* Crucible lets me see the number of comments (read and unread) on in the file-list pane on the left before going to the file
I personally think all 3 tools serve different purposes. I understand the want to move away from Crucible/Fisheye which are older and predate Git which causes some issues. IMO, there is a big unsatisfied market for code review tooling right now. There is also a market (probably not as big) for intelligent searching and notifications across a repo.
Re: stash. It's by far the best code review product I've used. And I've tried plenty!
In stash, I see the list of files on the left, and clicking on each file shows me the diffs. I also have the option to see the diff only (without the whole file).
Where I work we cannot use outside review tools, it has to be hosted internally. But I don't think we are your target audience in this case.
I figured that Reviewable wasn't the right tool for you / your company -- I was just looking for your opinion. Cheers!
For Google to launch something purely as a "Github competitor" would be silly because those using Github would quickly dismiss it; "we already have Github!"
So Google are playing up the integration with the rest of Google Cloud, integrating with Github and Bitbucket, and offering additional features.
You have to extrapolate a bit to realize it, and Google probably won't admit it, but this is definitely intended as a Github/Bitbucket competitor.
They're private repos to which only people in your projects have access.
Food for thought...
What do you mean? Don't you use gmail, publish to the app store, and host with AWS? Do you use Stripe for payments? Google Maps? Facebook login? You are trusting these companies with a great deal.
Dear god no, no, no, no, no, no.
> Don't you use gmail, publish to the app store, and host with AWS? Do you use Stripe for payments? Google Maps? Facebook login? You are trusting these companies with a great deal.
Believe it or not, most people do not do all of these things. Many do none.
Because trusting large companies that are trusted by many others and have invested in a large infrastructure makes it much more feasible to accomplish their goals. It is possible to trust no one, eg build on the blockchain or freenet, but there is so far much less audience, and it's only recently become feasible to go to marketwith that stuff.
If your goal is to attract millions of customers who can understand how to get started with your technology, trusting large corporations is usually an acceptable tradeoff.
And if you want to be competitive with what's out there using the features of native iOS or AWS or gmail or whatever these services offer that you can't simply get without trusting them, then you HAVE to trust them or users will use another product which did.
Hint: source code is not GitHub's value, just like books where not Amazon's. GitHubs true value is something Google is profoundly bad at.
That along with the cloud debugging from their git repo are some nice to haves.
"Using Cloud Source Repositories is easy if you are familiar with Git. For example, you can add a Cloud Source Repository to a local Git repository as a remote, or you can connect it to a hosted repository on GitHub or Bitbucket"
If the goal is lock-in, they're doing it wrong.
Isn't that what happens immediately after one places their artifacts into "the cloud"?
PM, Google Cloud Platform
I hope that someone really does make an online IDE that means I don't have to use a local IDE anymore, but I'm not certain how feasible that is. Atom seems like a giant step in the right direction.
That's not a feature of this product, it's just how git works.
For my personal projects, I'm fine with my own git server on a cheap vm, but for work I've been really happy with Github's issue tracker and org membership administration (with which we use OAUTH heavily for internal tools, several of which queue background computation). Github issues are much easier for tracking job submissions from analysts than integrating with the company email, and developers prefer it.
I looked at GitLab a year ago. I liked it, but it was a little funky (avatars weren't working; obviously not mission critical, but little shit like that erodes confidence -- either support a feature or don't, but never half ass it because I'm not going to admin over a server when I've got a chorus analysts bitching about it being hacky). GitLab people: this was a digitalocean prepared image version of GitLab, in case you're listening.
Version control is really the most minor and easy to replicate part of Github's value proposition.
No one seemed to like it. Heck, Google didn't seem to like it enough to give it any love, just check out the UI on the site: https://code.google.com/hosting/search?q=label%3aPython
> This Beta release of Cloud Source Repositories is free and can be used to store up to 500 MB of source files.
No thanks! I still remember what happened with AppEngine.
I used it a little bit a few years ago and despite the issues with the original platform I'm quite interested in the new Docker based managed-vm app engine platform, where you can build your own images and have much better control, and compute engine pricing.
So yeah, don't invest into something when you don't know what the final pricing will be.
And keep in mind, googlesource.com is not the same service as the one talked about in this article. Not even the same backend.
I wonder how many people shy away from AWS on the thought that web services aren't Amazon's core business model.
2. No built in issue tracker or wiki (?)
Also, and we're planning on upping the limit once we reach GA. What do you think a reasonable limit should be for a git repo? Our goal is to strike the right balance between usefulness and abuse.
Hacker News is a cloud service---we share comments on news stories in a collaborative fashion. I assume this means something closer to "I don't want my personal, sensitive data hosted by anybody and I'm willing to pay for the inefficiency and inconvenience of only being able to access it from a handful of nodes (or having to maintain my own hosting solution on my own hardware)" than the alternative interpretation "I'm a Luddite; down with the Internet?"
Any service, especially served abroad like in the US, where I share any of my data, I no longer feel as good about using.
Dropbox? There's a clone. Pinterest? Clone. Everything. Then they dogfood it and if there's more interest they gather up more resources to inevitably pitch the idea to Marissa Meyer, who then plays with it, design the business case for it, and approve a proper budget for it.
If the product is good then the news leaks or they launch it. After awhile if the Google audience doesn't like it they cut it loose.
Which goes to say... any time some investor asks you what happens if Google comes into your space, you should say: good.
Are they saying it is not secure?
Cloud Source Repositories are intended to store only the source code for your application and not user or personal data. Do not store any Core App Engine End User Data (as defined in your License Agreement) in a Cloud Source Repository. To use a hosted Git repository with a Cloud Source Repository, you must first open an account with GitHub or Bitbucket (independent companies separate from Google). If you push source code to a Cloud Source Repository, Google will make a copy of this data which will be hosted in the United States.