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

Re: Is SVN ready for use?

From: Noel Yap <yap_noel_at_yahoo.com>
Date: 2002-12-10 16:06:52 CET

--- "Ketil Z. Malde" <ketil@ii.uib.no> wrote:
> Noel Yap <yap_noel@yahoo.com> writes:
> > A good portion of the build breakage is due to
> developers forgetting
> > to checkin a file, most likely a new file they
> forgot to add to begin
> > with.
> This happened a lot when we were using VSS, where
> everything is
> file-based. I don't have the same kind of
> experience with SVN/CVS,
> but it seems using top-level update/status/commit
> eliminates most of
> these.

We're using CVS. I believe the bottom line is that in
our environment, developers aren't properly trained in
development processes or, rather, there aren't any
established corporate development processes to be
trained on :-(

> The flip side of the coin is that when you start
> modifying a file,
> VS/VSS will check out the latest file from the
> repository, which may
> not match the rest of your files, possibly (i.e.
> quite often) breaking
> everything.

That's crazy. I've been lucky enough not to have used

> The lockless model prevents this (although you
> eventually will have to
> do the merge, of course).

I have almost no argument here. I think having an
advisory locking mechanism (<blatant-plug
off-topic="true">see the CVS patch available on
SourceForge under project RCVS </blatant-plug>) will
give more control for those shops that want it.

> > Part of our problem is that the code base is so
> large that any build
> > break is a large build break
> Regardless, the smaller the checkin is, the easier
> it is to point at
> the bug. (But, yeah, it does sound like you have a
> process problem,
> not a technical one.)

I was unclear with my prior post. What I had meant
was that the product is so large that what really is a
simple breakage isn't so simple when it's broken
within the 99% of the product which is unfamiliar.

The problem stills boils down to process, though.
IMHO, our one product should be broken down into
several products each with its own release cycle --
build breakages would be taken care of by the
developers of the subproduct before it gets released.


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 10 16:07:35 2002

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