On Sat, Jun 09, 2007 at 11:04:33PM +0200, Henrik Sundberg wrote:
Release numbering: I noticed release numbers like V00-01-02. Is the format mandated by svn's/other tools' inability to sort lists numerically instead of alphabetically? Is this the format Boost versions ought to have?
No, that's legacy stuff that I can't get rid of for political reasons. I don't have a proposal for what format version names in boost libraries should have.
Tags/Releases: Are all releases releases, or would the more anonymous name tags be better?
Eh, I don't think it is terribly important. It is easy to change.
Meta-projects don't nest: Would it be very cumbersome to have meta-meta-projects (this is what we have in our system)? Is this related to the next point?
That metaprojects don't nest is due to how svn works. There is talk of svn:internals, which sounds good, but iiud it isn't going to happen right away. So for now metaprojects dont nest.
Branching multiple projects can be tedious: You seem to lack a tool here.
It would be easy enough to write. This isn't related to hook scripts, it is all client-side. SVN has good python bindings, you could do it all in python.
Trunk-level: Do you have a private meta-project referencing the trunks of all projects you (as a developer) are working on? Is it in such directories you can use "svn commit *" to commit over externals boundaries?
Each of the main metaprojects have a trunk. That is where we work, primarily. Simultaneously there may be arbitrary numbers of other private metprojects floating around. I have a couple right now.
Could private meta-projects be avoided by having the trunk/releases/branches at the svn root level instead of at the root of each project? Or would this force you to check out all or just one project to a local directory?
This 'inverted' structure has several disadvantages that were discussed. You wouldn't want to avoid 'private' meta-projects. They are one of the main features of the system.
Sandbox: Is the structure inside the sandbox completely free? I.e. anyone can have internal releases there, so checking out the complete sandbox would cost a lot disk space?
You would never have a reason to check out the whole sandbox. This is a physics experiment. The sandbox is freeform. There are probably a lot of metaprojects floating around in there in private areas.
Should at least the top directories in the sandbox follow some naming conventions?
It could. Usually somebody sends out "Hey check out my such-and-such project" to the mailing list with a url in the sandbox. So you're never trolling through there randomly looking for stuff. The boost sandbox probably should have more structure.
Externals: There are several threads hinting at problems with svn and externals.
I haven't read any that said anything I didn't know already. One was about having an external embedded deep in your source, and when people branch their code, they forget to branch the external. This doesn't happen when externals are used as a primary code organization techinque and everybody is aware of them. The other was about http vs. https in externals, and this is trivial to fix.
Have you seen more problems than tedious branching, the need for
Branching is tedious when different components become coupled and changes have to span multiple components. Otherwise it isn't really.
Internals and non intuitive commit (and perhaps meta-meta-problems)? Are you satisfied with the use of externals overall?
Very. I wouldn't propose it otherwise. -t