Boost logo

Boost :

From: Henrik Sundberg (storangen_at_[hidden])
Date: 2007-06-05 16:43:48

2007/6/5, troy d. straszheim <troy_at_[hidden]>:
> On Tue, Jun 05, 2007 at 09:31:02PM +0200, Henrik Sundberg wrote:
> > 2007/6/4, troy d. straszheim <troy_at_[hidden]>:
> > > My workspace (CVS HEAD) contains some svn:externals that look like
> > > this:
> > >
> > > iostreams
> > > variant
> > > date_time
> > > (etc)
> > >
> > > which means the code layout looks like that above. When I svn update,
> > > each of those subdirectories are updated recursively. I can make one
> > > commit across multiple projects.
> >
> > No, commits don't pass into externals.
> > >From
> > The support that exists for externals definitions in Subversion today
> > can be a little misleading, though. First, an externals definition can
> > only point to directories, not files. Second, the externals definition
> > cannot point to relative paths (paths like ../../skins/myskin). Third,
> > the working copies created via the externals definition support are
> > still disconnected from the primary working copy (on whose versioned
> > directories the svn:externals property was actually set). And
> > Subversion still only truly operates on non-disjoint working copies.
> > So, for example, if you want to commit changes that you've made in one
> > or more of those external working copies, you must run svn commit
> > explicitly on those working copies?committing on the primary working
> > copy will not recurse into any external ones.
> >
> I've read the manual, thanks. I didn't say exactly *how* I can make
> one commit across multiple projects. With something like emacs
> svn-mode you diff/tag with a few keystrokes and you make one commit
> across multiple projects. Or you can simply commit like this:
> svn commit *
> assuming everything that '*' matches is under version control, which
> it is when you do out-of-source builds, if not you can
> svn commit project1 project2 project3
> There are myriad convenient ways to work with a checkout full of
> externals.

Thanks for the info!

I'm new to svn. And I'm trying to build a good structure for a family
of systems built on ~200 components with 1-20 subcomponents per
Our current (pre-svn) method handles releases on subcomponent level.
Integration teams selects the subcomponents to build a system from,
builds it, and releases the resulting binaries/configurations.

I'm trying to understand what the best svn-structure would be. Boost,
and KDE, seem to have the same problems as I. I don't understand KDE
(I did read their tutorial) enough to know how it can be compiled
without a clear (to me) structure of subreleases.

I'm trying to understand when to use externals among other things.
They seemed to be useful for making higher order releases based on
lower ones. But I got discouraged.

I didn't intend to be rude. Sorry.

Boost list run by bdawes at, gregod at, cpdaniel at, john at