Slashdot Mirror


Performance Tuning Subversion

BlueVoodoo writes "Subversion is one of the few version control systems that can store binary files using a delta algorithm. In this article, senior developer David Bell explains why Subversion's performance suffers when handling binaries and suggests several ways to work around the problem."

4 of 200 comments (clear)

  1. Re:Why binaries? by jfengel · · Score: 5, Insightful

    It's really nice to be able to have your entire product in one place and under version control. Third party DLLs (or .so's or jars), images, your documentation... just about anything that's part of your product.

    That way it's all in one place and easily backed up. If you get a new version of the DLL/jar/so you can just drop it into a new branch for testing. If your customer won't upgrade from version 2.2 to version 3.0, you can recreate the entire product to help fix bugs in the old version rather than just saying, "We've lost it, you've got to upgrade."

    Basically, by putting your entire project under version control, you know that it's all in one place, no matter what version it is you want. Even if the files don't change, you know how to reconstruct a development installation without having to dig around in multiple locations (source in version control, DLLs in one directory on the server, etc.)

    Yeah, so it costs some extra disk to store it. Disk is cheap.

  2. Re:Why binaries? by autocracy · · Score: 4, Insightful

    Oh, I shouldn't feed trolling... but he does have an account... The target audience and main users of Subversion are not "high level network techs." Software developers / coders is where you want to look. That said, I'm disappointed in the article... I was hoping for tweaks rather than "use a tarball." The information / stats provided was interesting, though.

    --
    SIG: HUP
  3. Re:Why binaries? by javaxman · · Score: 4, Insightful

    1) you want deployment without the need to build
    2) you have proprietary build tools limited to developer use, or release engineers unable to build for whatever reason ( similar to #1, I know... )
    3) images, of course.
    4) Word, Excel, other proprietary document formats are all binary.
    5) third-party binary installation packages, patches, dynamic libs, tools, etc.

    You're just not trying, or you're thinking of version control as something that only programmers would use, and that they'd only use it to store their text source. There are as many reasons to store binary files in version control as there are reasons to have binary files...

  4. Re:Why binaries? by rblancarte · · Score: 4, Insightful

    I was thinking the same - especially since I use Subversion.

    But taking a quick look at the article, I get an idea - storing your binaries at different version levels w/ it. Say I am developing a software package, us SVN for each level of revisions. With major releases I could store the produced binaries with the package to prevent the need to recompile when I am pulling down a version. Basically it would truly version control your binaries as well.

    In some ways the article makes me wish I did that with the project I am currently working on. I might start doing it now.

    -R

    --
    It is human nature to take shortcuts in thinking.