Re: [boost] Organizing a large project with svn:externals (Was: Boost Development Environment proposal)

From: troy d straszheim (troy_at_[hidden])
Date: 2007-06-16 16:57:35

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