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.
Sparse checkouts (Score:5, Informative)
Although I'd argue that if this is a common problem then you probably have several sub-projects.
Re:But can SVN merge a branch yet? (Score:4, Informative)
Re:1TB repository? (Score:4, Informative)
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.
Re:GIT sucks on windows (Score:5, Informative)
Re:Both Have Their Purposes (Score:5, Informative)
TortoiseGit? [google.com]
Re:1TB repository? (Score:5, Informative)
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)
I'll just leave this here so people get to see a comparison that's actually useful.
https://git.wiki.kernel.org/index.php/GitSvnComparison [kernel.org]
Re:It's GIT for OSS, SVN for Enterprise. (Score:5, Informative)
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.
What? I use SourceTree on OS X and my coworkers on Windows like TortoiseGit. Also there is "git gui"
What? I don't think you understand how git works.
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.
We used to think this was a big deal, but the advantages that git has over svn more than made up for this.
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.
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.
Re:But can SVN merge a branch yet? (Score:5, Informative)
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)
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.
Re:Git is auto-backup (Score:5, Informative)
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.
Game programmers who need Art! (Score:5, Informative)
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)
I'm a Subversion developer and would like to clarify this bit of the summary:
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 [apache.org], 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.
Re:Different strokes for different folks (Score:5, Informative)
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)
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.
Re:GIT sucks on windows (Score:4, Informative)
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?)