Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
KDE GUI Programming IT Technology

KDE Switches to Subversion 310

Posted by timothy from the next-generation dept.
Michael Pyne writes "It's official, after weeks of preparation, KDE has completed switching their source control repository from CVS to Subversion. KDE is one of the largest software projects to make the switch, and is the first major desktop environment to do so. Some of the goodies that CVS users are used to are still in the process of being switched over (including WebSVN), but everything seems to be working well so far." (The announcement of early April is no longer the operative statement.)
This discussion has been archived. No new comments can be posted.

KDE Switches to Subversion More

KDE Switches to Subversion

Comments Filter:

  • Obligatory (Score:4, Funny)

    by Anonymous Coward on Wednesday May 04, 2005 @10:42AM (#12431664)
    Kongradulations!

  • I truly wished they have given a different name. (Score:5, Funny)

    by cabazorro ( 601004 ) on Wednesday May 04, 2005 @10:43AM (#12431674) Journal
    My managers simply refuse to use anything proposed by us, the development team, and named subversion.
    • Hey, that's neat, you can use SVN as a pointy-haired-boss detector!

      Sorry about yours, by the way.
    • Then call it SVN, Subversions shorter name.
    • You should just pronounce it like it is hyphenated.

      But, this is the first I am reading of this. Why are they moving from CVS to Subversion? It would seem that if it lacks useful features available in CVS that KDE would stick with CVS.
      • The submitter was complaining that the SVN utilities lack features available in the party CVS utilities; such as SVNweb vs CVSweb.

        He wasn't complaining that SVN itself lacks useful features available in CVS. There are enough improvements (Atomic commits, versioning of directories and permissions) in SVN over CVS that switching to the new system is compelling.

        The utilities don't all need to work now anyways.
        Any sort of large-scale migration like this is done in phases. Phase 1, switch the repository. Phas
    • My managers simply refuse to use anything proposed by us, the development team, and named subversion.

      Good that you mentioned it. for $50k a year, I'm glad to license them my own version control system, "Rule The Developers With an Iron Fist". It's actually just Subversion and Trac in a box with a pretty logo and some marketing collateral. Plus, a guy with a nice suit and good hair will come and spend two hours explaining things to them in short words and bullet points.

      Or they can get the deluxe version for $100k per year, where the guy with good hair will also take them golfing and out to dinner.
      • For shizzle. People are always complaining about "Oh, God, this product has such an awful name, my boss would never use it. I have a million better ideas for names!" But they don't get that, it's open source, so if you want to have a Fork In Name Only, you can go right ahead and do that. Just write a script that will changes all instances of 'Subversion' (or whatever) to 'Project Management Pro Elite'. Piece of cake.
      • It's obvious you have some experience in government or corporate purchasing.

        I'll put in a purchase order for the $1,000,000 version with the $100,000 per year support contract. That's the version where girls with good hair provide on site support.

        • I'll put in a purchase order for the $1,000,000 version with the $100,000 per year support contract. That's the version where girls with good hair provide on site support.

          Then you should certainly consider the $200,000/yr support contract. Then the on-site tech is an experienced fluffer [urbandictionary.com]. Of course, on the paperwork we describe her as a network technician, so that she has a good excuse for spending a lot of time under people's desks straightening their cables.

      • Good that you mentioned it. for $50k a year, I'm glad to license them my own version control system, "Rule The Developers With an Iron Fist". It's actually just Subversion and Trac in a box with a pretty logo and some marketing collateral. Plus, a guy with a nice suit and good hair will come and spend two hours explaining things to them in short words and bullet points.

        Or they can get the deluxe version for $100k per year, where the guy with good hair will also take them golfing and out to dinner.

    • Re:I truly wished they have given a different name (Score:4, Insightful)

      by killjoe ( 766577 ) on Wednesday May 04, 2005 @12:28PM (#12432719)
      " My managers simply refuse to use anything proposed by us, the development team, and named subversion."

      For the umpteenth time people. When you say things like this name your company. We all want to make sure we don't have ny stock in companies with this kind of management.
    • Try calling it SVN, and pronounce it ess-vee-en. If that isn't enough, claim you've got a "demo license" of it, rather than telling them it's open source. Weirdly, most companies I've worked at which had problems with open source had no trouble with developers using demo versions of things indefinitely.
    • Hummmmm. For fun, send them links to Satan.
    • My managers simply refuse to use anything proposed by us, the development team, and named subversion.

      Wow, your managers actually listen to anything your say? Crazy. My manager wouldn't pay attention long enough to actually object.
    • My managers simply refuse to use anything proposed by us, the development team, and named subversion.

      You think that's hard...try and get sign off on something called Double Choco Latte! [sourceforge.net]

      My manager at the time had this comment; "It's a great program, and exactly what we need, though I can't tell anyone about it here -- they'd laugh in my face! I'm just not going to do it!" In order to 'sell' it to other groups, we renamed it to "DCL" and swapped out the default logo. [sourceforge.net] Nobody laughed, though we weren't

  • A much needed switch (Score:5, Insightful)

    by CastrTroy ( 595695 ) on Wednesday May 04, 2005 @10:43AM (#12431679)
    Its nice to see them making the switch. Having used both Subversion and CVS, I have to say that Subversion is much better. I hope more projects continue to do the same. Its amazing that CVS has lasted as long as it has.

    • Re:A much needed switch (Score:2, Informative)

      by Anonymous Coward
      The only downside is that I've had some friends unable to use the WebDAV method PROPFIND because some corporate firewalls have blocked it. Regular GETs will work, but you don't have all the info about the file. And trying to get a big organization's IT dept to change a firewall setting for one project is a huge struggle.

      That and some people use Novell netdrive to access subversion like a regular drive which results in tons of small uncommented commits if they have write permission.
    • Yeah, I'm not a big CVS fan and I'm eager to start using subversion. Unfortunately, SourceForge [sourceforge.net] still doesn't support it so I (and thousands of others) are stuck with CVS for a while. However, they're looking into it. Here's an excert from their site status updates:

      Subversion Service: The research, analysis, and support gear-up needed to implement a Subversion service at SourceForge.net is now in progress. As with all SourceForge.net services, extensive analysis and testing must be performed to verify s

  • Why not everyone likes svn: (Score:5, Informative)

    by Anonymous Coward on Wednesday May 04, 2005 @10:48AM (#12431722)
    Monolithic svn databases are vulnerable to irrecoverable corruption [bris.ac.uk]

    • Re:Why not everyone likes svn: (Score:2, Insightful)

      by Anonymous Coward
      How about you check out the new backend fsfs?

    • Re:Why not everyone likes svn: (Score:5, Informative)

      by DarkDust ( 239124 ) * <marc@darkdust.net> on Wednesday May 04, 2005 @10:57AM (#12431809) Homepage
      If you're scared by the BDB backend then use the FSFS backend which is a filesystem based backend, like CVS uses RCS files.

      We're using SubVersion for over two years now, versioning our in-house Linux distribution with which we're doing our products and we've never had any data loss (though we had some trouble with BDB back in the 0.xx days).
      • BDB, FSFS, CVS, RCS

        Are you deliberately using acronyms, or is this really what you say.. :)

      • Uhhh... (Score:2, Informative)

        by lorcha ( 464930 )
        I am currently examining the FSFS repository that I use for my personal coding. Let me say this: "I defy you to make any sense out of the gibberish that is your FSFS backend."

        If you have a random corruption, I severely doubt you're going to be jumping into the FSFS repository and tweaking it to fix it.

        My solution: rsnapshot [rsnapshot.org]. Because the repository is filesystem-based, all of my backup history combined only takes up the same amount of space as my actual repository (god bless hard links). With BDB, the di

      • Can you just reuse the same RCS (,v) files from your CVS repository with SVN?

        Regarding BDB, yes, I'm scared shitless. My company tried to use it to back an object database system. We had locking problems that forced us to write our own disk-based btrees (specific to our needs).
    • Excellent article with excellent points; On the other hand, if you don't have backups, the same thing could happen with CVS, although the damage footprint would be different. Disk corruption due to bad memory is not uncommon - many people who experience this in Windows simply chalk it up to 'a virus' (even experienced technicians do). If the problem exists for some length of time beyond your last backup, you lose everything modified anyway. In small code trees, it's not a problem, but can you imagine workin
    • This is why subversion has the svn dump command (or was it svnadmin dump or svndump? Well, it doesn't really matter) that you can use to do backups of your repository to _plaintext_ files, just like you would use pg_dump to backup your postgresql database.

      Obviously, if you don't use the feature, it's pretty useless, but, hey, how often has it been pointed out that every serious project that uses computers needs a good backup strategy?
    • Hmmm, an academic who swears in such an article and whose homepage reads as follows: "Welcome, I work at the Department of Computer Science, University of Bristol, were I happen to be a reader."
    • That is why I use CVS to manage my SVN repositories :)
    • This has been posted in the last thread on svn and I don't agree. I've used subversion for more than a year now. I find it to a be a very reliable and easy way to put files under version control.

      The reason cvs fanboys love having textfiles around is that, well, you really need them in the not so unlikely case that cvs messes up. One of the many things that svn fixes is atomic commits. In svn a commit either fully succeeds or fails. In cvs on the other hand it may actually fail halfway and leave the reposit

  • Differences (Score:2, Insightful)

    by ecsdrive ( 869787 )
    What are the most important features that Subversion has and CVS hasn't? It's been a lot of buzz lately behind Subversion, but I didn't figure it out what CVS has that is so wrong/slow/bad for software versioning

    • Re:Differences (Score:4, Informative)

      by dos_dude ( 521098 ) on Wednesday May 04, 2005 @10:54AM (#12431781) Homepage
      Apparently, subversion allows you to rename files (which is a clumsy process in cvs). It's also able to keep track of directories themselves. cvs doesn't care about diretories, only about files.

      There are lots more differences though, but the two I mentionend certainly sound like they made life a little easier.

    • Re:Differences (Score:5, Informative)

      by Pete ( 2228 ) on Wednesday May 04, 2005 @10:56AM (#12431802)

      Subversion's really intended to be as close to a drop-in replacement for CVS as possible - except with most of the huge design flaws fixed.

      The feature I most notice (I use Subversion at work, albeit with a fairly small dev team) is the ability to do handle file renames properly (preserving history). Atomic commits (of groups of files) are also nice.

      There are lots of other important features [tigris.org] of course, but I tend to use it just as a better CVS - which role it fills admirably.

      • Re:Differences (Score:3, Interesting)

        by SpryGuy ( 206254 )
        Perforce has handled file renames and atomic commits for years now. I'm just curious why Perforce isn't used more widely, as it sounds like Subversion is just now trying to catch up with where Perforce has been for a long time now.

        • Re:Differences (Score:3, Interesting)

          by Woody77 ( 118089 )
          Price difference. Perforce was simply not an option for my small company. Subversion, on the other hand, is just as easy on the pocket-book as CVS.

    • Re:Differences (Score:5, Informative)

      by Chris Kamel ( 813292 ) on Wednesday May 04, 2005 @11:00AM (#12431829)
      Check this [berlios.de] for a detailed checklist of what each of the major version control systems support/doesn't support.
    • Check the main subversion page [tigris.org] for some examples, or try that google thing [google.ca].
    • I'm a fan of the atomic commits, with a single revision number for the repository. This makes it trivial to find a group of files that were checked in together and thus theoretically work together. This is important -- it isn't enough to just say "give me the version of foo.c two checkins back" without knowing what other files changed and what version of those files that foo.c was tested with. With CVS we would hack this functionality on top of it (you could use tags, but that was clumsy). Subversion gi

    • Re:Differences (Score:5, Informative)

      by Anonymous Coward on Wednesday May 04, 2005 @11:11AM (#12431947)
      There are many...

      The main one tends to be lack of tracking of file/directory renames. CVS does not really handle this at all while Subversion handles this very well.

      Subversion also treats a commit of changes to multiple files as an atomic operation. This is a major benefit. You can easily see what all went into a specific commit (bug fix/etc) without trying to track down each file that it happened to. You also never have to worry about part of your commit being on the server and part of it not. It either is committed or it is not. CVS can not do that. (Well, beyond a single file that is)

      Another major issue is the client/server relationship. Subversion has a very clean client/server interface. It is orthogonal, well designed, and relatively low overhead. CVS can not claim this to be the case. In fact, CVS's client/server features were bolted on after-the-fact and show it.

      Subversion can work via HTTP/HTTPS protocols via an Apache plugin. In fact, it is not just HTTP but WebDAV and DeltaV protocol based, which means that there are other tools that can play with the repository as a auto-revisioned filesystem.

      Subversion makes it possible to do some advanced web interfaces rather easily, such as the Insurrection http://insurrection.tigris.org/ [tigris.org] does.

      For me, once Subversion 1.1 came out there was no reason to look back at CVS other than legacy systems. (Subversion 1.0 was already better but it was 1.1 that finally put be over the edge.)

    • Re:Differences (Score:5, Informative)

      by DarkDust ( 239124 ) * <marc@darkdust.net> on Wednesday May 04, 2005 @11:16AM (#12432001) Homepage

      What are the most important features that Subversion has and CVS hasn't? It's been a lot of buzz lately behind Subversion, but I didn't figure it out what CVS has that is so wrong/slow/bad for software versioning

      • File/directory renaming. This is one of the most important things: you can easily move files around in a repository and thus rearrange your project directory structure. I'm forced to work on a big commercial project where we use CVS and the directory layout has grown like a cancer because some idiots couldn't get the layout clean in the first place and noone was able to correct it later (the CVS admin lacks the knowledge and the work necessary has become too big). This is a common CVS problem.
      • Atomic commits.
      • Cheap copies (which are used instead of tags and branches, more on this below).
      • Optional WebDAV support.
      • True binary file support (SVN only stores the deltas to previous versions while CVS has to store the complete file again if something changed... try versioning a 128MB binary file with CVS and watch your disk usage go up by 128MB with each commit).

      There are two things that you'll find different when comming from CVS:

      • The first is the fact that you don't version single files but the whole repository. This is very strange at first, but you'll quickly notice that it's much better than versioning single files as most of the time a source change like a feature implementation affects more than one file. With CVS you don't know that two files were changed at once and that these changes belong together: with SubVersion you instantly know because you see that at revision XY two files where changed.
      • The other thing that seems odd is the "lack" of branches and tags like they're used in CVS: in CVS the repository file path stays the same while the working copy content is different according to the tag/branch. In SubVersion, you'll make a copy of a directory (in the repository) to start a branch. Thus the file path is different. I think the SubVersion way is cleaner and also more user/developer friendly but people that use CVS for years won't agree, I think ;-)

      SubVersion as a whole has more clean, thought-out-design feel, IMHO. Being a former CVS user myself I guarantee you that after working with SubVersion for a while CVS feels a bit hacked together.

  • More switching! More, more! (Score:5, Interesting)

    by Pete ( 2228 ) on Wednesday May 04, 2005 @10:49AM (#12431725)

    Great!

    Now when are they going to be switching from [kde.org] Bugzilla [bugzilla.org] to Trac [edgewall.com]?

    (insert ha-ha-only-serious-cos-Bugzilla-scares-me smiley here)

  • Subversion + trac (Score:5, Interesting)

    by gregmac ( 629064 ) on Wednesday May 04, 2005 @10:49AM (#12431728) Homepage
    I recently switched my internal development from CVS to Subversion, and use trac [edgewall.com] (there site seems to be down right now) as a front end to it all. Trac is a web based interface (written in python) that is a combination wiki, bug tracker, source viewer, changelog and milestone tracker. It has some amazingly cool features, like the ability to put wiki markup anywhere.

    Using a wiki for documenting code is somewhat handy, but what's even better is the wiki extensions trac adds. You can type "This is related to bug #236" and it will make it a link to that bug. The cool part is, you can do that anywhere -- such as an svn commit message. (There's also ways to link to milestones, revision numbers, etc)

    I originally switched to subversion for the big features - the ability to move files/directories, and the simple (compared to cvs) tagging/branching support. Trac just made it that much better.

    • Re:Subversion + trac (Score:4, Informative)

      by tuxpert ( 512567 ) on Wednesday May 04, 2005 @11:02AM (#12431865)
      Although trac is quite good and integrates well with SubVersion, it has a few disadvantages, the main one being no support for multiple projects.

      Scarab [tigris.org], the open-source bug tracking tool that CollabNet's commercial offering [collab.net] uses and GForge [gforge.org], although cumbersome to setup are IMHO better alternatives if you're looking for bug-tracking tools to use along with SubVersion

      --
      Ravi
      • Bugzilla is pretty widely used as well. We are about to switch over to it.
      • It's pretty trivial to set up new instances of trac to correspond to new SVN repositories. If your repository contains multiple projects grouped by a folder, though, you have a point...

      • Re:Subversion + trac (Score:4, Informative)

        by Pete ( 2228 ) on Wednesday May 04, 2005 @11:20AM (#12432037)

        I understand that Trac support for multiple projects (along with a few other features) is due soon - I believe as part of the upcoming 0.9 release [edgewall.com].

        Thanks for the pointers re: Scarab and GForge though, I'll have a look at them. Always nice to keep up-to-date with the alternatives. :)

      • I tried scarab about 8 months back. I found more bugs with scarab in the first 48 hours of using it, than I had bugs in my project. I spent too much time 'dinking' with Bugzilla. So I bought FogBugz, and it just worked without extra work.

        My worst bug with scarab was that it started its 'index' numbers over again. So I had multiple bugs with the same bug number.

  • successor to CVS (Score:5, Informative)

    by moz25 ( 262020 ) on Wednesday May 04, 2005 @10:50AM (#12431734) Homepage
    As I understand, subversion was more or less designed to be the successor (and replacement) of CVS. It's not a big surprise then that switching is a major issue. The users are already used to its methodology (contrary to e.g. linux kernel developers).
  • I've been using SVN mainly for my documents, but hope to start using it for my code.

    Right now I've been using the CLI and I was wondering if anybody knew of GUI frontends (especially for diff'ing).

    • Re:GUI frontend for SVN (Score:5, Informative)

      by slavemowgli ( 585321 ) * on Wednesday May 04, 2005 @11:13AM (#12431970) Homepage
      Did you look into RapidSVN [tigris.org]? I haven't tried it myself, but it may be an interesting alternative to TortoiseSVN if you want support for platforms other than windows.

      There's also a Subversion plugin for Eclipse, in case you're using that.
    • Trac [edgewall.com] provides a nice web based diff tool and a bunch of other features.

  • This is what happens... (Score:5, Funny)

    by gbulmash ( 688770 ) * <semi_famous@ya h o o .com> on Wednesday May 04, 2005 @10:57AM (#12431808) Homepage Journal
    ...when you let geeks name products.

    Of course, Microsoft is coming out with their own alternative. It's called Coercion.

    - Greg

  • I would love to see how well Insurrection works... (Score:5, Informative)

    by Anonymous Coward on Wednesday May 04, 2005 @10:58AM (#12431817)
    I have build Insurrection, an enhanced web interface to Subversion, that is very closely tied to the way Subversion works. I would love to see how well it handles a repository as large as the KDE repository. (Plus I think it is a good tool, but then I wrote it :-)

    You can play around with it at http://www.sinz.org/Michael.Sinz/Insurrection/ [sinz.org]

    Note that I am still in somewhat active development but the code is also in active use. It can be checked out with:

  • TortoiseSVN (Score:5, Informative)

    by Mustang Matt ( 133426 ) on Wednesday May 04, 2005 @11:05AM (#12431888)
    This is one of the best windows based svn clients I've seen.

    http://tortoisesvn.tigris.org/ [tigris.org]

  • merging (Score:2, Interesting)

    by Hohlraum ( 135212 )
    I remember awhile back that the subversion guys said that merging/branching wouldn't outshine cvs for a couple more releases. Is that that case now? I haven't been following subversion development for awhile now.

    • Re:merging (Score:2, Informative)

      by JSD ( 6203 )
      Subversion has the same (poor) merging capabilities as CVS.

      FYI, I use Subversion but merging in Subversion and CVS is not nearly as simple as with Perforce or Arch. I subscribe to the subversion dev mailing list and I think it's probably at least another 1-2 years before Subversion has merging capabiliies on par with Perforce, Arch, ....

      If you're interested in doing lots of merging with Subversion then you'll want to look at svnmerge ( http://www.dellroad.org/svnmerge/index [dellroad.org]). I haven't used it but it ge

      • Try SVK (Score:2, Informative)

        by Krischi ( 61667 )
        SVK [elixus.org] works well with subversion, and has support for star merges. The ability to work offline is another cool bonus. On the flip side, documentation kinda sucks right now, but its command set for every day use works in pretty much the same way as subversion's.

  • Reasons NOT to do it in an Eclipse environment (Score:3, Interesting)

    by standards ( 461431 ) on Wednesday May 04, 2005 @12:15PM (#12432565)
    I know all about Subversion and its advertised benefits, but then again, my organization is centered around CVS and it works for us (despite its well known limitations).

    But since I need to reorganize my development environment (new development machines, etc), I'm curious - should I switch now?

    My development environment consists of CVS and Eclipse on Windows, Linux, Solaris, and Mac (an amalgam, eh?) ... a small group of distributed developers working on a (currently) proprietary product based around Java and Perl.

    I'd only like to convert and clean up my source code repository once every 5 years or so... so is this the time to do it, or am I just looking for trouble?

  • Subversion is kinda behind the curve these days. I mean the whole concept of Subversion can basically be summed up as "let's make something that feels just like CVS, but doesn't suck." There are lots of free alternatives that provide much more advanced capabilities.

    It's too bad they didn't chose something more advanced like Vesta [vestasys.org], or Codeville [codeville.org], or monotone [venge.net], or Darcs [darcs.net].

  • I think that's also well-worth noting, as Apache is a pretty big and significant open source software player, and as such its migration to Subversion, which happened months ago, served as the "green light" for smaller projects's move to SVN.

    When is SourceForge making this move?
  • Apache almost switched all of is infrastructure to SVN... if you know that Apache.org is a little bit more than simply the webserver, you know what I mean. Guess the code which already is hosted on the Apache SVN outnumbers the one from the KDE project.

    But nevertheless, Konkratulations

Slashdot Top Deals

Math is like love -- a simple idea but it can get complicated. -- R. Drabek

Close