Atomized

Subversion sucks

Aargh! I’ve been playing with Subversion, and I completely despise it. I have no idea why, given the chance to write a SCM from the ground up, anyone would possibly choose to produce this. It sucks. It sucks hard. In fact, I think it sucks worse than CVS, which it’s intended to replace.

The Case For

• It’s Not CVS(TM). Some people just want anything but CVS.
• Can copy/move/rename files and directories. This is nice. CVS is quite clumsy about moving things around.
• Doesn’t try to expand keywords in binary files, corrupting them. Default CVS behavior is to expand keywords (like $Id$) in all files, which will corrupt binary files in many cases. Subversion doesn’t do anything like that by default.

The Case Against

• Slow. Can you say slow? My god, Subversion is slow. How slow? Slower than a molasses glacier trapped in a stasis-producing rift in the fabric of space-time. Want to commit a file? Get ready to stare at the wall for a good 15 seconds. Heaven help you if you want to create a branch, which can take a good hour on a decent-sized repository. KDE recently switched to Subversion from CVS; I assume that their Subversion admin team consists of giggling homosexuals who take turns branching KDE releases while being whipped as they are repeatedly dunked upside-down into a vat full of piranha-infested human waste with mercury pouring down their throats, with breaks in between sessions to dress their wounds with salt bandages.
• No CVS migration tool. Or rather, no reliable, well-tested tool. I don’t know about you, but I prefer to avoid moving my four years of mission-critical development history to a new SCM system using an unsupported tool created by a third party, which is still in the alpha stages of development.
• It’s on-disk format sucks. It uses Berkeley DB, which is notorious for incompatible changes in it’s on-disk format and library. Say hello to incompatibilities, repository conversion, library conflicts, and crushing migraines. Expect the conversion to take approximately three weeks and completely corrupt your repository.
• It pollutes your project namespace. If you want to use the mind-bogglingly sluggish tag/branch system, you have to have three directories at the top of your project. Fortunately, they aren’t created automatically; you get to do it by hand! Or more likely, not realize that anyone would be retarded enough to think that directories are a good way to manage branches, and therefore not create them at all. Have fun moving everything in your whole repository one level down. It’s easy with Subversion, though by the time the first of the two commands has finished executing, senility may have robbed your memory of the second one.
• To make a new branch, you use the copy command. To make a new tag, you use… the copy command. Now that’s user-centric design!
• Merging is virtually impossible! That’s right, after you’ve gone to the trouble of setting things up so you can tag & branch, you will find that Subversion makes it astonishingly difficult to actually use those branches. The procedure from the FAQ (it’s not mentioned in the manual at all) consists of these seven easy steps:
  1. Create your branch, ‘foo_branch’
  2. Create a tag identical to the branch, ‘foo_branch_lastmerge’
  3. Work on the foo_branch branch
  4. Merge the difference from the foo_branch_lastmerge tag into your working copy of the foo_branch
  5. Commit your changes to foo_branch
  6. Delete the foo_branch_lastmerge tag
  7. Create a new foo_branch_lastmerge tag from the current foo_branch.

  Note, however, that you can’t just specify ‘branches/foo_branch’ – you have to give the full SVN URI every time you reference a tag or branch. It’s enough to send you shrieking back to the caves to chisel code out on stone tablets while making “ook ook” noises.

• Remember, tags and branches are just directories. Isn’t that convenient? And it means that, for a 500mb repository with two branches and two tags to merge changes from those branches, you’re only going to need 2.5gb of space (and bandwidth) to check out the repository. Now that’s convenient.

I hate Subversion.

Discussion

heh, i actually like subversion. my biggest beefs are the speed and the having to use full URIs for branching and tagging. but otherwise i actually found merges saner and easier to manage than CVS merges (i don’t use that seven-step process from the FAQ, though).

note, however, that all of my projects are pretty small…

bunnyhero

2005/09/05

Subversion uses cheap copies – i.e. tags & branches don’t take up additional space by default.

Anonymous

2005/09/11

Wow. You show pretty complete ignorance in how to use subversion. How can a branch take an hour?? Even a cursory glance at the docs (not to mention actually _trying_ it) would show that it is practically instantaneous.

And I don’t know what problems you’ve been having with BDB, but we’ve got a repository of several gigabytes in that format and have never had a problem.

Greg

2005/09/16

1. slow? that’s objective I suppose, but it’s no slower than cvs. you probably screwed something up.
2. cvs2svn
3. fsfs backend has been stable for a good year by the time you posted this.
4+: you don’t like making directories and moving files, and don’t know about shallow copies. this is basic stuff.

rasputnik

2005/11/01

“1. slow? that’s objective I suppose, but it’s no slower than cvs. you probably screwed something up.”
Hey, how about someone suggesting specific things which may be screwed up instead of just accusing me of incompetence?

