It is not "the point" but 2 points. First point is the svn layout and so far i have not written a word on that. And i concur that a split between those parts is a good idea because they are different tasks and are not closely coupled. We can see this separation already present in all areas (targets, doc, forum, ...) and even in svn as the directory structure separates for example the maps from other stuff. So if you want to update just part of the code, then "cd src;svn update" should do. But this doesnt work in all scenarios so I am looking forward to a more formalized splitup.
The second point being the long times for maps compiling.
So now I have to recompile all these maps... and so does anybody else using SVN. Lots of needless time and annoyance all-round.
Apparently the non annoyed svn users just dont recompile their maps. For over a month i have only been looking in the game code and thus didnt need to recompile the language files nor the maps. As shown you can get bootstrapped fast by the mappacks. So all in all, the long time for compiling maps is a problem with a magnitude several orders less then you make it look like.
UFO:AI which has multiple dlls and gtkradiant.exe
Executables in svn? Of course, they ARE the source! Maps are NOT because they are a derived product, we can compile them again from any revision we d like to. source >< derived. source in svn, derived not in svn. The difference between source and derived products IS simple, if you are not confused by the form in which it is delivered. So this svn repository *does* handle source only.
What if you *never* want to compile a map and also *always* want the latest maps? In this case the system fails but i cant see any legit use case for it. The only thing that can solve this is to commit the compiled map for every change to svn. Version control for binaries is, as i put before, of little value. It also breaks the consistency, the integrity of the database subversion! Because for every compiled map is depending on other sources but that cant be made explicit. It does not make sense at all to throw this away for it is the purpose of svn to ensure this. Thats one reason why the first rule of svn is "source only".
All in all:
*subproject already exist but svn is not splitup.
*you dont have to spend a lot of time compiling maps
*the big elephant problem is actually a small mice and the cure for this small improvement has a very high price.
*svn is not what think it is