Anyone use Subversion?

[unixronin]

I’m having my first experience with it for a client, on a Debian system.  With a choice between svn and git, we went with svn for the client because it’s supposedly very similar from the user viewpoint to cvs, thus much of my cvs knowledge would be handy when it came to advising the client.

That was the theory.

Setting up and creating the repository went fine.  Adding the project codebase into the repository went fine.  The client’s first major commit failed because .svn directories had become corrupted.  Turns out it’s a known problem.

I set about fixing the problem by the documented workaround ... and ran into another known problem in which svn checkout repeatedly exhausts the system entropy pool and hangs.  I’ve been trying for a day and a half to get a copy of the project checked out so that I can fix the problem of the corrupted .svn directories.

There’s a reported workaround for this problem, too; if svn’s been built to use /dev/random, try moving the real /dev/random and symlinking /dev/random to /dev/urandom.  I’ve tried it.  It doesn’t work.  I’ve tried all the tricks I can think of to try to generate additional entropy in the background, and that hasn’t helped either.

Is this anywhere close to a typical Subversion experience?  Because if it is, I have to say that on the basis of this experience, I cannot possibly seriously consider Subversion to be ready for production use.

Comments

[brownkitty.livejournal.com]

There's a flavor of Linux named Git?

[perspicuity.livejournal.com]

no. nor svn. these are source code control tools.

#

[brownkitty.livejournal.com]

Thank you.

[mrmeval.livejournal.com]

Git is another source code manager, CVS is like the pharmacy it would be worth something if it sucked, SVN works for some folk but if unixronin's experience is common it isn't even that good.

Linux is the name for the kernel, all else is 'hung on' it to make a working system. Git is used by the creator of the kernel Linus Torvalds to manage the kernel. It does that role well. It may or may not do other projects well.

These programs can manage any text based project spread across a lot of people. You could use it to write a text book or a novel. Final output will suck as badly as some source code. :-P

[ithildae.livejournal.com]

Did you look into any of the discussion of why the linux kernel developers moved to git? I know part of it was license issues, but I thought there were technical issues also. (I use and old, commercial system. I never got the linux native versioning systems to work right for me. It has been years since I tried.)

[perspicuity.livejournal.com]

the short form is "that's what Linus wanted to use, period" :)

i've never seen these issues with SVN, nor have i heard of these issues, and have used it for years.

perhaps you could use a "live CD" type linux boot, and use THAT to check out successfully. in other words, it could be YOUR installation of linux, not svn. just a thought.

#

[unixronin.livejournal.com]

The machine holding the repository isn't under my direct control and I don't have physical access to it, so that probably wouldn't work too well.

[perspicuity.livejournal.com]

mount the svn directories remotely and bypass that particular OS entirely?

and/or is the svn installation "up to date"?

#

[unixronin.livejournal.com]

Everything's up to date. The machine was only set up a few months ago.

[ithildae.livejournal.com]

Sorry, I miscommunicated, again. I use linux. I have used linux for years. I use a DOS based version control system, PVCS. I like it, and it runs well under linux in a DOS window.

I have never really put the effort into making a native version control systems work after a basic compile and attempt to get the configuration correct. I have something that I like, and it works for what I need. If I were to start doing serious development again, I would put in the time and effort to get it right. There is no driver to do that at this point.

My choice would be to use something that is active in the OSS community, since I have no previous bias.

[unixronin.livejournal.com]

There were indeed technical issues, speed among them. I don't remember what the other issues were.

[unixronin.livejournal.com]

Having now looked up the history, basically there were two reasons why Linux kernel development moved to git:

(1) Speed.
(2) Linus felt strongly that CVS was the perfect ideal of how NOT to build a source control system, and no existing source control system met his requirements for how one should work.

[paxed.livejournal.com]

I haven't encountered anything like this (and I do use Debian), but my svn usage has been limited to a handful of small personal projects.

[purple-dj.livejournal.com]

... Wandered over this way from a conversation with some Gweeps ...

I've been using svn for a good while now, and can't say I've ever bumped into your problems. Not that knowing that helps you solve them, but they're not typical.

Can you login to the machine hosting the repository and try to do a checkout using a file:// URL instead? It uses many of the same mechanisms, but will also bypass a bunch and might possibly help with the lack of randomness issue.

[unixronin.livejournal.com]

It hadn't occurred to me to try a direct file:/// checkout, having set it up to use svn+ssh via svnserve. I just tried it, and that does indeed totally bypass the problem. I'd still like to know why it's happening in the first place, though, but the important thing is to be able to make it work right now.

[guppiecat]

I've been running subversion professionally for the last five years and have never once experienced the problems you describe.

I occasionally had a repo corrupt, but this was more due to running on ReiserFS than SVN itself. The corruptions ceased when we moved to EXT3.

I like SVN better than GIT because we have no need for distributed version control, and we really like the pre and post hooks that SVN offers. I also like it better than CVS because of the advanced tagging and branching that SVN supports.

To answer ithildae's question, the Linux kernel has different needs than most development and checking in patches from multiple sources simultaneously is more important than centralized control. Apache and Rails have similar development models. Most businesses are better served with SVN.

[gdmusumeci.livejournal.com]

Git supports pre and post hooks -- I use them extensively. Git branches are also extremely powerful once you get your head around them.

[ithildae.livejournal.com]

Thank you! I just saw the high points of the chatter and never looked deeper, I had no need at the time.

[echristo.livejournal.com]

We use subversion very heavily at work in a production environment. I've never seen the problems you're describing.

[unixronin.livejournal.com]

So many other people have said. I can only conclude that there's something weird on the hardware on this machine, or something misconfigured.

[metahacker.livejournal.com]

Git definitely is a different beast. svn is a smaller step from cvs. So on that front, I think the original theory was correct.

Other folks have covered the "this is not standard svn behavior" angle.

[cipherpunk.livejournal.com]

I’ve used Subversion for years, and have never run into this problem. It is not representative of my Subversion experiences, which have so far been quite painless after a decade of use.

[unixronin.livejournal.com]

I've pretty much concluded something HAS to be funky on the client's dev machine, where the repository resides. They said it was old hardware — I'm wondering if it's old enough to not have a hardware prng, but their Debian install assumes it does. SSH has sometimes been a bit sluggish ... maybe svn+ssh just overwhelms its ability to generate entropy. Yet the client's initial checkout apparently went OK.

[mrmeval.livejournal.com]

What hardware would have a built in prng?

[unixronin.livejournal.com]

Many modern processors have a built-in hardware PRNG device. I think you'll find pretty much any UltraSPARC or Athlon or newer general-purpose processor has one.

[robbat2.livejournal.com]

Actually, I ran into something interesting with crypto hardware recently.
Namely, one of the nicer Hifn cards: crypto and rand from the card were SLOWER than than in software on the quad-core Opteron. While the latency on the cards is lower when you're doing a few operations, the overall bandwidth of the card for operations on large blocks of data is worse.

[unixronin.livejournal.com]

Interesting. That's comparable to a lot of older hardware RAID cards being slower than host-based software RAID on modern processors.

[robbat2.livejournal.com]

I'm pretty sure the urandom/random issue was solved in APR years ago, but maybe the client built it themselves on this box. Note that it's the apr lib that needs changing for it, not the svn binaries themselves.

[unixronin.livejournal.com]

Nope, standard off-the-shelf Debian packages, installed a couple of months back.