“2. cvs2svn”
According to the Subversion FAQ, it is still not reliable.

“3. fsfs backend has been stable for a good year by the time you posted this.”
This is precisely the problem I’m pointing out – Subversion has far too much instability. So now I have to convert my existing SVN repositories to a new format? Terrific.

“4+: you don’t like making directories and moving files, and don’t know about shallow copies. this is basic stuff.”
If it’s so basic, how come Googling for “shallow copies site:subversion.tigris.org” returns zero hits? Do you mean “cheap copies?” I submit that someone incapable of getting “basic” terminology correct is in no position to tell me what I am doing wrong.

Subversion still sucks.

Ian Eure

2005/11/17

Cheap Copies:
http://svnbook.red-bean.com/en/1.1/ch04s02.html#svn-ch-4-sect-2.1

Subversion’s repository has a special design. When you copy a directory, you don’t need to worry about the repository growing huge—Subversion doesn’t actually duplicate any data. Instead, it creates a new directory entry that points to an existing tree. If you’re a Unix user, this is the same concept as a hard-link. From there, the copy is said to be “lazy”. That is, if you commit a change to one file within the copied directory, then only that file changes—the rest of the files continue to exist as links to the original files in the original directory.
…

The documentation isn’t on subversion.tigris.org it’s the Subversion book http://svnbook.red-bean.com

I’ve been looking at switching from cvs to svn at work. It seems to be useful that branches and tags exist as actual directories. I’m sure that there are good ways of keeping track of the symbolic names in cvs, but I like that I can see a layout of everything with svn list.

Also, merging is discussed in the book here:
http://svnbook.red-bean.com/en/1.1/ch04s03.html
The book does seem pretty well written and clears up a lot of things. Not that you’re wrong on the points that you make, but it seems like some of the problem is that you want to be able to use svn the same way you are used to using cvs. That may be a real problem with svn, afterall, you wouldn’t try to use cvs the same way rcs was used.

Dana

2005/12/14

The subversion book is linked at subversion.tigris.org.

I know what cheap copies are, but they don’t seem to be O(1). It still takes a significant amount of time to branch.

Merging. I’ve read the docs, I’ve whined on the lists, I understand the difference between merging with CVS, and I think the SVN way is incredibly stupid. Even after reading everything there is on the subject, I get errors when e.g. files are added in one or the other of the branches. SVN complains that there’s no revision in the target branch – well, duh, it’s a new file, and I want it merged.

Merging with SVN is problematic at best.

Ian Eure

2005/12/23

Sure, Subversion may actually be faster than CVS, so long as you aren’t on an NTFS partition (last I checked, a significant fraction of us still, unfortunately, are). But anyone who says Subversion is fast has never tried putting a big project into Perforce. Joy, by comparison.

I’ve run into the hour copy problem. If you do the copy remotely (using the arcane commands necessary to do so), the same copy took only a couple of minutes. If you do that, then you’ve created a broken repository, if any of the files know anything about their location in the heirarchy. If you think that’s an acceptable tradeoff, you don’t appreciate the purpose of changelists.

The Subversion team set out to make something better than CVS. Ten years ago, that would have been a noble goal. Perhaps as recently as five years ago, that would still have been an improvement. For a very long time, the world stood still, and CVS was the best you could do. When it was evidenced that the world was changing, they set their bar too low, and have been found lacking.

My advice to anyone trying to write a new version control system: Find a seasoned Perforce user. Find out what they like about it, what they hate about it, and what they can’t live without. If you can’t do better on at least one count, and as well on the others, find another way to contribute to the community, lest your effort be wasted.

Jason Marshall

2006/01/17

Regarding SLOWness, the following solution restored my confidence: http://poocs.net/articles/2005/05/17/weird-hanging-commits-in-subversion

H Wassermann

2006/04/18

I agree, SVN sucks.
I don’t know what they bother making a download available for windows! It doesn’t even run as a service, it runs as an dirty old cheap console program not to mention it doesn’t even support SSPI on windows networks.
And don’t bring me that crap about having to use Apache. Yes, you have to install Apache to use real authentication, is that cheap or what.
To me the whole product has an “academic” rather than a professional feeling. If the plan was to rewrite things from scratch, it could have been done in a less mediocre way.

SBurns

2006/05/26

I just want to say DONT USE SUBVERSION. If I say delete directory A it will sometimes delete directory B. I constantly have to clean-up etc. If you delete a directory in explorer it will f*** up subversion. It just SUCKS

Subversion is cvs’s PREDECESSOR.

Developer

2006/07/07

I just don’t get it. The version control industry has some really great NEW tools that aren’t based on some architecture that was good enough 20 years ago. Reminds me of some of the highways I drive on. They started building 3 lanes 20 years ago and now they wish they had built 4 or 5. Subversion is the 3 lane highway.

