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