×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Subversion 1.8 Released But Will You Still Use Git?

Unknown Lamer posted about 10 months ago | from the darcs-for-life dept.

Software 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.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

378 comments

First post! (-1)

Anonymous Coward | about 10 months ago | (#44049461)

First post! muajaaa!

Re:First post! (5, Funny)

Anonymous Coward | about 10 months ago | (#44049683)

cat ./slashdot/posts/44049461.txt | sed 's/First/Second/g' | sed 's/muajaaa/bwaaa/g' > ./slashdot/posts/44049461.fixed
mv ./slashdot/posts/44049461.fixed ./slashdot/posts/44049461.txt
git add ./slashdot/posts/44049461.txt
git commit -m "Fixed that for you!"

github (1)

stoolpigeon (454276) | about 10 months ago | (#44049469)

I really started using github regularly at the same time that I started using github.

It's grown to so much more than the underlying version control software.

Re:github (0)

Anonymous Coward | about 10 months ago | (#44049513)

I really started using github regularly at the same time that I started using github.

Well then.

Good luck using github for anything with any sort of security/IP/audit requirement.

Re:github (1)

sjames (1099) | about 10 months ago | (#44049693)

I would imagine a shop with that requirement would install an in-house manager for Git repos.

One size does not fit all but it's nice to have a solution that can be fitted easily.

Re:github (3, Informative)

liamevo (1358257) | about 10 months ago | (#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.

Re:github (5, Funny)

Anonymous Coward | about 10 months ago | (#44049805)

Pfft. I've been using Github for decades before I started using github.

GIT sucks on windows (-1)

Anonymous Coward | about 10 months ago | (#44049471)

If you live in linux land and love using only command line, then GIT is fine. On the other hand, if you want to grab the latest code, make a change and commit, GIT sucks. It's especially true if you're using Github. Having to rebase is tiresome, especially on windows. The times I've contributed to OSS projects that used GIT, I spent 5 minutes make the code change and 30 minutes rebasing. For comparison, with SVN, I spend 1 minute to do update and 5 minutes to make the code change.

Re:GIT sucks on windows (4, Interesting)

ebno-10db (1459097) | about 10 months ago | (#44049643)

If you live in linux land and love using only command line, then GIT is fine. On the other hand, if you want to grab the latest code, make a change and commit, GIT sucks. It's especially true if you're using Github. Having to rebase is tiresome, especially on windows. The times I've contributed to OSS projects that used GIT, I spent 5 minutes make the code change and 30 minutes rebasing. For comparison, with SVN, I spend 1 minute to do update and 5 minutes to make the code change.

What about Mercurial? (you know, the DVCS that fanbois dis because it's not used by Linus the ultimate cool kid). I'm considering switching from Subversion to something else for my team at work, but the Git UI is awful. I've heard Mercurial is better, including its GUI integration (e.g. Tortoise).

P.S. To put a little damper on the flame war that this will ignite, I swear that personally I would give my left kidney to crawl over broken glass for the privilege of reading man pages all night just to be able to do the same thing with Git that I could figure out in 5 minutes with any other version control system. However, other people on my team are very good at what they do (Ph.D.'s working on signal processing) but are not quite as enthusiastic as I about the broken glass.

Re:GIT sucks on windows (0)

Anonymous Coward | about 10 months ago | (#44049733)

? `git gui` in Linux...TortoiseGit in Windows. Yay, UI + Git. So hard.

Re:GIT sucks on windows (0)

Anonymous Coward | about 10 months ago | (#44049879)

Ah, come on, TortoiseHg for the win!

Re:GIT sucks on windows (3, Interesting)

Anonymous Coward | about 10 months ago | (#44050005)

TortoiseGit is a flaming pile...it tries too hard to look like TortoiseSVN, and so it just ends up being confusing. There are a number of alternative gui git clients for windows, of which Sourcetree [sourcetreeapp.com] is my current favorite, but not by much (I don't like it as much as either TortoiseSVN or TortoiseHg).

To the gp, if you're on windows, I'd give mercurial the edge, based on both UI and general mindset. Git is very much a product of linux, and so it makes some assumptions that aren't correct if you're on windows. On the other hand, github is both amazing and unique (bitbucket tried to do the same thing for hg, but it's not nearly as nice a social scene). And if you're trying to develop marketable skills (probably a good idea in our industry), git experience will most likely take you farther than hg experience.

Re:GIT sucks on windows (1)

Anonymous Coward | about 10 months ago | (#44049865)

If you live in linux land and love using only command line, then GIT is fine. On the other hand, if you want to grab the latest code, make a change and commit, GIT sucks. It's especially true if you're using Github. Having to rebase is tiresome, especially on windows. The times I've contributed to OSS projects that used GIT, I spent 5 minutes make the code change and 30 minutes rebasing. For comparison, with SVN, I spend 1 minute to do update and 5 minutes to make the code change.

What about Mercurial? (you know, the DVCS that fanbois dis because it's not used by Linus the ultimate cool kid). I'm considering switching from Subversion to something else for my team at work, but the Git UI is awful. I've heard Mercurial is better, including its GUI integration (e.g. Tortoise).

P.S. To put a little damper on the flame war that this will ignite, I swear that personally I would give my left kidney to crawl over broken glass for the privilege of reading man pages all night just to be able to do the same thing with Git that I could figure out in 5 minutes with any other version control system. However, other people on my team are very good at what they do (Ph.D.'s working on signal processing) but are not quite as enthusiastic as I about the broken glass.

We switched from SVN to Mercurial at work, for technical folks it hasn't been a problem, but for less technical folks it is. My main gripe with Mercurial is that the tooling sucks. Yes TortoiseHg is okay, but IDE based tooling is lagging badly. Go ahead and use it in Eclipse on Linux for awhile, you'll see what I mean. I gave it a pass at first, SVN tooling really sucked at first too, but their grace period has long since run out. Git won the DVCS war, the vast majority of the people contributing to the tooling are working on it, not Hg.

SVN tooling remains really good. I'm a little gunshy about the branching and reintegration problems we used to encounter, so I've learned to avoid certain behaviors in favor of stuff I know is far less likely to cause problems. I know they said they'd improve it and maybe they have, but my workflow on SVN repos is fine.

Re:GIT sucks on windows (1)

Microlith (54737) | about 10 months ago | (#44049973)

What about its UI is awful? Is it because it is command line based that makes it awful?

I think the real problem is that people approach Git thinking it's like SVN, and when the SVN way of doing things doesn't work they get frustrated and proclaim it to be awful.

Re:GIT sucks on windows (5, Informative)

DrXym (126579) | about 10 months ago | (#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.

SVN sucks on windows (-1, Flamebait)

Jerry Atrick (2461566) | about 10 months ago | (#44049881)

SVN is great until it subtly (or no so) corrupts either the db or your working copy. Which on Windows happens a lot because every damn SVN client has enough bugs you need to use multiple tools to get work done. Then use extreme care to stop the buggy POS clients from interacting destructively.

And once it's buggered you have an undecipherable pile of bits. RCS just worked but didn't do much, CVS did more and just worked most of the time. Both were trivially repairable when disaster struck. There are days I miss RCS badly.

Re:SVN sucks on windows (5, Insightful)

Matje (183300) | about 10 months ago | (#44049945)

Care to point to specific bugs? We've been using SVN for years and never seen these problems.

Moreover, since SVN is client-server, why would a buggy client cause datacorruption in the database? Are you implying there are major bugs in the svn server?

without backup, your claims are just FUD...

Re:SVN sucks on windows (1)

ebno-10db (1459097) | about 10 months ago | (#44049987)

I've been using/administering svn for about 10 years now, usually w/ a Linux server and Windows clients. I've never had that happen. I'm sure your experience is different, but I've no idea why. I never even had problems with some of the older svn upgrades that automagically upgraded the repository (I faithfully did backups before hand, but never had to use them).

Re:GIT sucks on windows (1)

ahabswhale (1189519) | about 10 months ago | (#44049893)

What's so difficult about doing these things on Windows? It's the same process as OSX or Linux. And why do you need to rebase so much?

Re:GIT sucks on windows (0)

Anonymous Coward | about 10 months ago | (#44050129)

I guess he comes from SVN-land where the history is one line, no actual branches and rebase provides him with that kind of history ?

on the other hand you should never have to ask such a question as "why do you need to rebase so much". It's there, it's a feature of git, there should never be a restriction such as "yeah, you can use it, but not too much". "why do you use that feature" is probably one of the worst oximoron

disclaimer: this AC has switched from subversion to mercurial and git a looooong time ago. Never looking back.

Different strokes for different folks (4, Insightful)

WuphonsReach (684551) | about 10 months ago | (#44049473)

Whether you use git/mg/etc (distributed VCS) or centralized VCS systems (SVN, etc) has a lot to do with the level of control that you desire/need and how much centralization you desire/need.

For some development projects / communities, where everyone is independent and rarely connected to a central point, the distributed VCS make more sense. The downside is that you have to rely on developers to push their changes to some "master". On the other hand, it means they can work offline / disconnected.

For the less technical users, centralized VCS like SVN makes more sense. As long as you can get them to commit the changes, you're ensured that those changes are now on a server/machine that is getting backed up and taken care of.

Re:Different strokes for different folks (1, Insightful)

Anonymous Coward | about 10 months ago | (#44049537)

Your post is filled with nonsense. I've always used a central repo with git. That repo and all of it's backups could turn into a smoking crater, and we'd still be ok. With SVN, you better hope your backups are solid, because you're borked if you lose them.

Re:Different strokes for different folks (1)

ebno-10db (1459097) | about 10 months ago | (#44049655)

Heretic! Real programmers use Git. Nobody else gets to sit at the cool kids' table.

Re:Different strokes for different folks (1)

Anonymous Coward | about 10 months ago | (#44049803)

For the less technical users, centralized VCS like SVN makes more sense. As long as you can get them to commit the changes, you're ensured that those changes are now on a server/machine that is getting backed up and taken care of.

That was one of the things that made me drop SVN as an option. What do you mean I need a server? Do I need a server admin too?

SVN may be fine for projects in a company, that have admins on staff. But for smaller projects where one doesn't have an admin on staff, GIT is much easier.

$ git init

That's it. No server needed, you don't even need to know the root password. And no need to take backups of a server either, the usual backup of $HOME includes the whole repository.

Re:Different strokes for different folks (1)

mordejai (702496) | about 10 months ago | (#44049925)

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

Re:Different strokes for different folks (1)

Anonymous Coward | about 10 months ago | (#44050043)

SVN can be used as a VCS for other items too, like media or documents. Sometimes you want the less technical users to still get the benefit of version control.

Re:Different strokes for different folks (0)

Anonymous Coward | about 10 months ago | (#44050035)

...the distributed VCS make more sense. The downside is that you have to rely on developers to push their changes to some "master"...

...SVN makes more sense. As long as you can get them to commit the changes...

I'm not sure what point you are trying to make here. If you can't get your team to regularly update a central server, not only do you have serious management issues, but you have the same problem regardless of what VCS you use. If they do then the benefits in terms of backing up are the same.

Nice improvements (2)

cold fjord (826450) | about 10 months ago | (#44049489)

Going through the article it looks like a nice set of improvements. I expect that subversion users will be pleased with both the current improvements, and what will be built upon them in the future.

Among the useful improvements noted [developer.com]:

One of the area where robustness has been improved is in the storage of metadata. SVN now tracks the moves of working copy items. Stein noted that the harder part is getting the rest of the system to recognize the moves, and that work is ongoing. He explained that from a historical perspective, SVN didn't "move" items per se. Instead, the item was copied to its new location, and deleted from the old.

"This is problematic (for example) because if an edit comes in from the server for that deleted item, then we don't know what to do with it," Stein said. "For a moved item, then we know the edit should probably be applied to wherever the thing was moved."

But can SVN merge a branch yet? (1)

cultiv8 (1660093) | about 10 months ago | (#44049495)

My only complaint of SVN and the reason I moved to git.

Re:But can SVN merge a branch yet? (1)

Duncan Booth (869800) | about 10 months ago | (#44049551)

Automatic branch merging is listed in the release notes. I have no idea though how well it works.

Re:But can SVN merge a branch yet? (1)

LizardKing (5245) | about 10 months ago | (#44049595)

It sounds like the proper support for renaming that's new in this release is a step in the right direction. I assume branching is still really copying in Subversion though, which I recall being problematic in earlier versions where you needed to know at what point you'd branched from to do merges.

Re:But can SVN merge a branch yet? (3, Informative)

RaceProUK (1137575) | about 10 months ago | (#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:But can SVN merge a branch yet? (5, Informative)

ebno-10db (1459097) | about 10 months ago | (#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:But can SVN merge a branch yet? (2)

ebno-10db (1459097) | about 10 months ago | (#44049895)

Yes! That is the biggest problem with Subversion, and I hope that 1.8 fixes that as promised (although they're only promising partial support right now).

At work one of my side jobs is managing the VC for our small (5 person) dev team. For a small closely knit team centralized VC is fine, but the very limited merge capabilities of svn drive me nuts. 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.

I know I could overcome that problem by switching to Mercurial or Git, and I'd love to, but it's not a good idea with my team. Several of them are very good at what they do (Ph.D.'s in signal processing and detection and estimation) but have little interest in learning what is, for our purposes, the more complicated DVCS approach. Sometimes I feel lucky I got them to use VC at all, and it helps that the svn UI is a lot like the CVS that some of them already knew.

nice size (0)

Anonymous Coward | about 10 months ago | (#44049523)

1 TB repository? Are you storing piles of binary files in there? I cant imagine how many lines of code you could fit on that.

Re:nice size (1)

Anonymous Coward | about 10 months ago | (#44049885)

just one line of code...but it's a really long line.

Re:nice size (0)

Anonymous Coward | about 10 months ago | (#44050149)

... written in Brainfuck.

It's GIT for OSS, SVN for Enterprise. (5, Insightful)

goruka (1721094) | about 10 months ago | (#44049543)

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

-SVN has much better visual tools and is simpler to operate
-SVN has a simpler merge policies which are friendlier when there isn't a central person pulling the changes.
-SVN is very friendly for projects with a lot of binary objects (ie videogames)
-SVN allows different people to work on different directories individually, GIT doesn't.
-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.

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

Re:It's GIT for OSS, SVN for Enterprise. (0, Flamebait)

LubosD (909058) | about 10 months ago | (#44049629)

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

The idea of Git eludes you. You don't structure Git projects in a giant directory tree.

-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.

Have you ever heard about Gitolite?

Re:It's GIT for OSS, SVN for Enterprise. (0, Insightful)

Anonymous Coward | about 10 months ago | (#44049687)

Are you middle management by any chance? You seem to have no idea what you're talking about.

Re:It's GIT for OSS, SVN for Enterprise. (0)

Anonymous Coward | about 10 months ago | (#44049775)

SVN has much better visual tools and is simpler to operate - like what, tortoisesvn? http://code.google.com/p/tortoisegit/

SVN has a simpler merge policies which are friendlier when there isn't a central person pulling the changes. - The person responsible for the changes switches back to master and pulls their branch in, and runs tests, rather than just blindly push and hope everyone copes.

SVN is very friendly for projects with a lot of binary objects (ie videogames) - No issue here. Git sucks for keeping changes between binary files. Not sure if SVN is better, but git is bad.

Re:It's GIT for OSS, SVN for Enterprise. (0)

Anonymous Coward | about 10 months ago | (#44049829)

Our 100 developer enterprise software team uses git, and it is massively better than SVN IMO.

First off, large repo performance is order of magnitudes better. Git repo clones take 1/4 or less the time vs an SVN checkout.

Pull requests work great for many team projects where developers are not familiar with the entire codebase. The codebase can be split into separate repos with different permissions. When a developer makes a change to part of the code they're not an expert at, they create a pull request and a member of a team who does know that piece of code reviews and merges. This is much easier than passing around patch files like you have to do with an SVN repo with strict permissions. It's also much easier for interns and contractors to work on code, since they can clone the repo and create a pull request to merge their changes without having write access to the repo.

IntelliJ has great GIT bindings, just as good as SVN. It will highlight which lines have been modified since the last commit, I can click on a line to see it's commit message/date, I can resolve conflicts with a gui tool, etc.

Git is a more complicated tool and takes longer to learn, but once you learn it branching, stashing, rebasing make day-to-day development tasks much easier/faster.

Re:It's GIT for OSS, SVN for Enterprise. (4, Informative)

Bill_the_Engineer (772575) | about 10 months ago | (#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.

1TB repository? (2)

Nutria (679911) | about 10 months ago | (#44049547)

Who has a 1TB repository? Even 200GB is 15 shades of ginormous.

Re:1TB repository? (3, Informative)

Xest (935314) | about 10 months ago | (#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.

Re:1TB repository? (5, Informative)

Anonymous Coward | about 10 months ago | (#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.

Re:1TB repository? (1)

Anonymous Coward | about 10 months ago | (#44049779)

I used to work at a game dev house and all the artists would put their photoshop and maya files into the SVN repo. It wasn't quite 1TB, but it was massive. I'm not sure subversion is the best for this, but it's what I inherited, and I can easily see having version control for those types of things be useful.

Re:1TB repository? (1)

Anonymous Coward | about 10 months ago | (#44049781)

Our SVN repo is approaching 4GB. All our games assets (graphics/sound/video) are (and have to be) version controlled.

Re:1TB repository? (0)

Anonymous Coward | about 10 months ago | (#44049931)

Quite often binary dependencies are stored in SVN aswell. Once you start storing images, soundfiles, video and other blobs the size can grow quite quickly. Storagespace is cheap anyway nowadays, many reasons for keeping that stuff outside of VC don't apply anymore and there are benefits to storing it in there.

Game programmers who need Art! (5, Informative)

Anonymous Coward | about 10 months ago | (#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.

Hg (0)

LizardKing (5245) | about 10 months ago | (#44049553)

Everyone and their brother seems to have moved to Git

I've seen a lot of proprietary development moving to Mercurial, but haven't heard of anyone moving to Git. The latter seems to be much more popular for Open Source stuff.

Re:Hg (1)

pmontra (738736) | about 10 months ago | (#44049721)

All the closed source software for customers of mine (usually web apps and related services) was already on git when I took over the projects or has been migrated afterward (usually not my call). The only exception was a 1 GB svn repository of binary files that we don't really need to work much with and didn't make sense to convert. Anyway the two of us are too small a number to make a statistics. Just my two cents anecdote.

But in some environments git has become a de facto standard. Almost any Ruby gem is on github, which makes it easier to install, fork and modify. That means that many people and companies also use it for their private projects because they're accustomed to the tool. They also have desktop clients for Mac and Windows but I have no idea of what they do. I see customers hosting they remote git repositories on bitbucket too and somebody run their own server.

After years of git I can't think of using a pure centralized system anymore. Too limited.

Re:Hg (1)

zarr (724629) | about 10 months ago | (#44050117)

My 2 cents worth of data confirms your experience. My 3 last employers all moved to git from cvs or svn while i worked there. The first one was developing multi million LOC enterprisy stuff and ended up being bougth by Microsoft, which was ironic, until MS actually started supporting git themselves in tfs'12. How is that for closed sorce adoption? :)

Git is much better for large repos (0)

Anonymous Coward | about 10 months ago | (#44049609)

Yeah, but with Git at least you have the option of cloning that 1T repo if you really want to. If you try to checkout a 1T repo with SVN it will take weeks.

Re:Git is much better for large repos (1)

Duncan Booth (869800) | about 10 months ago | (#44049943)

You are confusing the repo size with the size of a checkout. With Git they are pretty much the same, but with SVN you only checkout the revision and indeed the branch that you actually need. If the repository has been well managed there may not be much in it, but as soon as someone adds binaries to the checkin the repository size is likely to explode. Here's an example: I wanted to play with a particular application environment just to get an idea what it could do. Their main 'kitchen sink' sample program at that time didn't have an up to date zip download, so the only way to get the latest version was to clone the github repository. For some reason they had included generated object files in the repository, so to get the example program it was a multi-GB cloning operation. If it had been in SVN it would have been a few MB total.

Re:Git is much better for large repos (2)

IanCal (1243022) | about 10 months ago | (#44050049)

git clone --depth 1

To add to this, last time I used SVN, it seemed to transfer each file individually which was really slow. Git compresses the files and then transfers everything

easier administration? (0)

Anonymous Coward | about 10 months ago | (#44049613)

Git shops typically have many, smaller repositories, while svn shops typically have a single repository, which eases administration, backup, etc.

Eh... I'm not sure backup could be any easier than every developer already (automatically, by design) having the full repository on their own separate machines. I don't know much about modern SVN administration tools, but I'd also be surprised if it's easier than Git, esp. using something like Gitolite, and that's assuming you want to bother with a "central" repository at all.

Both Have Their Purposes (3, Interesting)

ideonexus (1257332) | about 10 months ago | (#44049625)

I started using Git last year for my personal projects. It's a fantastic platform for coding as a social-network. I love that I can grab code I need from other developers around the world, tweak it, and send it back with a few suggestions. I love that I can follow other projects without having to get involved. Git is awesome.

That being said, we still use SVN for our internal development. The WYSIWYG interface of Tortoise is simply really comprehensive. I realize that Git offers more options, but if those options aren't available with a simple right-click, then I don't have the time for them. Tortoise SVN makes everything readily available, while Git makes me run to the command line too often.

Re:Both Have Their Purposes (0)

Anonymous Coward | about 10 months ago | (#44049869)

While not perfect, you might want to take a look at SourceTree [sourcetreeapp.com], a nice git gui from Atlassian. It's free, it actually looks decent, and does a much better job than the github client of keeping you off the command line. To date, it's my favorite git client.

Re:Both Have Their Purposes (1)

Frequency Domain (601421) | about 10 months ago | (#44050177)

For personal use I like Tower, but that's OS X only and costs $. SourceTree, in addition to being free, works on both Windows and OS X so that's what I recommend for my students.

Re:Both Have Their Purposes (0)

Anonymous Coward | about 10 months ago | (#44049875)

I started using Git last year for my personal projects. It's a fantastic platform for coding as a social-network. I love that I can grab code I need from other developers around the world, tweak it, and send it back with a few suggestions. I love that I can follow other projects without having to get involved. Git is awesome.

That being said, we still use SVN for our internal development. The WYSIWYG interface of Tortoise is simply really comprehensive. I realize that Git offers more options, but if those options aren't available with a simple right-click, then I don't have the time for them. Tortoise SVN makes everything readily available, while Git makes me run to the command line too often.

tortoiseGIT. No excuses.

Re:Both Have Their Purposes (1)

ahabswhale (1189519) | about 10 months ago | (#44050163)

Do you also like the tree conflicts you get when moving directories around in your project? Those are my favorite thing in SVN. In theory, they've made this better in the new version but I'll believe it when I see it myself. That's something about SVN that just really pisses me off.

Won't use SVN. (0)

Anonymous Coward | about 10 months ago | (#44049657)

All SCMs suck, some more than others. I liked CVS despite all its drawbacks. I can't help but dislike SVN despite all its upsides, notably its unbearably smug attitude, and especially its "documentation" drives me up the wall. Git, well, seems to be a reasonably solid bit of software and comes with somewhat usable manpages, despite its treacherous heritage. So we'll use that, reluctantly.

There are a few more alternatives I'd look at before looking at SVN again, in fact. And no apologies for not being sorry about it.

Re:Won't use SVN. (1)

Anonymous Coward | about 10 months ago | (#44049821)

And you are complaining about "unbearably smug attitude", with your hipsterish deathgrip on CVS?

Re:Won't use SVN. (2)

gulikoza (1087283) | about 10 months ago | (#44050065)

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

Sure, I've switched to git for my projects, but CVS is so easy to set up, centralized (it's a plus, when you need that), text files in repository and each file is versioned on it's own (it's a plus, when you need that). One great use I've found is put some software into git, manage patches with stgit, while having each individual patch in a CVS repository for patch history. I wouldn't change that for svn.

time terminology (0)

Anonymous Coward | about 10 months ago | (#44049679)

If by "back in the day" you mean "earlier this morning" in regards to CVS? Then yes, I remember, you insensitive clod!

Yes (0)

Anonymous Coward | about 10 months ago | (#44049689)

Of course I'll still use git; I don't trust source to databases.

hammer vs. screwdriver (0)

Anonymous Coward | about 10 months ago | (#44049731)

My screwdriver is so superior to your hammer! Need proof? Just try to fix a screw with your hammer, duh!
Move on - nothing to see here.

Never seen Git (0)

Anonymous Coward | about 10 months ago | (#44049753)

Never seen git. Never cared. Everyone and the dog uses Mercurial here.

Re:Never seen Git (0, Funny)

Anonymous Coward | about 10 months ago | (#44050041)

Perforce.

Git is auto-backup (3, Insightful)

mathimus1863 (1120437) | about 10 months ago | (#44049773)

For the same reason the summary complains about users having to clone the entire repo, you don't really have to deal with backups: the entire repo is already backed up by every single one of your users. In fact, this is one reason I use git, because I know that I don't have to worry about backing up. I can sync with github, and know that if github disappears, my code history doesn't go with it.

Re:Git is auto-backup (2)

drinkypoo (153816) | about 10 months ago | (#44049843)

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.

Re:Git is auto-backup (5, Informative)

Anonymous Coward | about 10 months ago | (#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.

bazaar (1)

pauljlucas (529435) | about 10 months ago | (#44049785)

I've been using bazaar [canonical.com] and it's everything subversion is, but better. It's had true renames since I've been using it and it really knows how to merge branches properly (which were the big big problems I've had with subversion).

both actually (1)

TheCarp (96830) | about 10 months ago | (#44049809)

For personal stuff, or things I intend to share haphazardly or widely, I go git all the way. Git is great for when I need to work disconnected and still keep revisions. Its simple, its fast, its easy to make a quick repo, so quick sometimes I make one for things I wouldn't otherwise, because even if it never gets used again, the overhead of turning a directory into a git repo is trivial.

That said, there are times when i have other requirements. Things that are going to need to be tracked long term, be shared with a defined group in a specific environment, times when even if I leave forever, someone else is going to need to be able to see what I did and maintain it all... for this I use subversion.

For example, lets say I have to muck with apache configs. I can go to /etc/apache and make it a git repo; check everything in as is, then work. Nice and safe and no thinking about whether I will want one repo for all machines with apache that I administer or any of that, its in place, its quick, its low overhead.

Then later, if I find multiple apache instances that i want under control, I can make them all different branches of one repo easily, or... I can wait till I have time to really think about how I want to setup a central repo, and pull everything into that when I am ready, without getting in the way of the changes I need to make right now.

So... both really, depending on both the long and short term requirements and who I need to work with in what mode.

I can't even think of enjoying svn ever again... (0)

Anonymous Coward | about 10 months ago | (#44049825)

Does SVN still force all my pending changes into one commit? (and one commit message to rule them all?)
Does SVN still force my commits to be immediately visible to everyone else, meaning I can't do commits in smaller steps without risking to expose unfinished and potentially functionality-breaking changes to rest of the team? (essentially meaning I must run with uncommitted change history far longer than would be necessary or comfortable) -- And don't even think of saying "I should just make my own branch then". Branching and merging in SVN is NOT HELPFUL.

I can't in believe that these features wouldn't be a very big boon to everyone doing teamwork, no matter the company structure/size.

Pristine copies (1)

DrXym (126579) | about 10 months ago | (#44049841)

On the flip side, Subversion stores a pristine copy of every file to avoid a network round trip when doing stuff like diffs. So if you have a 500MB working directory, it's backed by another 500MB worth of pristine copy. A typical Git clone can hold the entire history of the project in less space than that because it is packed down during the clone operation.

But definitely the ability to check out just a few folders or files is an advantage of CVS and Subversion. Git forces everything to be cloned although you can avoid dragging down the entire change history. Submodules are Git's way of decomposing projects into smaller ones and they tend to be hit and miss.

BerkeleyDB (1)

Anonymous Coward | about 10 months ago | (#44049905)

Every project I have ever heard of ends up dumping BerkeleyDB. Apparently, it's a giant tar pit.

Perforce (0)

Anonymous Coward | about 10 months ago | (#44049955)

All you need, and its FREE for small usage..

But Will You Still Use Git? (0)

cjjjer (530715) | about 10 months ago | (#44050003)

Pretty arrogant of the poster to think that everybody uses Git.

But then of the small sample of developers that I have interacted with on the topic of source control and use Git the majority are Git-Nazis and they are waaaay worse than the TFS-Nazis.

Re:But Will You Still Use Git? (0)

Anonymous Coward | about 10 months ago | (#44050211)

But TFS-nazis aren't as bad as RTFA-nazis, so I still don't know where that puts Git-nazis.

Speaking another language (0)

Anonymous Coward | about 10 months ago | (#44050025)

Every time someone starts talking about version control systems I zone out.

Git not good for big assets (2)

alexp700 (849116) | about 10 months ago | (#44050173)

We work on lots of asset rich projects - often the PSDs folder will span many (hundreds!) gigabytes for a small project, and we'll be working on multiple projects at once. The PSDs then often have source imagery and a whole load of clutter collected from clients. SVN is superb at dealing with this scenario, since as a coder I don't fill my machine with sources I don't need - but we need them archived and backed up none the less. This is especially a problem if you're a developer with a fancy small SSD and the guy across the room has 6TB at his disposal for videos ;-)!

Open Source (0)

Anonymous Coward | about 10 months ago | (#44050197)

Generally speaking, new versions aren't for the attracting of new users, but for the pleasure of existing users (since they are the ones writing the code...).

Misleading summary (5, Informative)

stsp (979375) | about 10 months ago | (#44050217)

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 [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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...