Google sluit deuren van sourcecodehosting-site Code

Google Code, waar ontwikkelaars opensource-projecten konden hosten, gaat zijn deuren sluiten. Dat heeft Google bekendgemaakt. Er zijn inmiddels betere alternatieven als GitHub en Bitbucket, en dus is Code niet langer nodig, stelt Google.

De zoekgigant riep Code in 2006 in het leven, naar eigen zeggen omdat er toen beperkte keus was voor ontwikkelaars die hun code wilden uploaden, bijvoorbeeld om in teamverband samen te werken. Inmiddels zijn er betere alternatieven, zoals GitHub en Bitbucket, en is Google Code dus niet meer nodig, stelt de zoekgigant. De sourcecodehosting-site zal daarom zijn deuren sluiten.

De sluiting van de site verloopt geleidelijk. Het is nu al niet meer mogelijk om nieuwe projecten aan te maken, maar voor bestaande projecten verandert er de komende maanden niets. Vanaf 24 augustus is het echter niet meer mogelijk om wijzigingen door te voeren; vanaf dan is de site in read-only-beschikbaar. Vanaf volgend jaar januari is de site definitief gesloten, al worden er gedurende heel 2016 nog tarballs met de inhoud van projecten aangeboden.

Google heeft een tool gemaakt waarmee ontwikkelaars hun code naar GitHub kunnen exporteren. Projecten op Google Code die Subversion of Mercurial voor versiebeheer gebruiken, worden daarbij geconverteerd naar Git-projecten. Google stelt dat het zelf al bijna duizend projecten van Google Code naar GitHub heeft overgeplaatst.

Reacties (91)

[svennd]

Ja er zijn alternatieven... maar zeer weinig voor SVN toch

[Proxi]

Zelf vind ik Git fijner, wat vind je precies fijner aan SVN?

[svennd]

Als single dev. hoef ik geen lokale "repo" , SVN heeft ook enkele handige plugins in windows, alsook in notepad++. Allemaal zaken die ongetwijfeld in alternatief voor GIT bestaan ook. Het is eigenlijk zoals bij zoveel puur smaak. Github ziet er leuker uit, heeft meer functionaliteit maar geen svn ...

O en een groot verschil, je kunt geen lege dir aanmaken

[Reactie gewijzigd door svennd op 22 juli 2024 15:47]

[pingwings]

Samenwerken en je history schoon houden kan wat mij betreft een stuk beter in git.

Je hebt gewoon tortoisegit voor Windows en de grote editors hebben ook git support. Ik gebruik het zelf voor al mijn dev klussen, ook al zijn sommige slechts wat hobby-dingen. Git helpt mij met developen een stuk meer dan wat svn deed.

[defixje]

Dan raad ik je eens aan om dit te lezen. Gaat over Git Flow, gebaseerd op de Git branching model.

Geheel werkt voor mijzelf erg goed, vooral de feature branch'es zijn handig voor het samenwerken.

Url: Git Flow

[Reactie gewijzigd door defixje op 22 juli 2024 15:47]

[roy-t]

Als er nu iets overkill is als single dev dan is het wel Git Flow


* roy-t is een fervent git/mercurial gebruiker, ook voor eigen projecten maar je kunt ook overdrijven in je eigen proces, en meteen iemand git-flow aanraden terwijl deze nog lekker linear (niets mis mee) met SVN werkt is een beetje over de top

[defixje]

Ik reageer dan ook op

Samenwerken en je history schoon houden kan wat mij betreft een stuk beter in git.

Misschien was ik niet duidelijk. Maar voor Single Dev hou ik ook gewoon de simpele Master/Develop aan, ga dan niet met feature-branches werken natuurlijk

[roy-t]

Excuus ik dacht dat je op svennd reageerde!

[svennd]

Dat is het net, ik ken SVN en ik werk alleen. Keuze is toch enkel maar positief?

[Olaf van der Spek]

Nee, keuze is geen doel op zich. Ik heb liever een goede oplossing dan de keuze uit 10 minder goede.
Ik heb tot nu toe ook altijd SVN gebruikt (en daarvoor CVS) maar volgens mij zijn bepaalde dingen van Git toch echt wel handig.

