svn suitability for large monolithic code bases

["Ian S. Worthington" <ia...@usa.net>]

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.

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.

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.

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?



ian 
... 

Ian S. Worthington, MBCS.

me:     http://isw.me.uk/ 
photos: http://gallery.isw.me.uk/ 

Dulce et decorum est pro patria mori, sed dulcius pro patria vivere, et
dulcissimus pro patria biber. Ergo, bibiamo pro salute patriae.




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svn suitability for large monolithic code bases

[Karl Fogel <kf...@red-bean.com>]

"Ian S. Worthington" <ia...@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org