If you're still using Google Code for any projects I'd really recommend moving it to another service at this point unless you have a compelling reason to stay. There's some good evidence at this point that's leading me to believe Google Code is next on the chopping block for dead Google services.
He wasn't saying google code was bad, just that it's likely the next service to be cut by our friends over at Google. Given that v8's moving, this is pretty reasonable prediction.
Google code also makes it really hard to subscribe to projects mailing lists with a non-gmail e-mail. It is possible, you just have to know how to construct the subscribe message or get the maintainer to invite you.
I don't know about them moving to Github, but the v8/v8 repo [0] (currently the svn mirror) has been deprecated and the git repo mirror will replace it in the near future [1]. That's the extend of them using Github as far as I know.
Looks like V8 runs Mozilla's JS tests too. I didn't know that. Does Mozilla do something similar to ensure that V8's tests work in Mozilla(Firefox) as well?
Mozilla's JS tests have for a while been run by everyone else because they have typically tested a lot of de-facto required behaviour that isn't specified anywhere. That said, the problem with both them and mjsunit (V8's JS testsuite) is they freely mix tests for unimportant implementation detail (say, details of enumeration order!) and what is de-facto required. In the end, with Carakan, we decided it wasn't worth the time to get the mjsunit tests running — they found almost nothing that weren't found otherwise — and coming up with proper expectations and keeping them up to date does take time.
I hope they also modify their build process a little.
Right now, when you want to build V8, it automatically downloads all the tools it depends on. This makes it difficult to store one particular version of the library and all the tools it depends on.
I find it interesting that they commit directly to master. I didn't see any branch merges at all. What is their workflow if they don't use branches? Do developers work offline on a fix then squash all their changes into a single commit and push it to master?
Generally having so many devs working off the same branch at the same time can be a bit problematic. My philosophy is that master should be for branch merges only.
Just do fast-forward merges. This means before pushing into the central repo, you rebase your feature branch onto origin/master. Cleaner history and easier to bisect.
However, I prefer non-fast-forward merges for features branches which break in between. Although rebase on origin/master is still good, because you find merge-bugs locally.
You never know with git. Which is one of my big problems with it. The picture on master doesn't necessarily represent what happens on other repos across your organisation.
I look forward to seeing the rest of Chromium follow. Hopefully it'll move from Reitveld to Gerrit and repo in the process. Reitveld has SVN support, but it and its command-line tools are otherwise more painful than Gerrit in every way.
This is good. Github mirrors of the repo are already available. Even though this does not help contributors it would help people like me to play with v8 lot more.
Google has had a Github account for a long time now. That doesn't mean they're moving all development over to Github for all Google projects. And the v8 project is moving to Google's Git infrastructure, not Github.
You do know that Google has had a presence on GitHub for quite a while. AngularJS, Polymer, CCA, Dart, Go, Karma...I'm sure there are many other examples.
I can't speak for everyone, but I appreciate the mirrors because I enjoy reading and searching through codebases on Github, so having the repository mirrored there is useful.
If you look below the repository title on GitHub, it says "mirrored from..". This means GitHub handles the synchronization (they set this up on request for some projects).
For me the advantage is being able to use GitHub's nice UI to browse the source code.
Github has some nice features that chromium.googlesource.com lacks, like being able to list all of the commits that have changed files in a specific sub directory.
Synchronising a mirror automatically is pretty trivial so I imagine they're usually pretty up to date.
> Github has some nice features that chromium.googlesource.com lacks, like being able to list all of the commits that have changed files in a specific sub directory.
fwiw you can do this on chromium.googlesource.com as well. look for link called `[path history]` when navigating the tree.