[Reactie gewijzigd door Olaf van der Spek op 22 juli 2024 15:47]

[RoestVrijStaal]

Geen lokale repo? Draai je de Subversion server-daemon op een aparte machine dan?

In de beginjaren van git haalde ik ook mijn neus erover op en bleef vrolijk verder gaan met Subversion. Ik had de server-daemon op m'n dev-machine draaien. Die hoefde enkel gestart te worden wanneer ik ging committen, mergen of een rollback deed.

Een paar maanden geleden besloot ik alsnog met git te experimenteren en nu wil ik niet anders.

De reden is dat ik ben overgestapt is dat je bij git enkel de client-software nodig hebt om een (privé/lokale) repository te maken. Voor Subversion moet je dan zowel in de server-daemon als bij de cliënt-applicatie weer het een en ander instellen.

Voor eenpersoonsprojecten is het verschil minimaal. Beide technologiën doen hun werk goed. Daarom is de keuze voor het gebruik van Subversion voor eenpersoonsprojecten niet an sich slecht. Mijn ervaring is dat projecten waarbij Subversion werd gebruikt grotere problemen (luiaards die verkeerd mergen, checkouts/commits van anderen waardoor delen van hun code weer verloren gingen ) voorkwamen dan bij git.

Wat me ook opvalt is dat er in vergelijking met git zo weinig opensource Subversion clients uit zijn gebracht en up-to-date blijven. Ok, behalve TurtoiseSVN (die als shellextensie de Windows Verkenner aardig bloat) en plugins in een zelfrespecterend IDE. Terwijl Subversion ouder is dan git.

[Reactie gewijzigd door RoestVrijStaal op 22 juli 2024 15:47]

[Olaf van der Spek]

Voor Subversion moet je dan zowel in de server-daemon als bij de cliënt-applicatie weer het een en ander instellen.

Dat is niet waar toch? SVN repos kon je ook gewoon lokaal in een directory opslaan die direct door de client werd benaderd zonder iets als svnserve.

[RoestVrijStaal]

Wat je omschrijft lijkt op een checkout.
Dan download je inderdaad de bestanden die in de (externe) repository staan naar die lokale directory en dan kun je inderdaad de gecheckedout code bewerken en (mits je permissies ervoor hebt committen naar de repository.

Ik had het in mijn vorige post over puur lokaal werken, dus zonder dat er een sourcecodehosting-dienst gebruikt wordt. En in het geval van svn moet je dan wel je eigen repository lokaal of op je eigen server hosten.

Ik had niet de behoefte om de code van mijn eigen projectjes publiek te maken. En gedeeltes van huidige code diffen of terugzetten naar gisteren of eergisteren is met revision control systemen makkelijker gedaan dan domweg zipjes van de hele codemap met een datum eraan vast.

[Olaf van der Spek]

Nope, ik heb het echt over een SVN repository op een lokale schijf. Geen server daemon nodig, alleen de client. Zie http://tortoisesvn.net/do...N_en/tsvn-repository.html

[riotrick]

Dat is correct. Subversion heeft helemaal geen server daemon nodig.

De repository is niets anders dan een aantal bestanden in een directory. Die de cliënt direct kan benaderen.

De svn server daemon (of http met een svndav mod) wordt gebruikt om een repository over het netwerk benaderbaar te maken. Dat zal in de meeste gevallen wel gebruikt worden, maar het is zeker geen vereiste.

[RoestVrijStaal]

Ah, Ik wist niet dat je de file:// URI-Scheme ook kon gebruiken. Ik gebruikte altijd svn:// omdat die in elke situatie werkte.

[svennd]

Naar ik begrijp is de lokale git repo, ook een volledige repo met history enzo. Je kunt ook jaren commiten zonder ooit te pushen. Bij SVN heb je lokaal enkel je "werkfiles" staan (trunk). De repo leeft in de server.

Ik heb git geprobeerd en ik vond het maar niks. Ik werk veel offline, en ik vergat altijd te pushen voor ik vertrok... mergen is altijd zo'n ramp omdat ik altijd aan 1 deel werk. Overigens was het ook vervelend dat lege mappen niet werken.

Er zijn een pak voordelen van Git, maar noem het nostalgie maar ik hou van m'n svn, die werkt voor mij perfect, vandaar spijtig dat google code ermee stopt. Want een echt alternatief voor SVN is er niet.

[djiwie]

Ik heb git geprobeerd en ik vond het maar niks. Ik werk veel offline, en ik vergat altijd te pushen voor ik vertrok... mergen is altijd zo'n ramp omdat ik altijd aan 1 deel werk.

Als je veel offline werkt is git toch juist handig? Je kunt offline gewoon meerdere commits maken, en als je weer connectie hebt push je ze naar je server/andere pc/etc. Met SVN zit je een commit dan uit te stellen totdat je verbinding hebt met megacommits als gevolg.

[svennd]

Bij git dan met megapushes ? :-) Veel is mss ook overdreven per dag een uur of 3 offline ...

