Google Code is going, going .... (will be) gone.

[guinness]

I am a little surprised that it didn't happen sooner. GitHub is used so much by Google these days, including their recent transition of Guava (a popular Java framework). I guess that was the real indicator that Google Code isn't their priority anymore.

Source: http://www.ghacks.net/2015/03/12/google-code-is-dead/

[Specular]

Was just about to post this in general discussion. Curious how many Google hosted projects are in the database, and whether they'll all get moved.

Chris diBona (director of open source at Google) has at least said that they'll be making a copy of the majority of abandoned projects and hosting it on googlesource.com.

We are planing on taking the majority of these legitimate, open source, 'abandonded' projects and putting them up in cold storage in a git repo on googlesource.com

[webfork]

Sigh.  That will probably require a bunch of site maintenance. Here's the Google results so far.

Sucks that they can't keep the doors open because of a stupid internal/external view that "Google doesn't / shouldn't take donations" to cover costs.

[I am Baas]

Sigh.  That will probably require a bunch of site maintenance. Here's the Google results so far.

Thanks webfork. I updated a couple of entries already. Some projects look abandoned though .

[webfork]

This has been on my todolist for quite a while and I finally came back to it...

I updated a couple of entries already.

Yeah I saw that, thanks for the help.

Some projects look abandoned though .

True. There's a constant slow slide toward inactivity with most freeware. I'm happy to say that on this group of open programs, someone could come back to them eventually.

Some notes so far:

* Duplicati - although the homepage has moved to GitHub (https://github.com/duplicati/duplicati), the download site hasn't. They're only listing the preview version on GitHub so I'll maintain the old download.

* Qrdecoder, MMD2PDF, 5 Minute Break - haven't moved yet

* ZScreen - project home page is actively pointing to ShareX so I've asked Andrew to zap it from the database to avoid confusion.

* Pshutdown - is no more, though with open software you of course never know. Added something to the entry.

[carbonize]

That's the thing about creating something then giving it away for free though. At first you're all hyped and are using it as a way of learning as well as because you have some ideas you just think people would like. Few years down the line and you end up where you need to do a total rewrite from the ground up to either bring it up to date with modern techniques or to add unicode support or, in my case, because PHP is constantly evolving and you just don't have the time you used to.

I'm at that point now with a script I forked about 15 years ago. My code now is mostly patchwork where I have added new functionality or improved existing ones but the core of the code is over 15 years old. So now I find myself having to either do a total rewrite of it or, as I intend, to create a newer version. But life doesn't stay still and I have far more responsibilities than 15 years ago and far less free time.


As to the subject at hand Google has a history of starting things then just letting it die. They see something doing well and think they can do better but their version doesn't get the users so they kill it. Think of Buzz, gTalk and now Code. Yes I know that technically gTalk became Hangouts but gTalk was XMPP based and open where as Hangouts is not.

[webfork]

Google has a history of starting things then just letting it die

I don't want to fault them for trying new things and I realize stuff has to make money, but I really don't know why they couldn't put code.google under a positive PR heading i.e. "look at all we do for the community".

Either way, it is (yet again) an argument for our work here since portable software will do what you need the first time and the 50th, whereas online services will continue to come and go.

[guinness]

Google has a history of starting things then just letting it die

I don't want to fault them for trying new things and I realize stuff has to make money, but I really don't know why they couldn't put code.google under a positive PR heading i.e. "look at all we do for the community".

Google Code came around when SVN was mature and git was just taking off, so to resurrect this, would require the company switch to a more GitHub-like interface. Which if I'm honest GitHub does it better and Google knows this. So I am glad Google Code disbanded, as SubVersion had it's time and place, which isn't now.

[SYSTEM]

So I am glad Google Code disbanded, as SubVersion had it's time and place, which isn't now.

I disagree about that. I still prefer the centralized version control model where there is just one repository per project (instead of the decentralized model where every developer has their own repository). I guess that I just like that, for any project using Subversion correctly, I can point at one repository and say "This is where the project source code is".

One notable disadvantage of decentralized version control is lack of sequential commit numbers (because commits are often copied between repositories, and therefore commit numbers would change). Git, for example, identifies commits with a SHA-1 hash. A couple of real-life situations where sequential commit numbers are useful:

• Bug tracking. A developer fixes a bug, commits the fix and writes to the bug tracker "Fixed in revision 9001." Next day, a QA tester obtains build 9010 and is able to verify the fix with it, because commit 9010 comes after commit 9001. That doesn't quite work if the programmer writes instead "Fixed in commit 2a6eb5e1bb53fddf756ebaf3a429174abb52042a" and the tester receives build 7282acf50866288159cf3e4d73a06b7f00c13f2a next day.
• End users. Similar case as above. For example, in the mpv media player haasn implemented debanding support for OpenGL video output driver in commit 97363e176d180f4f1bbc1e67e3e513c493ce31ed. If an user happens to have a build from around the same time, they have only two ways to find out if their build has debanding support: 1) test for it, or 2) find the right commit from the repository and compare the dates (this is relatively easy, yes, but still significantly more effort than simply comparing two numbers).
• Memory. A sequential commit number is easy to remember. Try remembering a SHA-1 hash.

