The practical upshot of this being that as I change things I just commit them to the main trunk and be done with it. Beyond that I had no real understanding of project organisation with SVN.
However a short time back now someone else showed an intrest in getting involved with GTL, mostly with bug fixing, and to that end they suggested a layout for the SVN. While it looked much like other projects I've seen I'd never really given much thought as to 'why' they were layed out as they are.
A quick reading of the SVN online book and I get it enough that I can now understand the whys of it all.
So, the SVN has been remade, with branches and tags now floating about the place (ok, so the tag isn't completely 2.1 as it claims, but it's close enuff), I've even hooked up a couple of mailing lists; one for dev discussion and one for SVN commit logging.
Granted, it's only a team of two or three (depending on if someone else who was using the lib and sorted out the Linux and OSX builds wants in or not) but who knows, maybe others will jump onboard and that means this setup will be useful.
It also means that, when I start work on 3.0 I'll
a) have somewhere to dump ideas list wise
b) have a sane branch system I can use to build the project from the ground up.
Nice... maybe I should do this with OGLWFW as well [grin]