[djiwie]

Maar een 'megapush' is geen probleem. In je commit history zie je die verder niet meer terug, en je commits zijn wel netjes atomisch.

[dmantione]

Naar ik begrijp is de lokale git repo, ook een volledige repo met history enzo. Je kunt ook jaren commiten zonder ooit te pushen. Bij SVN heb je lokaal enkel je "werkfiles" staan (trunk). De repo leeft in de server.

Dat klopt, maar is eenvoudig oplosbaar door een SVN-server lokaal te draaien. Je kunt dan naar hartelust naar je lokale SVN-server committen en als je de boel naar de hoofdrepository wilt sturen doe je een svn merge.

[SirQuack]

Het is misschien minder bekend, maar als ik deze blog post mag geloven, ondersteund GitHub gewoon SVN.

[cracking cloud]

Ik gebruik al een paar jaar repositoryhosting.com, die ondersteunt ook SVN en kost maar 6 dollar per maand.

[Verwijderd]

Om lege dir's aan te maken word .gitkeep gebruikt. Ik heb SVN jaren gebruikt maar ik vind git toch een stuk beter in elk opzicht,. Ook is een lokale repo super handig, mocht je even ergens offline lopen te werken kan je toch commits/tags etc aanmaken en bij je historie.

[svennd]

Ik kan ook offline commits en tags bijhouden ... ik zie het nut niet van commit/push voor mij alleen. Zelfs al staat work-in-progress op de server ... het is een trunk. De tags zijn werkende releases.

[CyBeR]

Dat is de grap van git juist: je hoeft helemaal niet te pushen, maar dat moet feitelijk met svn wel.

Een push is alleen maar het versturen van je informatie naar een remote repository. Iets wat je met 'svn commit' ook per definitie doet.

Je kunt ook gewoon compleet lokaal werken met git: dan commit je en push je dus niks.

[svennd]

Een van de belangrijkste redenen voor mij is dat de code ook centraal beschikbaar is ... dus 2* werk ipv 1*werk.

[CyBeR]

Mja. Kijk, als jij liever svn gebruikt moet je dat vooral zelf weten maar begrijp dat de rest van de wereld svn compleet aan de kant schuift. Zoals je cvs al nergens meer tegen komt omdat 't is vervangen door svn, kom je binnenkort svn ook nergens meer tegen omdat 't is vervangen door git (of soms mercurial.) In dat opzicht raad ik je sterk aan om om te leren gaan met git.

Overigens, je zegt elders:

Ik werk veel offline

en dat is heel grappig want daar is svn dus compleet ongeschikt voor.

[dmantione]

Het ligt wel iets genuanceerder. In een opensourceproject waar ik in ontwikkel zijn er regelmatig discussies waarin git-adepten preken hoeveel beter git wel niet is, maar de belangrijkste ontwikkelaars zijn van mening dat git voor de manier waarop we ontwikkelen geen echte meerwaarde zou bieden. Svn bood wel duidelijke meerwaarde t.o.v. cvs, daarom is wat ons betreft de vergelijking tussen svn git een hele andere dan tussen svn en cvs.

[Reactie gewijzigd door dmantione op 22 juli 2024 15:47]

[CyBeR]