Skip over the interrum crap and go for something worth using. There are plenty of reasonably priced tools if you need source control for more than your home office book report.

People use what they are familiar with, not necessarily what is better. Sad.

Developer1

2006/07/21

Your productivity is only as good as your tools. CVS and SVN are fine for small, manageable projects. And so are many other traditional opensource SCM tools.

When it’s time to graduate to a real SCM tool, look for one that uses Streams instead of Branches. A stream-based architecture will give you a far more natural workflow-oriented style of managing your software development… for 1 to 10,000 developers esp. when working on parallel codelines.

just google “stream based scm”

Veteran

2006/08/10

I completely agree with you. IT REALLY SUCKS A LOT. REALLY REALLY REALLY… It simply doesn’t work AT ALL!!!!! Even the book online documentation is buggy (CRAPPY!!!). It doesn’t even worth spending time to write how it SUCKS!!!

Developer

2006/09/16

I have to agree with the author. To put it harshly, SVN seems “stupid” when compared to CVS. Maybe it’s because I learned CVS first and then tried SVN (but I doubt it).

It’s to the point where something will go wrong with SVN, and I almost feel like I deserve it, because I totally expected something to go wrong with it. Unfortunately, I can’t just steer clear of it because both dev teams I work with use it like armed crusaders spreading a new religion.

As for the Windows Explorer corruption issue, I have found that the TortoiseSVN shell extension does a decent job of making SVN more friendly in that department. One must admit that the third party tools are looking better (still doesn’t help SVN’s case any).

The issue remains that SVN was created as a “compelling alternative to CVS”. Personally, I’m compelled to uninstall the whole package and stick with something that has some consistency.

P.S.: the new back-end release is not much better. Without SVN, I can download a 30 meg PHP project and unzip the thing in less than 20 minutes (thousands of files). SVN took approximately 3 hours to finish the job, disconnecting every 3-10 minutes due to “inactivity”!! Server configuration issue, right?

ZabMilenko

2006/10/02

I’ve heard the hype but so far I have been underwhelmed by SVN. Having wasted the best part of two days not getting my project checked in I’ve gone back to CVS.

SVN is sold as the better and easier alternative to CVS but it is not. I can get a project checked in to CVS is minutes, SVN is like banging rocks together.

TortoiseSVN – well I’m on Windows 2000 sp 2 so it is not an option. You wonder if the authors are part of the Microsoft forced upgrade brigade.

RapidSVN – uggh, reminds me visual source safe.

Eclipse integration is not as good as CVS.

SVN feels like I’m back in the days of RCS having to use command line tools to get stuff done. The project namespace pollution of the trunk, tag, branches directory naming convention is poor. The documentation is lacking.

I dare say all these points can be addressed but SVN cannot be described as easier than CVS.

David George

2006/10/19

Just started using Subversion, using TortoiseSVN and it’s fast. There’s only one plug in the comments for a competing product, open source or not – Perforce. So tell me just what should we be using?

Praveen Angyan

2006/11/10

I sure wish I knew, Praveen.

Ian Eure

2006/11/14

What kind of idiot source control system wipes out hundreds of megs of source code by telling you the repository is “locked” and to use “clean up”, but when you try to use “clean up”, it tells you it’s locked. My only solution: Delete EVERYTHING, then try to check out again. Screw TortoiseSVN.

Matt

2007/01/06

Subversion does indeed suck — but CVS sucks far, far worse. At least SVN guarantees that your changesets are atomic and doesn’t have a buggy branching implementation (where creating a file on a branch implicitly creates it on the trunk as well), and has mechanisms for programmatically pulling history in an unambiguously parseable format (“cvs log” is not unambiguously parsable, and the corner cases are nasty). CVS tracks your repository largely as a collection of separately-versioned files; tags are applied during an iterative process rather than applying all at once; and it’s just otherwise badly broken at a conceptual level. SVN doesn’t go remotely far enough — but it’s still a big step up (and in my experience its performance is better than CVS, though not as fast as Bazaar-NG). You may need to go through a whole bunch of hassle in SVN, but at least it’s storing your project’s history in a way that’s complete and retrievable; in CVS, you don’t necessarily even get that.

[I used to be the maintainer for CSCVS, which gave me a better view of CVS's downfalls than most people get -- because I had to maintain substantial amounts of convoluted code to figure out where an individual changeset begins and ends across the individual, per-file histories; to try to heuristically figure out whether what appeared to be a separator in "cvs log" output was just an area where the user-provided text quoted previous cvs log output; to help the folks whose ,v files were corrupted understand that even though CVS looked like it was still working fine for them, some of their old history was unretrievable due to an undetected filesystem corruption which had long since filtered its way onto all their tape archives; etc. SVN may suck, but at least it stores history in a way that's mostly complete and unambiguous -- the only thing it doesn't do that it really should is merge tracking with cherry picking support, and CVS sure doesn't do that either].

