[Tdg] Code commit

[Rama Hoetzlein]

some thoughts..

>I think it should be more like
>
>core/{branches/, trunk}
>core_easy/{branches, trunk}
>audio_system/{branches, trunk}
>documents
>etc.
>  
>
- how often will branches occur?
- while a future incarnation of mint might warrant such flexibility (to 
independently branch libraries), are we there yet?
- how important is it to be able to branch a library early on? (we can 
also add this later, while it introduces more complexity now)
- who keeps track of which branches are compatible with one another? 
(not it)

>basically, each system, while they require the core, is an independent project, and should be separated as such. [have their own makefiles, etc] early in this project we talked about this, we don't want to require all the libraries, well, we shouldn't build our project up like that either.
>  
>
- to be precise, to build an app or library doesn't require linkage of 
all libraries.. yet each library does depend on the core. how do we 
define "independent" in this context (ie. in relation to versioning, 
branching, etc.)?
- while there are multiple projects, are they so independent of the core 
that we would conceive of versioning and branching them this early on?

>Also, what's with all the folders in core?
>I assume the platform dependent stuff might go in a "platform" folder, but most folders simply have 2 files, a header and an implementation file, it is pain, It makes more sense to me to have all of these implementation files in a "source" dir [possibly excluding the platform dependent stuff], and all of the headers in a "include" dir.. or hell, put them all together... that would make life of makefiles easier, and, the core shouldn't be that big, so managing 1 "source" directory won't be a problem.
>  
>
- what happens when memory_pool (or event_queue) for example, which is 
currently 2 files, develops multiple subclasses?
- do we want all the subclasses of logical groups (memory_pool, etc) to 
be flat listed in a single folder? for example, all subclasses of 
memory_pool to be in the same folder as all subclasses of event_queue 
and application, and timers subclasses on different platforms?

>so I propose we do this:
>svn/core/branches/source/[all the cpp files for core]
>svn/core/branches/include/[all the header files for core]
>  
>
- makes sense if there is just a single folder for each library. do we 
really want this?
- if we do group "components" (such as memory_pool, event_queue) into 
folders, would it be better to keep the .cpp and .h files together or 
use some other structure (two folder trees, folder tree for cpp but not 
for .h, single folder tree as we currently have)?

questions we have not really addressed until now i suppose. i'm not sure 
i could address all these myself now anyway - not only because i can't 
yet forsee their impact, but because i have to finish my thesis, among 
other things.. on a personal note, nothing is perfect the first time. 
and we can't forsee everything. i would prefer to stick with what we 
have for now, do makefiles (PS. i spent weeks building vs projects), and 
move onto coding... then come back and revise later as i'm sure we'll 
need to do anyway when we have a clearer picture of what we really want.

rama