11 ms·
Did I read that correctly, they were on Subversion before this?
by cptskippy 6y ago
Did I read that correctly, they were on Subversion before this?
- quantummkv 6y agoOnly the translation communities, according to the article. But I wouldn't be surprised if more of the repositories were on subversion. There was no git in the 90's when KDE started
- lbeltrame 6y agoOnly the translation teams use SVN (and perhaps some very old websites, but I think most if not all of them have been moved to git). All the code lives on git, instead.
- wheels 6y ago> There was no git in the 90's when KDE started There was no Subversion when KDE started. Like most projects of its era, KDE started with CVS, and moved to Subversion in 2005.
- sho_hn 6y agoIn fact, I recall we had to contribute code to SVN to make it scale to our existing monorepo size :-)
- ognarb 6y agoThere is still some websites on SVN but I started moving them to git. The only one missing are the one from unmaintained project that I should import in git and then archive.
- ahartmetz 6y agoIt was Subversion until 2010 or so. After that, Git with... I think Reviewboard (and various other tools), then Phabricator, soon (and some parts already) GitLab.
- deleted 6y ago[deleted]
- sho_hn 6y agoWe started seriously looking into git in 2007/2008, then launched git.kde.org in 2010. We had set ourselves the goal to lose zero history, and doing a perfect import while transitioning from a monorepo (with lots of interesting code movement within the hierarchy) to hundreds of individual repositories was quite challenging back then! We had to invent some of the tooling (svn2git) along the way.
- lima 6y agoAre you still happy with your choice to migrate away from a monorepo?
- sho_hn 6y agoWe're pretty confident it had a positive impact overall. Our repo boundaries match our source archive release deliverables (source tarballs) since the switch. The consistent chunking, also in the build system (i.e. components finding each other during build - before mostly packagers were exposed to this, post-switch every dev is implicitly), helped us along in splitting/modularizing/tiering especially our libraries. It's made us more conscious of dependencies and made it easier to swap things out to rejuvenate. The community has seen some challenges with drifting apart along the way (projects isolating vs. working on common themes/initiatives), but I think this was more a side effect of overall growth than just the repo reorg. We've also since combatted it with the very successful community-wide KDE Goals election process. We've stuck to the same ACL approach throughout, notably - you gain KDE dev rights through a peer-support process based in merit, and once you have them you can push to any repo. We mandate code review through strongly enforced social etiquette, not by ACLs.