If I had the budget for Perforce, I’d be implementing that. If I had good win32 GUIs for Bazaar-NG (at minimum one for Eclipse and one Tortoise-style), I’d be implementing that. I don’t have either, so Subversion it is — and I hate to see folks deciding to stick with CVS, and in doing so storing their history in a manner which will make headaches for anyone trying to retrieve it later.

Charles Duffy

2007/01/28

I know people criticise Visual SourceSafe for various reasons, but I rememer that it took me about about an hour to figure out the basic operations, i.e. 1) checking stuff in and out 2) labeling(tagging) to a named version 3) checking out from a previous version(labeled or not) and then 4) branching and 5) merging.

I have to agree with the general feeling expressed here: SVN sucks: Especially tagging?? How can tagging and branching be mixed?? It shoud be simple to tag a project and then check-out a tagged version later on, but I seem to find it impossible to figure out how to do this in subclipse

hans

2007/03/28

Jason says:
“My advice to anyone trying to write a new version control system: Find a seasoned Perforce user. Find out what they like about it, what they hate about it, and what they can’t live without. If you can’t do better on at least one count, and as well on the others, find another way to contribute to the community, lest your effort be wasted.”

I would go one step further and say, find a seasoned Clearcase UCM user, find out what they don’t like about it, and then start using AccuRev, which actually has already broken out of the file-based, branch and label approach of RCS-style source control tools. Beat AccuRev, and gain my respect. Beating something like Perforce and Subversion won’t get my attention.

Srinivas

2007/05/01

Best quote I ever saw about Subversion SVN was on Joel on Software:

“Svn is a good implementation of a model of version control which is being rapidly left in the dust.”

Confused by the hype

2007/08/01

I personally think that those of you who whine and complain about Subversion not working are the type that try to jump in without reading to understand what you are doing. I’m also sure you are the programmers that just pick up a new language by typing new stuff in the IDE. Subversion does have it’s faults but following the simple documentation to get up and running is not rocket science but it does require an understanding of what you are doing. Here are my replies:

