How should multiple (related) projects be arranged (structured) and configured so that they can share code, have a related package structure and enable proper unittesting, and ensuring no namespace collisions

[Eric S. Johansson]

alisonken1 wrote:
> As to the question "fail to see how version control relates to
> code/test separation", the original poster asked several questions, one
> of which was production/testing code separation.
> 
> Along with the separation (so while you're testing new functionality,
> you don't break production files), a properly setup CVS allows you to
> do this by importing files from a production branch into your testing
> branch so you can re-use vetted code (production) in your trial code
> (testing) without affecting what's already out there (inadvertently
> breaking currently shipping code to customers).
> 

since I'm a wandering through the same paths, I would also point out 
that in addition to proper code management, I'm really coming to believe 
in the value of sand boxes or even complete virtual machines as part of 
your testing/production cycle.  Unfortunately managing all the source 
code is still a bit of a CF (and I don't mean CompactFlash).  I have yet 
to find a distributed configuration management system that works in a 
way that's a comfortable fit with how I work.  darcs is the closest so 
far but even that is a bit unwieldy.

I must admit however that part of my discomfort with development 
techniques and methods comes because I am dependent on speech 
recognition.  And thanks to ScanSoft's (now nuance) inability to make a 
speech recognition application that can dictate sanely into 
non-Microsoft applications, I must jump through hoops to write Python on 
a UNIX box (NT Emacs + Webdrive).  As a result my perspective is colored 
by my handicap in the same way the TABS experience colors your perception.

---eric