Re: [boost] SVN repo structure... [was: Subversion structure in KDE]

From: Henrik Sundberg (storangen_at_[hidden])
Date: 2007-05-30 16:40:27

I think it could be better to have trunk/tags/branches on the topmost
directory level, and to use trunk instead of devel.

I would also like to see how libraries could have their own
release-cycles, with the major Boost-releases just picking appropriate
library-releases.

/$

2007/5/30, Rene Rivera <grafikrobot_at_[hidden]>:
> Ping... Any comments on this? It would be nice if people voice some
> comments on this subject now. Instead of later when we would have to
> move a bunch of directories around.
>
> -------- Original Message --------
> Subject: Re: [boost] Subversion structure in KDE
> Date: Sun, 27 May 2007 17:54:20 -0500
> From: Rene Rivera <grafikrobot_at_[hidden]>
>
> Henrik Sundberg wrote:
> > KDE is also a large project with separate subprojects. I thought it
> > might be a good idea to look at their structure.
> [snip]
> > Here is the repository: http://websvn.kde.org/
> [snip]
> > How about a trunk with the two subdirectories Boost and Sandbox? The
> > Boost directory would contain libraries that are to be part of the
> > next official Boost release, and the Sandbox other libraries.
>
> If I'm understanding you, and the KDE docs, correctly, what you want is
> something like(**):
>
> [boost-svn]
>     boost
>       stable (full boost tree here)
>       devel (full boost tree here)
>       branches
>         my_branch (full boost tree here)
>         cmake_a (full boost tree here)
>         cmake_b (full boost tree here)
>       tags
>         boost_1_33_1 (full boost tree here)
>         boost_1_34_0 (full boost tree here)
>     sandbox
>       devel
>         xml (partial boost tree here)
>         explore  (partial boost tree here)
>       branches
>         xml_b0 (partial boost tree here)
>         explore_b0  (partial boost tree here)
>       tags
>         xml_for_review (partial boost tree here)
>         explore_for_review  (partial boost tree here)
>
> That seems like a reasonable arrangement to me. It has the beauty of
> being easy to explain, and it's not too far off from what we have now.
> The one drawback I can see is that one common case, of updating
> boost/stable and boost/devel can't be done in one go. But I think that's
> a reasonable aspect to give up (not that we had it in the first place)
> since hopefully working with both at the same time will be an infrequent
> task.
>
>
>
> (**) I'm ignoring the website tree because it's not the same kind of
> beast. Since it only has to deal with two versions, and doesn't need tags.
>
> --
> -- 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
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>