Developer (September 16th, 2006 at 1:29 pm): You are an idiot. You get a free book available to you on Subversion (http://svnbook.red-bean.com) and you complain about the documentation? You must be a lazy ass.

ZabMilenko: Unfortunately, you are probably right. Your problem with SVN is you are probably trying to make it work like CVS which it will not. Read the red-book apendix on Subversion from a CVS user perspective and then admit in public that you were a little rushed to say Subversion sucked.

David George: If you worked on getting source code from a CVS project into Subversion for two days and were unsuccessful, you are dumber than your post. The documentation is so clear that a 15 year old Kenyan refugee could do it. Actually, a caveman could do it. Stop being lazy and read a little before you try to unsuccessfully make Subversion be your CVS and the then blame Subversion for your idiocy.

hans: I would be embarrassed to write a comment like you did. If you cannot read “svn help copy” and use it, you are an idiot. I have no problem creating a tag and then accessing it in the future. What a fricking retard…

I know the above responses may be harsh but suck it up and deal with it. If you have the stupidity to spew FUD because you were too lazy or stupid to read before acting, shame on you. For the rest of us using Subversion properly, it works fine. Like I said, it is not without fault but for all of you whining about having problems with Subversion, there are many times more of us that have invested the time to do it right and not screw it up…successfully I might add.

Anonymous

2007/08/23

The above only responded to a few but based on the comments I read, the sentiment applies to the majority of you as well. Stop being so lazy and stop trying to make Subversion work like CVS. Finally, make sure you have the facts before whining and bitching in public.

Anonymous

2007/08/23

I have to agree. SVN blows. So do 99% of the tutorials, which tell you how to set up, add, update and commit, but ALWAYS leave out deploying.

Say I need to work on 2 files in a project. According to what I have read, instead of being able to tag and export those 2 files, I’d need to publish the whole project. WTF. It’s just overkill for no reason.

jaemo

2007/12/03

I admit, I was one of those SVN fanboys for a while. But after getting these errors in TortoiseSVN and Subclipse, I’ve lost all respect I had for SVN:

Restored: C:\project\filename.GIF
Error: Failed to add file ‘C:\project\filename.gif’: object of the same name already exists

Error: Can’t copy ‘C:\project\.svn\text-base\filename.gif.svn-base’ to ‘C:\project\.svn\tmp\filename.gif.tmp.tmp’: No error

Chris

2008/02/11

To anyone who defends svn, it’s obvious you haven’t acquainted yourself with a superior system such as git. No more svn add, svn delete, etc ad nauseum. You just move files around, create, delete folders however you damn well please and git is smart enough to see your changes. I also hate the fact that svn pollutes every single directory with those pesky .svn folders. And compared to git, working with branches is a NIGHTMARE with svn.

Someone needs to put this crappy system out of its misery. It’s outlived its usefulness.

Billy Badass

2008/03/06

Over the last six months, I’ve been evaluating several SCM systems. I passed over subversion because of reports of its poor merge ability. Several weeks ago, before submitting my final report a fellow developer claimed I was wrong about several points. Worried that I had missed something, I cranked up a Virtual PC and tested it.

I was dumbstruck; it is one of the worse pieces of software I’ve ever used. I cannot understand why anyone would use this, let alone defend it. I suspect a big part is that these developers have never used anything truly capable like Perforce, AccuRev, Team Foundation or Surround SCM. And they have so geared their working style around Subversion/CVS that they simply don’t see the deficiencies.

For the record; we’re going with Surround SCM from Seapine. (No, I don’t work for them.)

(If we had a small number of huge projects, AccuRev would have been my choice, though I’ve been less than impressed with their sales and support. For a purely .NET environment, I would have leaned toward Team Foundation.)

Joe

2008/03/15

I have to agree… We moved over to SVN because of all the good things we had heard about it…

Well… it sucks bad…
I also hate tortoise SVN

But.. is there anything out there that sucks less?? or is there even something out there that can be considered ‘good’??

Justin

2008/07/11

The reason I moved from CVS to SVN is (besides not being aware of free distributed systems) that it “finally” supported multiple-files-in-a-commit. CVS sucked because every file had its own revision counter. Well, retrospectively looking at it, that’s all SVN offered over CVS. I am now a happy git user.

You Know Me

2008/07/24

Accurev sucks. The Java GUI is sloooow, bloated and buggy. The Linux CLI misses a lot of functionality (or buries it very very deeply). It is a royal pain. But hey, I’ve only been using it for six years, so I’m still a newbie at it…

BradG

2008/07/24

BradG: Every single Accurev UI feature is implemented simply by forking and execing and parsing XML output of the command line utilities. I have never (in my 6 years of using it both as a developer and as the SCM admin for my group) hit a situation where I couldn’t quickly figure out what commands to use to do something just by typing ‘accurev help xyz’. Real men don’t use use command lines, they can figure them out by RingTFM.

On the GUI. it behaves about as well as any pure Java UI I’ve ever used. Of late (4.5-4.6) I’ve seen a marked improvement in the UI’s performance. But, if you don’t have a good fast box, it will seem slow if you use the UI. But the IDE integrations work very well IMO.

Where Accurev is a dream (and why admins love it) is that it is both super easy and very flexible to administer. Coming from a ClearCase background, it was everything I ever liked about ClearCase, and none of its headaches.

Chris Boran

2008/07/24

I really wanted to like subversion, the feature list sounded good, and cvs has many shortcomings.

I recently went through a subversion evaluation.

I migrated the cvs repository to subversion. After several false starts, got it to work.

But after trying it out, it is so slow. Really slow! So slow the developers would lynch me! Checkout was about 4-5 times slower than CVS

Add to this that the both Eclipse plugins Subclipse and Subversive are weak (in comparison to the CVS plugin). Operations like compare took forever, well not forever, but so slow that it was unusable.

As I said, I really wanted to like it, but in the end, I couldn’t recommend using it.

Neil

2008/09/25

I think that a substantial number of the comments here are complaining because they don’t want to read the documentation. Many of the comments here are easily and quickly answered by simply reading the (surprisingly good) documentation. Tags and branching (on a > 500 MB repo) take less than 5 seconds. Checking out the entire tree takes about 5 minutes through a VPN connection. Tagging and branching are the same underlying operation (a copy, and a cheap, very fast copy at that), and differ only in the high, abstract sense. I don’t understand what’s so hard to understand about that. Merging isn’t really that hard at all to do (not as simple as ClearCase, but not that hard either), particularly if you’re using TortoiseSVN. I’ve never had a problem with it (though “from” and “to” don’t mean what you think they mean, which relates back to atomic commits). I’ve successfully and easily merged hundreds if not thousands of files in the span of about a year or so without any problems. I’d suggest you read the documentation.

To say that Subversion is one of the worst pieces of software ever is … complete hyperbole. Sure it has deficiencies (all software does). However, I find it substantially simpler to use on a daily basis than CVS ever was (which I used for about a year or so). I have not used git (or it’s conceptual siblings).

You version control change sets, not files in Subversion. Understand that concept, and the rest of subversion more or less falls into place. That and ditch the Berkeley DB filing system…

Satisfied with SVN

2008/10/02

You didn’t even mention the wonderful dumpfile hell. Say you have a repository with some directory that has grown huge and should be elsewhere. Easy! All you have to do is use the “svnadmin dump” command to make a massive glob of filth, make a new repository for the stuff you want to fork off, use svndumpfilter to include only the directory you want to keep and…oh hell, it is teh fail. It turns out that at some point in The Distant Past you used some files from some other part of the repository. So now you have to include the stuff you want and the stuff you don’t want from however long ago. Now you’re all set, cat $filth|svndumpfilter include stuff_you_want stuff_to_keep_svndumpfilter_from_crashing and…oh wait,

adding path : stuff_you_do_not_want/some_file …svn: File not found: transaction ‘1ff’, path ’stuff_you_do_not_want/some_file’

The awesomeness! It turns out that if the same file is created on multiple checkouts then svn knows to do the graceful thing: break the repository forever and don’t tell anyone!

But, just for the sake of pain exploration we say that the above operation worked properly. Now you have a brand new repository with the stuff you didn’t want in your other repository along with a bunch of stuff you don’t want in your new repository. Oh well, you can clean that up and it won’t take Much(TM) disk space.

Now we get to remove the directory of stuff from the original repository. To do this we DELETE THE REPOSITORY. I love the smell of awesome in the morning. Then we pipe the filth produced by “svnadmin dump” to “svndumpfilter exclude stuff_you_do_not_want” and pray to Yahweh that svndumpfilter doesn’t fall over in a burning heap of rancid failure. Which, of course, it will.

Once the entire process has failed we start over again. This time we are leaving the unwanted directory in the source directory, we will just svn delete it and it will live on forever in the repository. But it shouldn’t show up in any of the checkouts, it will just take up disk space for ever and ever.

So now we run svnadmin dump again, but we do no filtering, we dump the whole fcuikng thing. We then restore the whole fcuikng thing…

tick…tock…tick…tock…tick………….tock……………….tick….

- several years pass -

tick……….tock………

- man colonizes distant space -

……………………………………tick………………………….tock………………

And then it fails.

I realize now that I was going about the above procedure in totally the wrong way. The correct thing to do would have been to hide in the back of a closet, naked and cry myself to sleep.

svnpain

2008/10/29

One word…. CONFLICT…
Non stop bloody conflicts. I hate and despise subversion.
Having to update continuously, and my project file conflicting non stop because it’s been updated elsewhere.
Work around? Revert your change, update your project, change your project again – THEN commit.
Our whole team has to tell each other not to work on files just in case the merge doesnt’ work and files conflict.
And the argument by lovers of subversion that “we’re all doing something wrong”, is poor, since i’ve never faced this problem with other source control solutions.

Tups

2008/12/18

SVN is witout a doubt the crappiest piece of software I’ve ever worked with..I had very little problems with CVS (used it for 2.5 years) but with SVN there are problems every day. It’s slow as hell, it gets corrupted all the time, it’s totally unusable

Bas

2008/12/19

SVN sucks! Totally slow, atomic commits are good in theory but in reality the tool is so broken that I need to break up my commits if they involve lots of files since otherwise svn blows up partway through the commit and all the progress is lost (our network sucks in this respect but vs. cvs the svn tooling is far less stable and more prone to problems when the network drops or the hickups occur).

Mrx

2009/01/05

http://git.or.cz/course/svn.html -this piece of information was enough to setup and use git. I will never ever touch SVN again.

“Developer (September 16th, 2006 at 1:29 pm): You are an idiot. You get a free book available to you on Subversion (http://svnbook.red-bean.com) and you complain about the documentation? You must be a lazy ass.”

There is 383 pages in that book. I am a lazy ass and I don’t have time to read books and cryptic documents about poorly designed features. And I don’t have time to wait for hours SVN doing simple merge and then failing.

Another Developer

2009/01/18

I’m a release engineer, and have managed source code control systems in CVS, ClearCase, Perforce, and Subversion, and am currently using the last one, which I also used at my last job. I hate it for all the reasons listed above, but primarily because it is o-h-s-o-s-l-o-w. Plus the stupid .svn folders everywhere, and the text-base copies the effectively double the size of your checkout. I’m pushing hard for the company to spend the money on Perforce.

One with perspective

2009/01/21

Chris Says:
February 11th, 2008 at 7:05 pm
I admit, I was one of those SVN fanboys for a while. But after getting these errors in TortoiseSVN and Subclipse, I’ve lost all respect I had for SVN:

Restored: C:\project\filename.GIF
Error: Failed to add file ‘C:\project\filename.gif’: object of the same name already exists

And you’re a moron for 1) using a non case-sensitive filesystem and 2) not recognizing what was happening. How exactly is svn supposed to store both files when the filesystem itself won’t?

