* Daniel James <daniel@calamity.org.uk> [2005-02-06 05:01]:
troy d. straszheim wrote:
SVN accomodates this structure quite nicely. In the spirit of considering the project structure carefully, here's a few thoughts. Assume that you have your libraries broken up as in the jakarta example above. boost would look something like this:
/boost /boost /shared_ptr /trunk /branches/v1.0 /branches/v1.1 /type_traits /trunk /branches/v1.0 /branches/some_other_branch /libs /shared_ptr /trunk /branches/v1.0 /type_traits /trunk /branches/v1.0 /branches/some_other_branch /tools /trunk /branches/v1.0
Now that kind of looks like a nightmare, but svn makes it pretty easy to handle. A checkout of the trunk should assemble the trunks of each sublibrary locally in such a way that immediately after the checkout, you're ready to bjam without additional work. Named releases should do something similar, but with various releases of various sublibraries.
I think this is a good idea, but the problem is that a lot of libraries have code in the boost directory (such as boost/shared_ptr.hpp). They could possibly be changed to just include the implementation from a subdirectory. Would this be worth it? I actually think that might be a good idea anyway.
This would be very nice for Spirit, which has two active versions.
How do you propose a person asssembles a boost checkout? Currently you simply run a single command to grab all of boost. cvs -d [pserver] co [module] Everything is pulled. With the above, would I not have to checkout... svn checkout http://foo.com/boost/shared_ptr/trunk shared_ptr svn checkout http://foo.com/boost/type_traits/trunk type_traits ... and so on, for every sub-library in boost? -- Alan Gutierrez - alan@engrm.com