2007/6/5, troy d. straszheim <troy@resophonic.com>:
On Tue, Jun 05, 2007 at 09:31:02PM +0200, Henrik Sundberg wrote:
2007/6/4, troy d. straszheim <troy@resophonic.com>:
My workspace (CVS HEAD) contains some svn:externals that look like this:
iostreams https://svn.boost.org/svn/projects/iostreams/trunk variant https://svn.boost.org/svn/projects/variant/trunk date_time https://svn.boost.org/svn/projects/date_time/trunk (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.
From http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.externals: 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,
No, commits don't pass into externals. 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 component. 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. /$