nobody

2009/02/05

I have been working with subversion, clearcase, UCM, dimensions.
If You think that SVN sucks it means you didn’t use any others :)
Believe me SVN is not as worst as dimensions is.

SVN can also be fast – Berkeley DB is one of the fastest database in the world – but only need a dam-good-fast hardware with Tera Byte disks. To keep the SVN in reins You need to freeze the code once a week – to avoid any database problem too.

I prefer basic clearcase for all proposes is one of the most logic, easy to learn and use and really fast. All versions are easy available due special file-system.

I’m not recommends UCM – why – it is too powerful – with this power – too complicated for developers which causes many administration problems.

I’m not recommends Dimensions – has totally different point of view – un-logical, hard to administrate, very slowwwww, and is poor comparing to base clearcase.

Vic

2009/04/06

Without a graph feature, how can SVN really replace CVS?

Also, it’s really sucks that changes are not updated/reflected even if you commit the changes 5 mins ago, it still shows RED in windows explorer, which means still changes not commmited . This really makes me, a developer , more than mad with SVN.

Dennis

2009/06/12

I just love this SVN error :

This client is too old to work with working copy xyz’. You need
to get a newer Subversion client, or to downgrade this working copy.

I havent changed svn version on the server and my client version neither.
It just appears from time to time and it really freaks me out :/