If you were wondering why I moved Project Invincible from Google Code to SourceForge instead of GitHub, this is the reason. My dislike for Git and decentralized version control.

[guinness]

I can't really argue with the rev numbers being absent, though honestly haven't found it to be such a big problem, as tags are an alternative solution. Plus, the reason revision numbers exist in SVN, is because branching and merging is not an easy process compared to git. So normally what happens in git, when a new feature is implemented, you create a branch off of the master, commit the feature, test, fix, repeat and then submit a PR. So really, no buggy code should be making its way to the master branch, or what ever branch is currently checked out globally.

As for the decentralized comment, don't you find it annoying that you must be connected online to make a commit? Or do you create multiple changes under one revision and then push to the server? As I know it would be annoying if I was out of the office and I couldn't work on the repo due to loss of connectivity.

Also you can work in a centralised fashion by using a git management system, like GitHub or GitLab. You have one or two people who look after the master branch and everyone else submits PR to them, in which they can also review (inc... dev team) and merge. So the code is reviewed several times, before making its way into the master.

Therefore, I fail to see the reason really why someone would still stick with SVN, but I respect that you do, so who am I to say otherwise.

PS Watched a lecture by Linus (a week ago) from 2007 @ Google, talking about git. Quite funny!

[SYSTEM]

So normally what happens in git, when a new feature is implemented, you create a branch off of the master, commit the feature, test, fix, repeat and then submit a PR. So really, no buggy code should be making its way to the master branch, or what ever branch is currently checked out globally.

I dislike feature branches as well. I find they add unnecessary hassle for little benefit.

At work I occasionally commit work-in-progress features to trunk (Subversion's equivalent to master branch). Every time I finish the feature soon after with a few more commits. I think it simply doesn't matter that there was an incomplete feature ("buggy code") for a day or two.

After all, usually only developers use trunk builds, and it doesn't matter too much if they run into bugs. And even if it's an open source project that recommends end users to use trunk/master builds, the most common case of buggy code, unfinished features, isn't too problematic: just don't use that feature if you can't stand the bugs.

As for the decentralized comment, don't you find it annoying that you must be connected online to make a commit? Or do you create multiple changes under one revision and then push to the server? As I know it would be annoying if I was out of the office and I couldn't work on the repo due to loss of connectivity.

No, because I'm always online when I use a computer. At the moment the only computer I own is a desktop computer (with cable Internet).

By the way, this is a good example of different ways of thinking in centralized and decentralized version control. In centralized version control, the idea of committing code when you're offline doesn't make any sense because you're not connected to the repository.

Also you can work in a centralised fashion by using a git management system, like GitHub or GitLab. You have one or two people who look after the master branch and everyone else submits PR to them, in which they can also review (inc... dev team) and merge. So the code is reviewed several times, before making its way into the master.

Decentralized version control can't emulate centralized version control well enough in my opinion. In particular, even if you create a canonical repository in GitHub and give all developers the privilege to push commits directly, all developers still have their own repositories (and some have two - one in GitHub and another in their hard drive). It doesn't bring back commit numbers either.

Therefore, I fail to see the reason really why someone would still stick with SVN, but I respect that you do, so who am I to say otherwise.

Likewise, it's fine for me if other people want to use different tools. It was just the statement "SubVersion [sic] had it's [sic] time and place, which isn't now" that I don't agree with.

Subversion isn't dead, far from it. Apache released Subversion 1.9.0 on August 5. And I fully agree with their vision (particularly the "simplicity of its model and usage" part):

Subversion exists to be universally recognized and adopted as an open-source, centralized version control system characterized by its reliability as a safe haven for valuable data; the simplicity of its model and usage; and its ability to support the needs of a wide variety of users and projects, from individuals to large-scale enterprise operations.

[guinness]

Don't get me wrong, I still use SubVersion for the AutoIt repo, but honestly if you search around you will see statistically SVN is on the decline. I am now waiting for some CVS user to drop by and argue their case.

[SYSTEM]

Don't get me wrong, I still use SubVersion for the AutoIt repo, but honestly if you search around you will see statistically SVN is on the decline.

That's true. I still think that Subversion has its place in today's world as well, though.

I am now waiting for some CVS user to drop by and argue their case.

That would indeed be quite funny. Mind you, you can reasonably claim that CVS (unlike Subversion) is dead: https://en.wikipedia.org/wiki/Concurren ... ent_status