I agree that it would reduce the number of things that can go wrong.
Launching processes from Java is certainly not very robust. There's also a few
things we can do better if Hudson speaks the CVS protocol directly (like
tagging the workspace post-facto can be done just from a control information.)

OTOH, there's a prioritization issue. There are a lot of other things that
could be improved, and Hudson will still have to launch processes
even if we internalize cvs and svn, people still have to have Java, Ant, and
Maven installed, etc. Since launching external cvs/svn works good enough for me,

So I guess I'm not too sure if this is a high priority issue, and as such
I'm bit hesitant to spend my time on this.

If there's a particular pain that motivated you to file this bug, I'm very
interested in learning those and implement additional error checks or diagnosis
code to ease those pains.

Or, would you be interested in participating in the development of Hudson ?

reassigning this one to myself

http://svnkit.com/ seems to be getting a traction, so perhaps that could be
something worth considering.

Starting 1.74, Hudson uses svnkit. So the only remaining work for this is CVS
(if we ever decide to do it.)

this is great news kohsuke.
I've deployed the 1.74 snapshot but I get an exception when hudson attempts to
retrieve the bits...

type Exception report

message

description The server encountered an internal error () that prevented it from
fulfilling this request.

exception

javax.servlet.ServletException: java.lang.NullPointerException
org.kohsuke.stapler.Stapler.invoke(Stapler.java:233)
org.kohsuke.stapler.MetaClass$9.doDispatch(MetaClass.java:207)
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
org.kohsuke.stapler.Stapler.invoke(Stapler.java:224)
org.kohsuke.stapler.Stapler.invoke(Stapler.java:169)
org.kohsuke.stapler.Stapler.service(Stapler.java:68)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)

root cause

java.lang.NullPointerException
java.util.StringTokenizer.<init>(StringTokenizer.java:182)
java.util.StringTokenizer.<init>(StringTokenizer.java:219)
hudson.scm.SubversionSCM$DescriptorImpl$1.check(SubversionSCM.java:589)
hudson.util.FormFieldValidator.process(FormFieldValidator.java:33)
hudson.scm.SubversionSCM$DescriptorImpl.doAuthenticationCheck(SubversionSCM.java:587)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:50)
org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:59)
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
org.kohsuke.stapler.Stapler.invoke(Stapler.java:224)
org.kohsuke.stapler.MetaClass$9.doDispatch(MetaClass.java:207)
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
org.kohsuke.stapler.Stapler.invoke(Stapler.java:224)
org.kohsuke.stapler.Stapler.invoke(Stapler.java:169)
org.kohsuke.stapler.Stapler.service(Stapler.java:68)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)

this happens consistently when I create a new job

but the integration of svnkit seems to get going and that's just great!

NPE fixed. The change should be in snapshot 2015.