Vigour

2009/06/15

Vic Says:
> If You think that SVN sucks it means you didn’t use any others :)
> Believe me SVN is not as worst as dimensions is.

Sure you can find something even more crappy than SVN, but if you do
not think that SVN sucks, you clearly have not tried anything that has
a clear and solid design such as Git.

SVN, being released about 15 years later after CVS, offers very little
improvement over its predecessor (or more precisely it does offer some
improvements but they are complemented by some other features such as
slowness, mind-boggling tags/branches implementation, etc…).

So, while SVN may not be the worst VCS out there, it will always remain
the momentum of mediocrity. Whoever wrote that system apparently slept
during the classes where the difference between version control systems
and revision file systems was explained, or why you never want to use a
database to implement a file system over it… and that is only the
beginning of the long list of mistakes…

Looking at SVN, it is difficult to believe that it was meant as a clean
replacement to CVS, which has been developed for years. If you want to
know what difference a clean and solid design can make, I will give you
one:

It took about two years for Subversion to become self-hosted, and it was
only 5 days for Git to become self-hosted, and two weeks later it already
hosted the Linux kernel and was capable of doing merge, something that
SVN still has not learned to do correctly.

And anyone who think that SVN is capable of merge are welcome to try –
get something that uses merge a lot, like the Linux kernel, and try to
repeat that in SVN. Good luck with that! (I am sure you will find
something new and interesting to add to already lo-o-ong list of merge
related bugs in Subversion).

Yet, looking at what crappy VCSes are still used in the corporate world,
I believe that SVN got a chance there, and its developers can continue
to write books like “ScrewVersioN: a new generation of SubVerisoN”…
So far, they got more success with writing books than code…

Tired

2009/07/13

Yeah I too feel like subversion SUCKS !!! coz I did face many problems for a simple merge

If a file is modifed or even some text appended at the last of the file it shows a conflict ,I am bored of solving the conflicts
Will throw up the svn and may be have a look at Git or so

Subramanyam Vemu

2009/07/22

What I find amazing about the comments on this list is complete and utter ignorance. None of you have obviously written a source code control system yet alone understand developing complex mature systems.

Git, Mercurial, Subversion, Bazaar plus many commercial products all have their place. The general problem with DVCS at present is their immaturity. Basically toys at present for girls and boys still in the bike lane.

John Kamp

2009/09/07

At the end of the day what the people complaining on this list want is something that just works. I have used many SCMs over the years and I have to admit that the only one I hate is SVN. Some of you like to call people morons because they didn’t read the documentation. I have not had to read documentation for any other SCM ever because they just worked.

I have used SVN a few years ago because our group changed to it because it was free. After about 6 months of using it we voted and swtiched back to Perforce because: “It just works”. That is all a developer really wants out of their SCM.

Now I am using SVN again in a new role. Not surprisingly, after over 5 years away from SVN and only about 30 minutes into using it to move a small directory structure around and it has shat upon itself again. I once again find myself copying my materials to another folder, deleting the SVN-protected folders, checking out the files again, and copying my changed files into place. This is an occurrence that happens all the time, and is completely unacceptable for an SCM. Not to mention that it costs me a ton of productivity! I have never had to do this with any other SCM.

