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

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