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

Re: svn suitability for large monolithic code bases

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Wed, 23 Apr 2008 21:42:57 -0400

"Ian S. Worthington" <ianworthington_at_usa.net> writes:
> I'm having a problem deciding on the suitability of svn as a replacement
> library system.
> Our project consists of several thousand programs and several hundred include
> files. Currently developers select the ones they need, check them out, noting
> possible conflicts with other developers who have also got those elements
> checked out, do their work, their testing, then check them back in. From
> there they are loaded on a test system for a few weeks before finally being
> promoted to production.

Yes. See also


for how developers can notify each other about who's working on what.

> If I understand it correctly, the first problem I see is that with svn is that
> I couldn't check out individual elements, but would have to check out dozens
> or hundreds of elements depending on how fine-grained the containing
> directories are structured.

Yes, though see


...for an improvement to this in upcoming Subversion 1.5.

> This then leads to other developers not really knowing what elements
> are being updated and the possibility of being blind-sided at check in
> time, which would cause project delays.

No. Merely checking something out doesn't mean changing it -- the
amount you've checked out may be much greater than the portion of it
that you actually modify. Only the things you modify can cause
"conflicts" (the term of art for the blind-siding you refer to).

> Given svn is in such widespread use I wonder if I've missed something
> in the documentation. Is there some way of avoiding this problem?




To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-04-24 03:43:37 CEST

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