I am in the Enterprise Software development world. Much of the coding we do is centered around ensuring that errors don’t occur or are gracefully handled. That is where SVN falls flat on its face. It just doesn’t give a crap if you didn’t read the precious manual perfectly because you had real work to do. Now I am forced to read a 383 manual for something that should be intuitive to some degree. I have a feeling that even after RTFM I will still feel the same way… probably worse as I will have wasted 1-2 days of my life reading a stupid SCM manual after over 15 years in the business. That is what is retarded about SVN. Clearly by looking at the posts on this site and others there are a ton of people who agree.

Has Real Work To Do

2009/10/15

I think many of you misunderstand the differences between the repository and the working copy. Let’s say you make a repository with a “trunk” folder whose contents (minus the .svn folders) takes 500M. You can create 100 tags/branches/copies/whateveryouwannacallit at the repository level and the repository will only increase in size by a very small amount (mostly dependent on if you committed 100 times, or if you did it in a way that only cause 1 commit). If, on the other hand, you checkout the root of the repository, you’ll require 50,000M times two (because of those .svn folders). But the **repository** only stores enough information to say “folder x is a copy of folder y at revision z”.

Many people also seem to have a hard time with branches, or tags, or whatever. The basic idea is that SVN thinks of things in terms of a **LINUX** filesystem. All files are case-sensitive. Paths to files are stored, and those paths can change over time and the files (technically part of the path) can also be changed, but all the history sticks with it (provided you’re smart enough to tell SVN that you’ve renamed the file, instead of just renaming it and deleting the old one). When you start trying to use it on a case-INsensitive filesystem such as those used by Windows, you can run into problems if someone starts creating files with mixed-cases… for instance: if you create FileName.GIF, and another person manages to rename it “filename.Gif”, someone will invariably have problems because SVN tries to rename your local file but the Windows filesystem won’t allow it. Try creating a file on your Windows machine like “FileName.GIF” and then make it all lowercase… good luck. The Linux part of the equation is important: on a Linux webserver, if you pull up “http://crazedsanity.com/images/dev-logo.gif”, then try “http://crazedsanity.com/images/dev-LOGO.gIf”, you will get an error as the files aren’t the same. I’m not sure how IIS handles this, but Linux is very case-sensitive. You can literally have the two afore-mentioned files (“dev-LOGO.gIf” and “dev-logo.gif”) sitting side-by-side without a problem, but Windows can’t. If someone in Linux added and committed files like that, the Windows developer would have all kinds of problems.

As far as merging, or branching, or tagging, or whatever you want to call it: its all just folders. Create a copy of one folder and you’re just creating another folder. The repository stores them in a very efficient manner. If you create a branch off “trunk” (a commonly used term, but **not** required): create it on the repository side so the server does all the work. When you want to work on that branch, use “svn switch” to change your workspace to point to that branch and have all the data from that branch: it will only change files that need to be changed and leave everything else. If you do the switch with local changes, you might be in for some trouble, but the developers of SVN kinda assume that you’re smart enough to know what you’re doing.

And finally, don’t go freaking out about how bad Subversion is when you haven’t read the book or you’re using some shitty program to work with it. If you’re using Eclipse, checkouts and commits will take extra long, but that has **NOTHING** to do with the repository and **EVERYTHING** to do with the code that is doing the interacting. I can do a checkout through TortoiseSVN or Linux CLI 10 times faster than Eclipse. If you start bitching about Subversion, make sure your problem is **actually** Subversion and not PEBKAC or some middleware you’re using.

CrazedSanity

2009/10/20

Why are you people so down on svn? It’s a wonderful product and has enhanced my productivity to levels that I hadn’t imagined possible. Just the other day when “svn commit” was running I had time to go to the bank, get gas, get a haircut and grab a quick lunch. All of this was on billable hours. Do you think that I could derive such benefits from git? I think not.

“You didn’t even mention the wonderful dumpfile hell…”

Ah yes, svndumpfilter. What a fantasmagorical source of bliss that tool is. Just type the words “svndumpfilter” and “impossible” into google to get an idea of the playground that is svndumpfilter. And don’t wait up for those insane error messages, perfection takes time.

Hortence The Dog-Faced Girl

2009/11/17

I’ve been using SVN for years, mostly without too many problems. But recently, I’ve hit serious issues with large (>15G) repositories taking a *long* time to ‘update’ or do a ‘ci’. This is affecting my (and my group’s) ability to do our work.

So after investigating, I found “Fossil” — written (and used by) the guy who wrote SQLite. Check it out here: http://www.fossil-scm.org/ . It is free, robust, and easier to use than SVN in many regards. It is a cinch to set up on a server. Doesn’t pollute your directories (just a couple files in the root of your working set, not part of the actual check in).

It’s not as fast as “git”. But it is *much* easier to understand and deploy, and it works on Windows, Linux and Mac OS/X (among others).

ron

2010/01/31

Participate

Name (required)

Mail (will not be published) (required)

Website