[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Fixing "checkout -N"? (possible contracting gig)

From: Steve Johnson <steve_at_Equilibrium.com>
Date: 2005-11-10 06:56:59 CET


I lead a team of developers who work remotely and who often work only on
specific portions of our single, rather large source tree (15 years of
development, 12 products * 4 platforms). We had been using CVS for
years, and then switched to Subversion about 3 months ago.

Unfortunately, I did not know about the broken "checkout -N" issue that
exists to this day (Issue #695) when I championed the switch to
Subversion. My engineers grew to rely on the similar feature in CVS to
limit checkout and update times. I am now getting a lot of grief from
my engineers, as they are forced to checkout and update our entire
source tree. The initial checkouts aren't so bad, since those are only
done once and disk space is cheap, but updates and checkins are taking
significantly longer that with CVS as well.

This problem is affecting our development in a number of ways. We do a
significant number of automated nightly builds, and the need to check
out our entire source tree over and over again is affecting our ability
to complete those builds in a timely fashion...a problem we never had
with CVS. We're now hesitant to add larger files to our repository for
fear of making initial checkouts take even longer.

Isn't this issue driving other users crazy as well, especially former
CVS users? I find it hard to believe that there isn't a deafening roar
regarding this issue. How can this bug have existed for so long? Is my
company's practice of fostering code sharing by keeping everything in a
single repository not generally done when using Subversion? There
surely must be much larger companies than ours using Subversion. How do
they get around this problem? Or are we missing something...are we
making a bigger issue out of this than we need to?

The bottom line is...unless we can be enlightened as to how to rethink
our use of Subversion in developing and delivering our products, we
REALLY need a fix to Issue #695!!! It has come to my attention that a
fix might not be coming any time soon given the current course of
things, so I'd like to solicit some help in changing that course...

Would anyone with the necessary knowledge of the Subversion codebase be
interested in taking on a contracting job to, in effect or in actuality,
fix Issue #695? Not knowing the code, I have no idea what kind of time
we're talking about here, but I'm definitely open to throwing some money
at this problem. In addition to solving our need, it would be cool to
be able to give something back to the open source community by fixing
this problem.

If anyone thinks they could do this and wants to discuss such a project,
please send me an email. And of course, if any of you have suggestions
as to how we can mitigate our pain regarding Subversion, please please
please do not hesitate to enlighten me/us.

Take care all!

Steve Johnson
Vice President of R & D

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 10 06:57:46 2005

This is an archived mail posted to the Subversion Dev mailing list.