maar de belangrijkste ontwikkelaars zijn van mening dat git voor de manier waarop we ontwikkelen geen echte meerwaarde zou bieden.

Dat hoor je vaker, maar stel jezelf dan de vraag of 'de manier waarop we ontwikkelen' niet een gevolg is van het gebruik van svn, in plaats van andersom. Met andere woorden: kun je niet beter (efficienter, minder fouten, watdanook) ontwikkelen door dat op een andere manier te doen die svn niet (goed) ondersteunt?

[dmantione]

Waarschijnlijk niet, omdat simpelweg meer handelingen nodig. De bekende is de commit+push. Maar een mogelijk belangrijker is het mergen van commits naar de stabiele branch. Er is nu een systeem waar per commit gevlagt wordt of de commit gemerget is, wat vrij efficiënt werkt omdat iemand in een middagje tientallen bugfixes naar de stabiele branch kan bijwerken. Bij Git kun je met merge requests wel ongeveer hetzelfde bereiken, het is gewoon bewerkelijker.

[CyBeR]

Dat 'middagje bijwerken' is bij git een kwestie van seconden: git checkout master && git merge <bugfixbranch>.

Let ook even op dat je git niet verwart met github.

[Reactie gewijzigd door CyBeR op 22 juli 2024 15:47]

[dmantione]

Nee, want daarmee merge je de hele branch (dus ook al je commits die je niet wilt mergen). Met een middadje bijwerken bedoel ik de commitlogs bestuderen, daaruit de gewenste commits selecteren, die mergen, de betreffende commits afvlaggen dat ze gemerget zijn, en de resulterende branch testen en testsuite draaien.

[Reactie gewijzigd door dmantione op 22 juli 2024 15:47]

[CyBeR]

dus ook al je commits die je niet wilt mergen

Dat die er zijn is een duidelijke indicatie van een ontwikkelproces wat niet goed werkt imo.

[dmantione]

Hoezo? Je wilt voornamelijk bugfixes mergen naar je stabiele branch. Alle nieuwe ontwikkeling moet in je trunk blijven gebeuren en al die commits wil je dus niet mergen.

[CyBeR]

Alle nieuwe ontwikkeling moet in je trunk blijven gebeuren

En dat is dus weer een indicatie van gelimiteerd worden door svn Bij svn is dat de gebruikelijke manier van werken omdat branches in svn best wel kut werken. Bij git (en hg) is dat niet zo en kun je ontwikkeling doen in een aparte branch en dat pas mergen naar master als 't klaar is.

Voor jullie huidige ontwikkelmodel zoals je 't omschrijft is git inderdaad niet handig (dwz, voegt relatief weinig toe). Maar je zit ook duidelijk met dat ontwikkelmodel vanwege de limitaties van svn, niet omdat 't nou zo goed werkt.

https://www.atlassian.com/git/tutorials/comparing-workflows

[Reactie gewijzigd door CyBeR op 22 juli 2024 15:47]

[dmantione]

Precies, dan kom je op de kern van de discussie."mergen als iets klaar is". Wanneer is iets klaar? Programmeur x merkt dat de testuite op Windows/X86 goed werkt en merget de boel. Maar hij heeft geen MacOS X op PowerPC. Dat is een sterk argument om toch een trunk te hebben, die in ons geval 's nachts op zo veel mogelijk platformen automatisch getest wordt.

Svn en meer nog cvs hebben zeker hun invloed gehad op het ontwikkelmodel, maar dat betekent niet dat het ook gelijk logisch is om het om te gooien.

[CyBeR]

Precies, dan kom je op de kern van de discussie."mergen als iets klaar is". Wanneer is iets klaar? Programmeur x merkt dat de testuite op Windows/X86 goed werkt en merget de boel. Maar hij heeft geen MacOS X op PowerPC. Dat is een sterk argument om toch een trunk te hebben, die in ons geval 's nachts op zo veel mogelijk platformen automatisch getest wordt.

Zeker niet. De gemiddelde CI-oplossing voor git/hg test namelijk ook branches.

Svn en meer nog cvs hebben zeker hun invloed gehad op het ontwikkelmodel, maar dat betekent niet dat het ook gelijk logisch is om het om te gooien.

