|
Boost : |
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2007-06-17 11:01:07
troy d straszheim wrote:
> On Sat, Jun 09, 2007 at 11:04:33PM +0200, Henrik Sundberg wrote:
>> 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.
Could you point out what those disadvantages are? AFAIK a top-level,
what you call inverted, is equivalent to a bottom-up arrangement.
>> 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.
I do that all the time. And I keep arguing that the common use case for
the sandbox, and Boost in general, is precisely the inverse of what you
think it is.
>> 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 problem with anything that developers have to be "aware of" is that
they will forget. Anything that can't be enforced will break at some
point. So we really want to avoid the forgotten work aspect that keeps
hitting us during releases.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk