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.
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.
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.
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 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.
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.
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.
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 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.
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.
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.
49 comments
[ 2.7 ms ] story [ 108 ms ] thread[0]: https://github.com/v8/v8
[1]: https://groups.google.com/forum/#!topic/v8-users/VgL3Fn4ijqE
https://chromium.googlesource.com/v8/v8.git
I remember when I thought sourceforge was so good. Now I silently weep when I need to go there for anything.
Aren't mirrors going to be slightly out of date (unless continually synchronised). And you wouldn't commit to the mirror, right?
For me the advantage is being able to use GitHub's nice UI to browse the source code.
Synchronising a mirror automatically is pretty trivial so I imagine they're usually pretty up to date.
fwiw you can do this on chromium.googlesource.com as well. look for link called `[path history]` when navigating the tree.
They have a mirror and it appears that they are killing Google Code and I get 4 down votes NICE
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.
GitHub is very poor on that matter.
1. v8 is just a Google project. Their decisions doesn't represent the company as a whole.
2. They just changed the VCS.
3. When Google is going to shut down a service, they warn you several months in advance.
Honestly, whether Google will shut down Google Code or not should not be a concern until they announce it officially...
My post: It is good to see that a company can accept that there is a better tool, github.
They were WRONG Google is moving to github https://github.com/google
Lots of repos are hours old thanks down voters.
https://chromium.googlesource.com/v8/v8.git/+/5d65e1374fd9c5...
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?
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.
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.