Oh inderdaad, maar als je er daadwerkelijk iets uit kunt halen (en ik denk dat dat zo is) is 't ook weer zo'n onzin om 't niet te doen. Het vereist absoluut een verandering in hoe je werkt om er het maximale uit te halen, maar dat is allerminst verplicht.

Ik heb die omschakeling meegemaakt, al twee keer. Eerst van CVS naar SVN, wat al een flinke verbetering was, en toen van SVN naar git. En geloof me, als je eenmaal die klik hebt van hoe je git serieus gebruikt (en dan bedoel ik dus niet gewoon svn na-doen maar dan met git commando's) wil je nooit meer terug.

Overigens zeg ik steeds git omdat wij dat gebruiken, maar voor hg en dergelijke distributed vcs'en geldt in hoofdlijnen hetzelfde.

[Armada651]

de commitlogs bestuderen, daaruit de gewenste commits selecteren, die mergen

Klinkt als git rebase -i

[Reactie gewijzigd door Armada651 op 22 juli 2024 15:47]

[dmantione]

Git rebase komt meer in de buurt, maar kan op zichzelf geen lijst geven van commits die nog niet afgevlagd zijn en dus bekeken moeten worden, en ook geen makkelijke manier om individuele commits te selecteren. Zowieso is svn op dit punt makkelijker omdat commits een volgnummer hebben ip.v. een lange hashcode.

[Armada651]

Git commits hebben ook een volg nummer, die krijg je met git describe.

Bovendien is dit 'afvlaggen' van commits volgens mij helemaal geen standaard functie van SVN.

[Daeley]

Zoals je cvs al nergens meer tegen komt omdat 't is vervangen door svn, kom je binnenkort svn ook nergens meer tegen omdat 't is vervangen door git (of soms mercurial.

Wauw. Sorry, maar dat is gewoon totaal fout. Er zijn veel legacy codebases die nog op SVN of zelfs CVS draaien. Een groot project met een paar honderd developers en miljoenen lijnen code zet je niet zomaar in een knip om.

[P_Tingen]

Misschien moet je het niet AL te letterlijk nemen, ik denk dat ik - als ik even goed zoek - ook nog wel ergens een cvs repo kan vinden, compleet mét groep enthousiaste gebruikers, dus "Zoals je cvs al nergens meer tegenkomt" moet je óók met een korreltje zout nemen.

Korte samenvatting: git is hip, svn niet.

[Niemand_Anders]

Plus dat men nu continue een decentraal versioning systeem met een centraal versioning systeem aan het vergelijken is..

Een belangrijke reden waarom veel bedrijven nog steeds met svn werken ipv git, is dan svn geen '-no-verify' kent waarmee je de commit hooks kunt omzeilen. Overigens had ik wel graag een pre-merge hook in git gezien, zodat je als developer wel niet-werkende code kunt committen (opslaan van je huidige werk), maar de code niet gemerged kan worden als deze niet build of een unit-test fout gaat..

Maar de discussie hier voelt erg als een vi(m) vs emacs discussie aan..

[CAPSLOCK2000]

Voor mij is SVN in veel gevallen simpeler dan git. Git is heel krachtig maar daardoor soms ook omslachtig. Een simpel voorbeeld is dat je git apart moet comitten en pushen. In SVN is dat 1 actie. Ik snap de voordelen van het gescheiden houden van die twee maar in heel veel gevallen voegt het weinig toe maar maakt het de boel wel maar complexer. Nu is er vast een manier om git hetzelfde te laten doen, maar svn doet het direct.
Git heeft gekozen voor flexibiliteit en is geoptimaliseerd voor grote projecten met een hoop onafhankelijke developers. SVN is beter geoptimaliseerd voor kleinere teams die nauw samenwerken. Git is geschreven om te kunnen omgaan met de extreme eisen die de Linux-kernel stelt aan versiebeheer software maar in de meeste situaties zijn de eisen veel simpeler. Dan is SVN de makkelijkere tool.

[jaapzb]

Vind het juist een voordeel in een project waar je met meer dan 1 personen werkt dat als je iets commit dat het nog niet gelijk gepushed wordt. Als je dan namelijk toch iets fouts commit dan is de boel bij iedereen gelijk naar de taffes.

Dat is in ieder geval de (geforceerde) ervaring die ik van SVN heb gekregen tijdens mijn opleiding Informatica. Kan natuurlijk zijn dat ons SVN daar gewoon verkeerd aangeleerd werd.

[Ruudjah]

Hopen dat dat zo blijft! Niemand is uiteindelijk gebaat bij verder gebruik en ontwikkeling van SVN. Beter om snel naar Perforce, Git of Mercurial te gaan.

[svennd]

Want ? Niet omdat het nieuw is dat het beter is... op het werk, werken we met darcs ...

[Ruudjah]

Het is inmiddels heel duidelijk dat DVCS-en conceptueel en implementatiewijs niet-DVCS-en VCS-en op alle vlakken voorbij zijn. Oude systemen als VSS, CVS, SVN en anderen zetten ontwikkelaars op het verkeerde spoor. Daarnaast zorgt het voor minder kritieke massa bij de DVCS-en.

Op korte termijn snap ik dat de meeste mensen bij het "oude vertrouwde" blijven. Op langere termijn denk ik dat iedereen de vruchten plukt van een DVCS.

[elmuerte]

Wat een onzin. Er zijn veel dingen mis met CVS en SVN. Maar er zijn ook veel dingen mis met GIT, HG, BZR. (En er zijn ook veel dingen mis met P4)

Maar je hoeft mij woord niet te vertrouwen, Benjamin Pollack heeft duidelijk artikel geschreven over problemen van DVCS: http://bitquabit.com/post...vcs-and-return-to-sanity/

[Ruudjah]

Er zijn veel dingen mis met CVS en SVN. Maar er zijn ook veel dingen mis met GIT, HG, BZR. (En er zijn ook veel dingen mis met P4)

Klopt helemaal . Het essentiële verschil zit'm erin dat de verschillen tussen een DVCS en CVCS fundamenteel zijn. Bijvoorbeeld: SVN heeft geen officiële notie van een lokale branch. Terwijl een developer altijd een eigen versie lokaal heeft. Dit niet ondersteunen zorgt voor hele rare conceptuele problemen. Deze uitten zich vervolgens in praktische zoals inconsistente werkprocessen, gebruiksinterfaces en API's.

Het artikel van Benjamin Pollack moet goed worden gelezen als je de geest ervan wil snappen. Hij beargumenteerd niet dat SVN nou zo fantastisch is. Benjamin geeft aan dat DVCS-en de meeste problemen goed oplossen, maar dat er nog een paar lastige overblijven.

Zijn eindquote

Long live the centralized SCM.

is vooral sarcastisch bedoeld.

En ik ben het volledig met zijn messcherpe analyse eens. Dat is dan ook precies de reden waarom het zonde is dat mensen nog met/aan CVS, VSS en SVN werken: Als ze aan git, mercurial, Bazaar of Perforce zouden werken worden die problemen sneller opgelost.

[CyBeR]

http://beanstalkapp.com.

Maar waarom je vandaag de dag nog met svn zou willen werken is iets wat me compleet ontgaat.

[drZymo]

GitHub ondersteunt ook gewoon SVN clients (zie https://help.github.com/a...t-for-subversion-clients/). Je hebt dan wel een Git repository, maar je kan hem gewoon benaderen alsof het een SVN repository is.

[bbr]

Heb jaren met svn en ook cvs gewerkt,. het is even wennen maar Git werkt - icm smartgit echt geniaal veel beter. Aanrader om het gewoon eens te proberen

[RoestVrijStaal]

Another one bites the dust.

Jammer. Nu blijven er steeds minder sourcecodehosters over. Een niet al te beste ontwikkeling imho.

De twee bekenste ervan (SourceForge en GitHub) zitten in de USA en we hebben gezien watvoor nadeling effect dat kan hebben op open source projecten: nieuws: GitHub haalt repository Popcorn Time offline na takedown-verzoek Hollywood nieuws: Copyrightwaakhond laat XBMC-add-on SportsDevil van GitHub verwijderen nieuws: GitHub censureert content om blokkade in Rusland te stoppen

Vorige week ontving ik nog in een mail van GitLab dat het Gitorious heeft overgenomen en dat het de bedoeling is dat alle projecten van Gitorious migreren naar GitLab.

Het gaat hard

[Jaap-Jan]

Je bent je ervan bewust dat GitLab van oorsprong een Nederlands bedrijf is? Het bedrijf wat de hosting verzorgt heet GitLab B.V.

[Reactie gewijzigd door Jaap-Jan op 22 juli 2024 15:47]

[RoestVrijStaal]

GitLab is nu nog wel Nederlands, straks niet meer lijkt het erop.
De data van huidige repositories zijn al naar Amazon's AWS verhuisd.

[kimborntobewild]

De twee bekenste ervan (SourceForge en GitHub) zitten in de USA en we hebben gezien watvoor nadeling effect dat kan hebben op open source projecten

Google zit ook in de USA, dus als dat 't argument is, is er geen gemis...

[onok]

Iets als Gitlab kun je echter prima zelf opzetten, en is gewoon gratis! Op je eigen server, in je eigen Nederlandse cloud. Er zijn genoeg mogelijkheiden, niet meteen zo paniekerig gaan doen

[Grauw]

BitBucket is ook een goede (en bekende) code hoster. Ondersteunt zowel git als Mercurial, dus als je niet wil dat Google voor jou even beslist dat je maar git moet gaan gebruiken ipv Mercurial... That’s the place to be.

[g4wx3]

Dit is wel erg,

Dat ze het op read only zetten ok, maar doe het niet weg?
Ze hebben toch plaats genoeg?? Dat ze wat domme youtube-filmpjes weg indien ze plaats tekort hebben.

Er zijn dode projecten, die wel intressant zijn, wie gaat die overzetten?
Ik zal alvast zelf een backup gaan nemen van een paar projecten.
Voor de rest hoop ik dat de internet-archive zich erover kan buigen?

[jvnknvlgl]

Google Code gaat niet op read-only omdat ze te weinig ruimte hebben. Het gaat op read-only om de overstapperiode zo soepel mogelijk te maken. De code die er op staat blijft zo net iets langer beschikbaar, zodat iedereen tijd genoeg heeft alles over te hevelen naar een andere dienst.

[Verwijderd]

Alle projecten op code.google.com zijn per definitie open source dus als je je geroepen voelt om een dood project te migreren naar github...

[Verwijderd]

Inderdaad, denk dat het Internet Archive hier echt op moet duiken, Google Code is de laatste jaren dan misschien steeds minder 'bekend' geworden, maar in mijn ervaring staan er wel vaak de beste projecten/source codes, tegenover een enorme berg aan willekeurige kleine dingetjes op github.

[Joostlek]

En daar gaat nog een briljant idee waar Google als eerste mee was en nooit onder de aandacht heeft gebracht. Net zoals Helpouts (nieuws: Google sluit Helpouts-dienst op 20 april). Dit is gewoon een goed en revolutionair idee, Google had het voordeel om zo'n dienst als eerste op te zetten en het groot te maken. Ik vraag me af waarom ze dat doen, kansen laten lopen, waar ze nog groter mee kunnen worden...

[David Mulder]

Hoezo eerste? De eerste die het gratis aanbod was toch aardig zeker Sourceforge hoor en die is 7 jaar ouder dan Google Code.

[Joostlek]

De zoekgigant riep Code in 2006 in het leven, naar eigen zeggen omdat er toen beperkte keus was voor ontwikkelaars die hun code wilden uploaden, bijvoorbeeld om in teamverband samen te werken. Inmiddels zijn er betere alternatieven, zoals GitHub en Bitbucket, en is Google Code dus niet meer nodig, stelt de zoekgigant. De sourcecodehosting-site zal daarom zijn deuren sluiten.

Ik doel een beetje op dit

[David Mulder]

Je punt zijnde? Zoals ik al aangaf in m'n comment wat SourceForge er echt al 7 jaar eerder, net nog eens dubbel gechecked. Zoals je eigen quote al aanhaalt was er beperkte keuze (er was dus wel keuze), dus die spreekt ook je eigen punt alleen tegen ;-) .

[Reactie gewijzigd door David Mulder op 22 juli 2024 15:47]

[Megamind]

Dat jij het een revolutionair idee vindt maakt het dat nog niet. Ik vond het zelf niks bijzonders en een marktplaats voor spam en troep

[Yzord]

Simpel, kosten baten plaatje. Er zijn inmiddels zoveel alternatieven dat er nu is overwogen of het financieel aantrekkelijk is om de servers up te houden. Nu zal het voor Google niet zo'n probleem zijn om die dingen up te houden qua kosten, maar het onderhoud zal wel de nodige mankracht nodig hebben en doe zijn niet goedkoop ☺

[Verwijderd]

En waarom dan ook de read only killen?

[Coffee]

Omdat, geloof het of niet, read only ook man kracht kost.

[kimborntobewild]

'Alles' kost mankracht, maar 't beschikbaar stellen (en houden) van wat bestandjes... dat stelt niks voor. Maak er een open GoogleDocs gebruiker van; klaar. Verder geen omkijken meer naar. Of een torrentje.

[_David_]

Wat wel vreemd is dat er totaal niks gezegd wordt over de issue tracker van Google Code, Google gebruikt die o.a voor Android (https://code.google.com/p/android/issues/list).

Ben benieuwd wat daar mee gaat gebeuren?

[Antrax]

Waarschijnlijk gaan ze dat ook verhuizen naar Github.

[Murfy]

"Google will continue to provide Git and Gerrit hosting for certain projects like Android and Chrome. We will also continue maintaining our mirrors of projects like Eclipse, kernel.org and others."
Vermoedelijk gebruiken ze het verder voor hun eigen zooi?

[NC83]

Kan google niet gewoon eens een keer een dienst open houden. Zodra iemand het beter doet sluiten die hap, ipv beter maken zodat je mee kunt concureren daardoor worden tenminste beide diensten beter.

[Reactie gewijzigd door NC83 op 22 juli 2024 15:47]

[David Mulder]

Soms beslis je te concurreren en soms is dat het simpelweg niet waard. Vergeet niet dat Google code echt één van die diensten was die Google niet deed om het geld (zover ik weet hebben ze er geen cent aan verdiend, stonden zelfs geen ads op de sites). Dit was gewoon iets wat Google voor de open source community deed waar ze toch wel sterk ook deel van uitmaken. Nu Github het beter doet en ook een business model heeft begrijp ik zeker in deze dat ze het sluiten. Alleen jammer dat ze het niet voor lange tijd read only houden.

[Reactie gewijzigd door David Mulder op 22 juli 2024 15:47]

[kimborntobewild]

stonden zelfs geen ads op de sites

Droevige constatering dat hier 't woordje 'zelfs' gebruikt wordt / kan worden.
Geeft aan hoe overdreven vercommercialiseerd internet is.

[David Mulder]

Was inderdaad te verwachten, op zich wel jammer, want toen het gelaunched werd was het echt de beste keuze en was volgens mij de grootste competitie sourceforge (dat waren de twee die ik toen overwoog, maar dat was alleen als zomaar student nog maar). Nu zie je bijna alle projecten van Google ook gewoon op GitHub, dus ik was al aan het wachten totdat ze Code zouden sluiten. Had verwacht dat hij nog wat langer op read only zou blijven staan, maar goed, prima zaak op zich, al had ik er ook niks op tegen gehad als ze een nieuwe versie hadden gemaakt met het doel met Github direct te competeren.

[space_octopus]

Ik ga Google Code wel missen. Ik vond het erg handig!

[rubenvb]

Ik heb Google code altijd ver ondermaats gevonden: navigatie was brak, servers waren werkelijk trager, en tja, er zijn zoveel alternatieven die alles net dat tikkeltje beter wisten te brengen (github, atlassian, gitorious, zelfs sourceforge).

Good riddance! Dat ze het maar begraven in een diepe put.

[jj71]

Ik vind Github ontzettend handig, ik heb er zelf ook een aantal hobby-projectjes op staan.

Google heeft zijn eigen projecten allang naar Github verplaatst: https://github.com/google (tsjonge wat een lange lijst van projecten!).