Re: svn suitability for large monolithic code bases

"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

   http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html

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

   http://svnbook.red-bean.com/nightly/en/svn.advanced.sparsedirs.html

...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?

See

   http://svnbook.red-bean.com/nightly/en/svn.basic.vsn-models.html

-Karl

---------------------------------------------------------------------
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