Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Software-update: Subversion 1.7.0

De Apache Software Foundation heeft enkele dagen geleden de final release van Subversion-versie 1.7.0 uitgebracht. Subversion is een programma voor software- en projectontwikkelaars waarmee beheer en versiecontrole van software en broncode kan worden uitgevoerd. Het programma moet worden gezien als een directe concurrent van CVS. Versie 1.7.0 bevat een groot aantal nieuwe features, verbeteringen en bugfixes. De complete lijst kan hieronder worden gevonden.

User-visible changes:

  • No longer including contrib/ in the release tarballs (r877798)
Major new features:
  • Less verbose HTTP-based repository access protocol (issue #1161, #3371)
  • Rewritten working copy metadata storage (issue #3357)
  • New 'svn patch' subcommand (issue #511)
  • Rewritten FSFS in-memory caching for better performance
  • New remote repository dump/load client 'svnrdump'
Minor new features and improvements:
  • Better handling of HTTP redirects (issue #2779)
  • Improved and much more consistent path handling (issue #2028, and others)
  • 'svnadmin load' rewrites changed revnums in mergeinfo (issue #3020)
  • Error message and help text improvements
  • 'svn log' can print unidiff of changes made in a revision (issue #2909)
  • 'svn diff' can print git-style unidiff annotations
  • svnsync can now steal locks on a mirror repository (issue #3309)
  • display the wc root in the output of 'svn info' (issue #3355)
  • add 'svnlook filesize' (issue #3509)
  • add 'svn upgrade' command for upgrading working copies (r877675)
  • add 'svnsync --disable-locking' (issue #3545)
  • subtree merges don't unconditionally stop reintegrate merge (issue #3577)
  • 'svn relocate' replaces 'svn switch --relocate' (r1026475)
  • 'svn relocate' updates relative externals (issue #3597)
  • allow svnsync users to specify the source repo (issue #3637)
  • remove redundant mergeinfo notifications for 2-URL merges (issue #3671)
  • 'svn export' into the current directory (issue #3727)
  • added '--parents' to 'svn update' (issue #3748)
  • allow configurable connection timeout in ra_serf (r876161)
  • add digest authentication in ra_serf (r876405)
  • add extensive caching support to servers (r1067669, -75, -72302)
  • add configurable caching to svnadmin (r1078357)
  • make server-side network data compression rate configurable (r1072288)
  • added support for auto-detecting mime-types with libmagic (r1131120)
  • 'svn rm url1 url2 url3' uses single txn per repo (issue #1199)
  • don't leave unversioned files when reverting copies (issue #3101)
Client-side bugfixes:
  • 'svn cp A B; svn mv B C' is equivalent to 'svn cp A C' (issue #756)
  • revert fetches missing directories from the server (issue #1040)
  • allow subdirs of moved dirs to be moved and committed (issue #1259)
  • improved performance of 'svn mv' with whole directories (issue #1284)
  • 'svn rm B; svn cp A B' now works (issue #1516)
  • 'svn diff URL1 URL2' now reverse of 'svn diff URL2 URL1' (issue #2333)
  • error if relocating to an unused URL (issue #2531)
  • 'svn blame -rWORKING' is now supported (issue #2544)
  • improve correctness of commit on a relocated wc over ra_dav (issue #2578)
  • add early error to 'svn add --auto-props' with mixed eols (issue #2713)
  • allow 'svn diff' to accept symlinks as targets (issue #2716)
  • don't lose props for replaced items (issue #2743)
  • handle mergeinfo for subtrees removed outside of svn (issue #2915)
  • add ability to force 'svn diff' to use internal diff (issue #3701)
  • correctly recover a schedule-for-delete rm'd outside of svn (issue #3106)
  • don't create self-referential mergeinfo from own history (issue #3157)
  • improve 'svn log -g' handling of bad mergeinfo source paths (issue #3270)
  • better conflict stat printing (issue #3342, issue #3594)
  • 'svn update' restores excluded files (issue #3544)
  • allow reintegrate merges into WCs with missing subtrees (issue #3603)
  • more gracefully error when given back cmdline input (issue #3620)
  • update exit codes to reflect command failure (issue #3622)
  • don't double-update file externals (issue #3665)
  • improve output of multi-target update (issue #3693, #3746)
  • make 'svn up --set-depth=exclude FILE' work (issue #3736)
  • return correct error code for 'svn cat' on nonexisting file (issue #3713)
  • support svn:externals on locally added directories (issue #2267)
  • use installed GSSAPI lib for Kerberos in ra_serf (r877381)
  • allow 'svn info' to run on an excluded item (issue #3792)
  • improve 'log -g' output with reverse merges (issue #3176)
  • don't print error message if stdout is a pipe and is closed (issue #3014)
  • removed special copy-handling during updates added in 1.5.0 (issue #3711)
  • fix warning about copies committed with non-infinity depth (issue #3752)
  • can now commit multiple wc paths lacking a common parent (issue #2381)
  • 'svn export --depth $WC' now works correctly (issue #3800)
  • added support for case-only renames on Windows (issue #3702)
  • 'svn delete --force' removes tree conflicts (issue #3805)
  • don't throw an error when skipping tree conflicts in update (issue #3329)
  • don't break commits of wc->wc copies with file externals (issue #3589)
  • allow 'svn info' to work on symlinks to working copies (issue #2305)
  • allow 'svn st --show-updates' to work across symlinks (issue #3117)
  • 'svn revert' shouldn't loop on symlinks (issue #3972)
  • fixed: wc-to-wc copy of a switch source (issue #1802)
  • fixed: 'svn st' reports symlinks as obstructed items (issue #2284)
  • fixed: 'cd e:\; svn up e:\' fails (issue #2556)
  • fixed: svn aborts on commiting from root dir on windows (issue #3346)
  • fixed: removing a dir scheduled for deletion corrupts wc (issue #2741)
  • fixed: 'svn cleanup' fails on obstructed paths (issue #2867)
  • fixed: case-only renames resulting from merges don't work (issue #3115)
  • fixed: 'svn mergeinfo' ignores peg rev for wc target (issue #3180)
  • fixed: unable to merge to wc of deleted branch (issue #3221)
  • fixed: move via merge leaves behind versioned move source (issue #3324)
  • fixed: ra_serf does not honor http-proxy-exceptions (issue #3428)
  • fixed: 'svn mv A B; svn mv B A' loses history (issue #3429)
  • fixed: ra_serf doesn't support http-auth-types config (issue #3435)
  • fixed: merge sets incorrect mergeinfo on skipped paths (issue #3440)
  • fixed: ra_serf inconsistent handling of cached authn creds (issue #3450)
  • fixed: ra_serf sefault with using NTLM or Negotiate auth (r876910)
  • fixed: excluded subtrees are not detected by svnversion (issue #3461)
  • fixed: submitting a changelist while obstructed item exists (issue #3484)
  • fixed: crash when changing an external's URL (issue #3530)
  • fixed: target moved after branching breaks reintegrate (issue #3640)
  • fixed: potential race condition in svnsync (issue #3546)
  • fixed: spurious merge conflicts with pre-1.7 mod_dav_svn (issue #3657)
  • fixed: repeat merge is not a no-op (issue #3564)
  • fixed: inheritance results in self-referential mergeinfo (issue #3668)
  • fixed: inheritance results in nonexistent mergeinfo sources (issue #3669)
  • fixed: memory leaks in ra_serf (issue #3684)
  • fixed: corruption of 'svn pg' output for large properties (issue #3721)
  • fixed: 'svnsync copy-revprops' doesn't sync revprop dels (issue #3728)
  • fixed: executable flag not correctly set on merge (issue #3686)
  • fixed: 'svn rm' fails on multiple URLs with encoded spaces (issue #3839)
  • fixed: children of replaced dirs cannot be deleted (issue #3468)
  • fixed: executable flag of binary file lost during merge (issue #3686)
  • fixed: merging a symlink-turned-regular-file breaks the wc (issue #2530)
  • fixed: can't remove file externals (issue #3351)
  • fixed: 'svn unlock' attempts to unlock wrong token on DAV (issue #3794)
  • fixed: forced DAV 'svn unlock' results in 403, not warning (issue #3801)
  • fixed: rm -> ci -> cp = missing directory (issue #2763)
  • fixed: 'svn info' returns parent info on missing dirs (issue #3178)
  • fixed: spurious prop conflict with 'merge --reintegrate' (issue #3919)
  • fixed: 'svn --version' fails with non-existant $HOME (issue #3947)
  • fixed: unforced export silently overwites existing file (issue #3799)
  • fixed: reverse merge which adds subtree mergeinfo fails (issue #3978)
  • fixed: 'svn up -r{R>HEAD}' hangs client over ra_svn (issue #3963)
  • fixed: 'svn up' updates file externals in target siblings (issue #3819)
  • many other minor bugfixes, optimizations, plugs of memory leaks, etc
Server-side bugfixes:
  • mod_dav_svn is less strict about auto-merging for commits (issue #1704)
  • allow SVNListParentPath to be used with authz (issue #2753)
  • allow nav to repo list from repo top with SVNListParentPath (issue #3159)
  • allow repositories in the root of a drive on windows (issue #3535)
  • don't destroy mergeinfo with 'svnadmin load --parent-dir' (issue #3547)
  • fixed: 'svnadmin hotcopy' does not duplicate symlinks (issue #2591)
  • fixed: post-revprop-change errors cancel commit (issue #2990)
  • fixed: mod_dav_svn runs pre-revprop-change hook twice (issue #3085)
  • fixed: mod_dav_svn doesn't return stderr to user on failure (issue #3112)
  • fixed: hotcopy may corrupt target rep-cache.db (issue #3596)
  • fixed: mod_dav_svn can cause spurious merge conflicts (issue #3657)
  • fixed: DAV can overwrite directories during copy (issue #3314)
  • fixed: 'svn log' returns log of unrelated path (issue #3931)
  • match paths against authz rules in case sensitive way (issue #3781)
  • svnserve can now force usernames to upper/lower case (issue #3726)
  • reduce duplicate log messages in 'log -g' (issue #3650)
  • svnserve: don't crash on shutdown with SASL in inetd mode (issue #3664)
  • disallow arbitrary HTTP headers from committers (issue #2872)
  • limit FSFS memory consumption (issue #3478, #3593)
  • many other minor bugfixes too numerous to list here
Other tool improvements and bugfixes:
  • svnsync now takes the '--config-option' argument (issue #2027)
  • svnsync can translate non-UTF-8 properties to UTF-8 (issue #3817)
  • svnadmin now errors on non-UTF-8 revision properties (issue #3755)
  • svnadmin verify now errors on non-UTF-8 paths (r1129641)

Developer-visible changes:

  • improved output of 'make check'
  • introduce scratch_pool/result_pool parameter paradigm
  • improved error tracing (r877208, -736)
  • improve building with sqlite on Windows (issue #3364)
  • allow mod_dav_svn to compile against Apache 2.4 (issue #3548)
  • support running tests against older servers (r876016)
  • notification of unversioned obstructions (r877344)
  • removed virtually all abort() calls (issue #2780)
  • don't include client-specific suggestions in error msgs (issue #3887)
API changes:
  • don't crash svn_client_copy if ctx->log_msg_func is NULL (issue #3234)
  • much improved ra_serf error handling (issue #3375)
  • provide clients with old and new revision on update (r876515)
  • close both files, even on error in svn_stream_copy3() (r887262)
  • added 'work-in-progress' XFail test status (r876549)
  • notifications sent when mergeinfo changes (r877588)
  • add information on text and property mods in log APIs (r877688)
  • fixed: svn_ra_local__get_file() leaks file descriptors (issue #3290)
  • svn_ra_neon__get_dir() returns correct dir set for URLs (issue #3093)
  • swig-py: always set ChangedPath.path (also for deletes) (issue #2630)
  • improve conflict resolver API for a specific direction (issue #3049)
  • New JavaHL package: org.apache.subversion
  • Deprecate the SVNClientSynchronized class in JavaHL (issue #2755)
  • fixed setting binary properties in JavaHL (issue #3770)
  • fix type mapping of svn_txdelta_window_t in python bindings (issue #3688)

De volgende downloads zijn beschikbaar:

Subversion logo
Versienummer 1.7.0
Releasestatus Final
Besturingssystemen Windows 7, Windows 2000, Linux, BSD, Windows XP, macOS, Solaris, UNIX, Windows Server 2003, Windows Vista, Windows Server 2008
Website Apache Software Foundation
Bestandsgrootte 7,19MB
Licentietype Voorwaarden (GNU/BSD/etc.)

Door Bart van Klaveren

Downloads en Best Buy Guide

14-10-2011 • 13:17

21 Linkedin Google+

Submitter: apokalypse

Bron: Apache Software Foundation

Reacties (21)

Wijzig sortering
Een first post met "svn < git" is nogal waardeloos.

Ik vind het eigenlijk wel jammer dat velen zo schaapachtig achter distributed version control systemen zoals Git aanlopen. Het lijkt vaak alsof men meer de mode volgt dan een goede afweging te maken op basis van benodigde features.

Voor veel ontwikkelteams is het centralized model van SVN nog steeds geschikter dan distributed, net zoals de goede beschikbaarheid van GUI's op Windows, of de mogelijkheid bestanden te 'locken'. Ook de repo-architectuur van Subversion heeft vaak voordelen, zoals meerdere projecten in één repo kunnen plaatsen, rechten kunnen toekennen op paden in de rep, etc.

Git's pluspunten worden naar mijn mening overschaduwd door de ontzettend slechte user interface; iets dat door veel gebruikers erkend wordt. Net alsof deze door een Linux kernel-developer bedacht is ;) Ik zou willen dat de developers het lef hadden om een redesign van hun CLI front-end te doen. Dan was Git niet alleen een snel en krachtig versiebeheer systeem, maar ook nog eens een plezier om te leren en te gebruiken. Mercurial heeft op het gebied van user interface nog een voorsprong t.o.v. Git. Het is simpeler te bedienen en te leren, maar mist verder ook de tooling/intergatie die Subversion wél heeft.

Verder missen veel bedrijven goede in-house repository-servers voor distributed systemen. GitHub en Bitbucket zijn fantastische tools voor teams die inderdaad geografisch 'distributed' zijn, maar lang niet alle bedrijven zijn bereid hun broncode off-site te hosten. Zolang er geen self-hosted servers te krijgen zijn met vergelijkbaar gebruiksgemak en features denk ik dat centralized systemen nog populair blijven. Hopelijk kunnen de developers van distributed systemen hun hype waarmaken en hebben we straks allemaal snelle, met makkelijke interfaces en eenvoudige branching/merging.
Schaapachtig? Neuh. Ik heb een tijd lang met SVN gewerkt, maar sinds Mercurial ook fatsoenlijke Windows-tools heeft (TortoiseHg) geef ik toch ook voor mijn eigen projectjes waar ik de enige developer ben de voorkeur aan Mercurial boven SVN. Ik heb veel minder ruzie met Mercurial dan met SVN.

Je hebt het over beter tooling en integratie voor SVN... maar wat dan? Mercurial heeft al vele extensies en is relatief eenvoudig in Python aan te passen en te hooken. Tool-support voor Mercurial doet voor mijn gebruik ook niet meer onder tov SVN: m'n IDE, Netbeans, support Mercurial semi-out of the box, net als SVN.
Ook de repo-architectuur van Subversion heeft vaak voordelen, zoals meerdere projecten in één repo kunnen plaatsen
Je kunt je afvragen of dat een voordeel is.
Git's pluspunten worden naar mijn mening overschaduwd door de ontzettend slechte user interface
UI? UI's zijn voor n00bs, commandline FTW! :p.

Nee, maar ik begrijp wat je bedoelt. Het standaard gitk is idd lelijk. Voor Gnome heb je gitg, dat op QT gebouwd is en iets mooier is. Voor Mac heb je nog Tower en nog zoiets, maar da's ook niet geweldig.

Een hele goeie vind ik GitHub for Mac, die veel complexiteit van Git verbergt achter een eenvoudige, overzichtelijke UI (en natuurlijk koppeling met GitHub). Je moet helaas nog wel eens de commandline induiken hiermee, aangezien het niet altijd even goed omgaat met conflicten resolven.
Verder missen veel bedrijven goede in-house repository-servers voor distributed systemen.
Een wat? Klinkt als iets enterprisey, en da's voor Git niet nodig. Gewoon een linuxbak (evt met backups), repo erop zetten, git remote add bij je clients en klaar.
in-house repository-servers moeilijk spannend? Man, dat is toch niet zo spannend... Niks ingewikkelders dan cvs.
Heel logisch dat je als bedrijf je projecten niet ergens op het internet wil hosten, dus lekker intern op een server net als cvs.

Dit zijn voor ons de redenen om git te gebruiken:
  • Snel! (linux kernel checkout/clone van onze server is bijna even snel als een kernel.tar.bz2 uitpakken, dat lukt no way met cvs).
  • Geen .CVS dirs in *alle* subdirectories, moet je eens een recursive diff proberen te doen
  • Makkelijk te beheren&backuppen.
Laat ik het zo zeggen: Ik ken talloze voorbeelden van mensen die van SVN naar Git overstapten, maar geen enkele die van Git (of een ander DVCS) terugging naar SVN.

Dat Git gedecentraliseerd werkt wil niet zeggen dat je binnen je organisatie niet een centrale repository kunt hebben. Deze is met een git init --bare zo opgezet, daarna mis je niets wat een centraal SVN repository wel hebt (maar heb je wel de voordelen van Git). Met een tool als gitosis/gitolite kun je ook eenvoudig de toegang tot op brancheniveau regelen op basis van de SSH keys van je gebruikers.

Dat het frontend aanbod voor Git niet zo goed is ben ik met je eens, maar SVN doet het out-of-the-box niet veel beter. Bedrijven die kicken op grafische snufjes kunnen beter een draak van een product als Perforce aanschaffen lijkt me.
GIT is een Distributed Version Control System en Subversion is een Centralized Version Control System.

Simpel gezegd, bij Subversion haal je een moment opname van de code op de centrale server binnen (checkout van een revisie).

Bij GIT heb je zelf een volledige copy van de hele repository inclusief branches, tags en history.

Daarnaast is GIT loei snel en is branching en merging eenvoudiger dan met een revisie based SCM als Subversion.

Speel eens met beide om het te ervaren.

Leuke presentatie over GIT:
Héél kort gezegd:
distributed (git (bazaar, mercurial, monotone)) -vs- centralized (svn (cvs, perforce))

Dit verschil in architectuur speelde een grote rol in de hack van, omdat er geen officiele centrale linux kernel repository bestaat. Als je er wat uitgebreider op in wilt gaan, wat het zeker wel verdiend:

Google Tech Talk: Linus Torvalds on git

Ten gevolge van distributed vs centralized zijn er heel wat voordelen, waaronder het belachelijk veel makkelijker werken met branches, géén gedoe over commit access en meer dingen, zie het filmpje.

[Reactie gewijzigd door afraca op 14 oktober 2011 15:54]

Grappige video, maar het leert je wel heel weinig over Git, of over distributed vs. centralized. Het komt op mij meer over als een vermakelijk uurtje 'ranten' van Linus.
Het is inderdaad redelijk wat ranten, maar later in de talk beantwoord hij wat vragen met iets meer technische onderbouwing, desalniettemin blijft het redelijk oppervlakkig, toch zegt hij nog aardig wat over de architectuur van Git
Ik ben heel blij met deze update. Met name:
  • Less verbose HTTP-based repository access protocol (issue #1161, #3371)
  • Rewritten working copy metadata storage (issue #3357)
Dat zou voor heel wat betere performance en minder I/O moeten zorgen. Hopelijk komt dat de snelheid te goede.

Verder een boel goede bugfixen en minor features. Men luistert dus wel naar hun gebruikers. Hopelijk komen er snel officiële backport packages voor Ubuntu 10.04LTS beschikbaar, zodat we onze servers kunnen upgraden.
svn < git

wat ben ik blij dat ik van svn af ben zeg :)
Dat begrijp ik niet want subversion doet prima wat het moet doen. Wat is er dan zo vervelend aan subversion?
heb je weleens met meer dan 5 mensen samen gewerkt? En ook alle 5 verschillende branches etc?

edit: mijn mening ;)

1.met git is het SUPER makkelijk om te branchen/reverten en te mergen.
2. je hebt niet van iedereen alle branches online staan terwijl ze makkelijk offline kunnen.
3. svn is langzaam en git is snel. Dit heeft te maken dat git alles offline doet ipv online. Een nieuwe branch maken doe je bijvoorbeeld in 0.0001 seconden, want hij maakt alleen een soort pointer naar een branch. (weet zelf niet precies)
4. Het werkt ook als je geen internet hebt.
5. pull requests
6. Stuk minder rare conflicten.... voel nog mijn hoofdpijn na al de svn conflicten bij het mergen van branches etc.

en kan nog wel doorgaan :)

[Reactie gewijzigd door mokkol op 14 oktober 2011 18:16]

Dat is jou kant....

SVN is bij mij nooit langzaam... misschien toch eens naar je SVN server kijken ;) Rare conflicten heb ik ook bij git dus dat ligt meer aan de mensen en de manier waarop je het gebruikt denk ik ;)
het is wel langzaam. Ga maar eens een branch maken. en daarna met git. git -> 0.0001 seconden. Probeer dat maar eens met svn te halen. langzaam is misschien relatief, maar vergeleken met git is het wel langzaam

Je moet alles over internet doen dus zulke dingen zijn ALTIJD een stuk langzamer.

Met conflicten doelde ik meer op dingen zoals directory cleanen etc. Dat moest ik vaak doen bij svn.... en had vaak problemen daarmee. Ik doel niet op conflicten van source code, die je daarna even moet verbeteren en opnieuw moet commiten. Die zal elk systeem hebben.

Owja nog een groot voordeel vind ik. De versie nummers zijn hash codes ipv integers. Een commit heeft altijd een parent, Daarom hoef je dus niet een merge als een commit te zien die de hele structuur daarna omzeep helpt maar gewoon lekker zijn versie nummer behoud. Zo kan je dus ook makkelijk een single commit van andere branches mergen ipv een gehele branch. cherry-pick heet dat.

[Reactie gewijzigd door mokkol op 14 oktober 2011 18:24]

Niks, totdat je normaal met branches of andere mensen wilt gaan werken (jwz, zoals het hoort).
Ik kan dit ook zelf opzoeken natuurlijk, maar kan iemand mij heel kort vertellen wat het verschil is tussen SVN en GiT? En hoe werkt GiT?
Vergeet ook Mercurial niet; een interessante concurrent van Git. Het is niet zo populair als Git, maar is gebruiksvriendelijker en daardoor makkelijker te leren.

Een duidelijke high-level uitleg van het verschil tussen centralized version control (bijv. SVN) en distributed version control (bijv. Git, Mercurial, Bazaar) is:
Geen kant en klare installatiefile beschikbaar voor Subversion 1.7.0

Ik heb het gedownload en de installatie instructies bekeken, maar ben er niet nog niet in geslaagd hiermee het te installeren onder windows. In de tussentijd heb ik wel al 5 andere programma's gedownload en geinstalleerd, maar deze subversion 1.7.0 lukte dus niet zo een twee drie. Dat is een heel project om dat geinstalleerd te krijgen.

De rechtstreekse mogelijkheid om een standaard windows setup.exe programma uit te voeren was niet beschikbaar voor subversion 1.7.0 daar.

Ik citeer uit de installatieinstructies voor windows:
"Download a Zip (*.zip) or self-extracting installer (*-setup.exe) file from: http://subversion.tigris....tDocumentList?folderID=91

Als ik die site dan bezoek zijn er daar alleen oudere versies beschikbaar van subversion (1.6.x is het laatste die ze daar hebben staan)
Ik had toch 1.7.0 geclickt en gedownload om op mijn systeem te installeren.

De sources waren echter wel beschikbaar na de download van 1.7.0, en er staan ook wat vage aanwijzingen hoe je dat dan op windows geinstalleerd zou kunnen krijgen.

Om dat te doen moet je allerlei software in huis hebben die de meeste mensen niet hebben, en zelfs als je dat hebt kost het nog veel tijd om uit te zoeken hoe je zo'n programma met sourcecode voor linux in visual studio moet inladen en compileren.

Het stond ook niet in de instructies, er stond alleen welke software daarvoor nodig was, maar niet hoe dat dan ging. Ik moet nog zien of die van linux geporte code inderdaad vanuit Visual studio te compileren is, zonder foutmeldingen na het volgen van de bijgeleverde instructies.

Op dit item kan niet meer gereageerd worden.

OnePlus 7 Pro (8GB intern) Microsoft Xbox One S All-Digital Edition LG OLED C9 Google Pixel 3a XL FIFA 19 Samsung Galaxy S10 Sony PlayStation 5 E3 2019

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank, Intermediair en Independer de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2019 Hosting door True