Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Software Apache

Subversion 1.8 Released But Will You Still Use Git? 378

darthcamaro writes "Remember back in the day when we all used CVS? Then we moved to SVN (subversion) but in the last three yrs or so everyone and their brother seems to have moved to Git, right? Well truth is Subversion is still going strong and just released version 1.8. While Git is still faster for some things, Greg Stein, the former chair of the Apache Software Foundation, figures SVN is better than Git at lots of things. From the article: '"With Subversion, you can have a 1T repository and check out just a small portion of it, The developers don't need full copies," Stein explained. "Git shops typically have many, smaller repositories, while svn shops typically have a single repository, which eases administration, backup, etc."'" Major new features of 1.8 include switching to a new metadata storage engine by default instead of using Berkeley DB, first-class renames (instead of the CVS-era holdover of deleting and recreating with a new name) which will make merges involving renamed files saner, and a slightly simplified branch merging interface.
This discussion has been archived. No new comments can be posted.

Subversion 1.8 Released But Will You Still Use Git?

Comments Filter:
  • Sparse checkouts (Score:5, Informative)

    by IanCal ( 1243022 ) on Wednesday June 19, 2013 @10:33AM (#44049535)
    While a little more work than with svn, you can checkout just part of a repository: []

    Although I'd argue that if this is a common problem then you probably have several sub-projects.

  • by RaceProUK ( 1137575 ) on Wednesday June 19, 2013 @10:40AM (#44049617)
    Not used SVN for a few years, but I've merged branches several times with it. Not sure what you're trying to say.
  • Re:1TB repository? (Score:4, Informative)

    by Xest ( 935314 ) on Wednesday June 19, 2013 @10:46AM (#44049697)

    Lots of places really.

    Some companies use it for versioning of content as well as just source code and that may mean archiving raw versions of said content such as images, 3D art assets, uncompressed audio and so forth.

  • by DrXym ( 126579 ) on Wednesday June 19, 2013 @10:53AM (#44049801)
    TortoiseGit puts a nice UI over Git that does pretty much everything in the normal developer workflow. I'm not sure why you would be rebasing so much since that would typically be a final act for a large, long lived branch that you intended to squash and make relative to the head of another branch prior to merging it over.
  • by ameen.ross ( 2498000 ) on Wednesday June 19, 2013 @10:54AM (#44049815)

    TortoiseGit? []

  • Re:1TB repository? (Score:5, Informative)

    by Anonymous Coward on Wednesday June 19, 2013 @11:04AM (#44049937)

    On the last games I worked on, a minimum initial sync to build was around 50GB, full sync was over 150GB (MANY different language versions of NIS movies.) I have no idea how big the revision database was but I'm going to guess freakin' huge with over 600000 commits during the project. The BlueArc backing Perforce was bretty large.
    Git would explode in a cloud of fail if you tried to do anything like that, in my opinion it's for toy sized projects.
    Where I work now (at a semiconductor company) the people calling the shots switched from Perforce to Git and it truly sucks. There's over 400 repositories to build the project managed by a nasty set of shell scripts. What I wouldn't give to have a single place to manage all of the changes.

  • Decent comparison (Score:5, Informative)

    by ameen.ross ( 2498000 ) on Wednesday June 19, 2013 @11:05AM (#44049953)

    I'll just leave this here so people get to see a comparison that's actually useful. []

  • by Bill_the_Engineer ( 772575 ) on Wednesday June 19, 2013 @11:07AM (#44049969)

    While GIT expresses the distributed development nature of open source projects much better nowadays, SVN fits the workflow of enterprise projects much better:

    Actually... git fits the workflow better than svn. I have to manage a project that spans multiple institutions and two continents. Instead of forcing everyone to use VPN while they develop, they only need to use VPN to push to the official repository.

    SVN has much better visual tools and is simpler to operate

    What? I use SourceTree on OS X and my coworkers on Windows like TortoiseGit. Also there is "git gui"

    SVN has a simpler merge policies which are friendlier when there isn't a central person pulling the changes.

    What? I don't think you understand how git works.

    SVN is very friendly for projects with a lot of binary objects (ie videogames)

    Not necessarily. We use both svn and git to manage very large BLOBs and I haven't seen any noticeable differences. I have people that version control gigabytes worth of design documents that are stored in binary format and I haven't heard any complaints from them.

    SVN allows different people to work on different directories individually, GIT doesn't.

    We used to think this was a big deal, but the advantages that git has over svn more than made up for this.

    -SVN has fine grained permissions, access and authentication controls, very useful when parts of your project (ie, APIs) are under NDA or you don't want them to leak.

    What? First not by default. The most popular method https+ssh does not. You can use Crowd to make it a little easier.

    Whereas in git I use gitolite. I manage their public keys and assign privileges based on the public key. Keep the NDA (or more importantly ITAR) in a separate git repository which makes life easier all around and satisfies the regulators too. They weren't too comfortable with trusting the single repository to handle the compartmentation correctly.

    They are different systems with different scenarios in mind, comparing them or claiming that GIT is killing SVN is just ignorance.

    I operate both SVN and GIT systems. My anecdotal evidence show that most of my projects left SVN and went with GIT due to its distributive nature. We have operational processes in place that eliminates the need for physical enforcement of a centralized repository. As an extra bonus, my co-developers like the ability to check in while they develop and then push the changes once they are confident that it won't break the build on the official repository.

  • by ebno-10db ( 1459097 ) on Wednesday June 19, 2013 @11:11AM (#44050037)

    Pardon me reposting part of what I wrote above, but I think it explains what he was talking about:

    It's ok to create a branch (say from trunk), work on the branch, and even update it from trunk, but you're pretty much limited to a one-time reintegration merge from that branch back to trunk. You can't easily go back and forth, choosing to put one new thing from trunk into branch and vice versa. That becomes a serious pain if, for example, you use trunk for new development and a release branch on the side. The natural way to work is, if a bug is found in the release, fix it in the release branch and then merge that one change back into trunk. Similarly you may fix a bug in trunk and realize you should also merge it into the release. Svn doesn't really let you do that, so I have to tell people to always make the fix in trunk and merge that one change to the release.

  • Re:github (Score:4, Informative)

    by liamevo ( 1358257 ) on Wednesday June 19, 2013 @11:13AM (#44050063)

    You don't need to use github to use git, bit if you really like github, you can run it on your own servers, there is an enterprise version.

  • by Anonymous Coward on Wednesday June 19, 2013 @11:17AM (#44050123)

    For small repos that's fine, it's a feature. For large repos it's not fine, it's a serious problem. I literally cannot fetch the Android-x86 repo. git won't just finish sending the old stuff if new stuff has appeared since your last attempt to fetch the repo.

    This wouldn't be as big a problem if people didn't think that git access was a substitute for a tarball, so that if you just need to build the fucking code you can do so.

    Use 'git clone --depth 1' if you only want the most recent revision. It will allow you to update it from upstream but obviously you won't be able to go back into the history.

  • by Anonymous Coward on Wednesday June 19, 2013 @11:19AM (#44050145)

    I worked in game programming several years back, and 1TB was quite reasonable. Branching meant IT would bring everyone a new hard drive to store the new branch on.

    IIRC the client for one of the MMOs I worked on was a 20 gig download. The source code that actually went into that... was big, but couldn't possibly have been a gig of raw text before being compiled; the art on the other hand, was sliced, diced, squeezed and compressed to get it down into that small of a download. Art Is Huge. Especially art in the raw forms -- even if the final game art is going to be some horribly compressed format to save space, artists want to record the initial sound files in pristine high bitrate forms, and want to do the initial drawings in zillion-pixel-wide, maximum-color-depth formats, and then compress later. The intro-video that nobody watches alone probably took up more space in the repo than all of our source code files, because it was rendered for impossibly good monitors. So, in our repo, we have both the compressed MP3-low-bitrate voiceovers that go into the game, and also the uncompressed-perfect-form from the recording sessions (just in case we want to recompress to MP3 later so we can have a higher bitrate... or maybe we'll swap to using ogg next year... or just for historical interest? it's a repo, you check stuff in...) And similarly for the textures -- the original photoshop files at maximum size and color depth are gorgeous... and then there's the smooshed version you get on your computer. But we have to store the maxumum size one, because that's the one that we're going to edit if we make a change! And it's version-control, so the repo has this hard-to-compress binary (trust me, photoshop files don't compress nearly as well as python files), possibly in a dozen different versions because all of your art got reviewed and edited as it passed through various layers of management and licencees... And then of course there's video too -- cutscenes and intro video and such.

    There's no chance that you could get a repo like that to work on git. We used perforce rather than svn; perforce is (or at least was at the time) the popular tool in the gaming industry for source control (it's expensive, but stable and has good support for massive repos), but I can see lower budget places going for svn. Git just isn't designed for huge repos full of binary blobs.

  • Misleading summary (Score:5, Informative)

    by stsp ( 979375 ) on Wednesday June 19, 2013 @11:26AM (#44050217) Homepage

    I'm a Subversion developer and would like to clarify this bit of the summary:

    Major new features of 1.8 include switching to a new metadata storage engine by default instead of using Berkeley DB, first-class renames (instead of the CVS-era holdover of deleting and recreating with a new name) which will make merges involving renamed files saner, and a slightly simplified branch merging interface.

    The "new metadata storage engine" probably refers to FSFS which has been the default repository backend since Subversion 1.2. FSFS has been improved since then, and 1.8 contains some new improvements (such as directory deltification) but does not add a new repository backend. The BDB-based backend is the one from Subversion 1.0 and is rarely used these days.

    Subversion 1.8 doesn't contain support for "first-class renames". Renames are still modeled as copy+delete [], with special annotations. The working copy is so far the only part of the system which is aware of moves. There are plans to make other subsystems aware of moves in future releases. Also, while tree-conflicts involving local moves can now be auto-resolved after 'svn update', 'svn merge' mostly behaves as it did in 1.7, expect there is no need to use the --reintegrate option and tree conflicts are now flagged if a directory was renamed or deleted on the merge source branch. Whereas Subversion 1.7 would unconditionally perform the deletion in the merge target.

  • by tlhIngan ( 30335 ) <> on Wednesday June 19, 2013 @11:42AM (#44050429)

    I don't know about you, but I usually try to keep "less technical users" away from software development.

    Why? There's a LOT of places where version control is very useful outside of software development.

    Keeping track of documents, for example - marketing folks run through a lot of variations of a theme and having a repository of older versions of the document is handy. Because otherwise they're going to do it themselves (you'll find documents with timestamps on them for that reason).

    Sysadmins often use VC on their configuration files as well (I've known some to store their Cisco hardware configuration files in VC as well). Serves as a backup (the repos are backed up with the regular source code backup), as well as an "oh shit the switch went down what's the last configuration we have" panic. Instead of hunting through endless wads of files (did I put it here last time? Or is it over there?) you just grab the latest from VC, maybe go back a revision and use that.

    Version control is extremely helpful for a lot of things - being able to hold the latest and previous versions of something in one spot is surprisingly helpful for a large number of instances.

  • Re:Won't use SVN. (Score:5, Informative)

    by ebno-10db ( 1459097 ) on Wednesday June 19, 2013 @11:47AM (#44050517)

    I don't understand however why CVS is so easily forgotten. I still use it on a daily basis.

    It's forgotten only because SVN was intended to be, and is, "CVS done better". It was even created by CVS devs who wanted to start clean to overcome some of CVS's shortcomings, but intentionally and unabashedly looks, feels, and where possible, works like CVS. I've done both CVS (back in the day) and SVN repo setup, and they're both very simple. One reason I chose SVN for some in-house stuff is because the people who already knew CVS could pick it up in a heartbeat.

  • by M. Baranczak ( 726671 ) on Wednesday June 19, 2013 @12:07PM (#44050817)

    Having to rebase is tiresome, especially on windows

    git config branch.autosetuprebase always

    Or add --global to apply this to your personal settings. I don't understand why they didn't make this the default behavior, but there you have it. (And why "especially on windows"? What's different about doing it on windows?)

FORTUNE'S FUN FACTS TO KNOW AND TELL: A giant panda bear is really a member of the racoon family.