SVN repo structure... [was: Subversion structure in KDE]
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@gmail.com> 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
Rene Rivera wrote:
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.
Yes, this looks reasonable to me.
[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)
I'm still not convinced that the branching in the sandbox should happen outside the projects (as opposed to let each sandbox project organize its own substructure), but I don't have a strong opinion there. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
on Wed May 30 2007, Stefan Seefeld <seefeld-AT-sympatico.ca> wrote:
Rene Rivera wrote:
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.
Yes, this looks reasonable to me.
[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)
I'm still not convinced that the branching in the sandbox should happen outside the projects (as opposed to let each sandbox project organize its own substructure), but I don't have a strong opinion there.
I agree with Stefan. And that goes for the non-sandbox areas too. What is the point of pushing **library-specific** branches and tags up to the top level? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Wed May 30 2007, Stefan Seefeld <seefeld-AT-sympatico.ca> wrote:
Rene Rivera wrote:
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. Yes, this looks reasonable to me.
[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) I'm still not convinced that the branching in the sandbox should happen outside the projects (as opposed to let each sandbox project organize its own substructure), but I don't have a strong opinion there.
I agree with Stefan. And that goes for the non-sandbox areas too. What is the point of pushing **library-specific** branches and tags up to the top level?
Like I said some time ago, when the longer svn thread started... It accommodates the most common use case of people going to 1 directory and getting the current version of *all* the sandbox projects. But to give you and idea of the general impact of applying the "branch inside the project dir" generally, say the thread lib needed a branch, like they have now, to work on an experimental version. They might end up with: [svn] boost boost thread trunk branches ex1 libs thread trunk branches ex1 build, docs, example, src, test I know, I'm probably exaggerating for effect. So to take a simpler example. I currently have a branch "Boost_Jam_994" which corresponds to addressing issue #994. I would, under you suggestion, end up with: [svn] boost tools jam trunk (doc,src,test,*) branches Boost_Jam_994 (doc,src,test,*) Which might be fine if you are only interested in getting bjam. But in getting the one Boost checkout you would end up waiting a long time to transfer every variation of Boost code for every library, tool, and random sub-project. What I'm essentially saying, and what KDE seems to be following, is that even though there might be many sub-projects there is only one (or some other small number) project. In our case I'm saying that's "Boost", "Sandbox", and "Website". And under those we follow the mostly suggested trunk, branches, tags arrangement. -- -- 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
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87odk1d2p8.fsf@grogan.peloton...
on Wed May 30 2007, Stefan Seefeld <seefeld-AT-sympatico.ca> wrote:
Rene Rivera wrote:
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.
Yes, this looks reasonable to me.
[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)
I'm still not convinced that the branching in the sandbox should happen outside the projects (as opposed to let each sandbox project organize its own substructure), but I don't have a strong opinion there.
I agree with Stefan. And that goes for the non-sandbox areas too. What is the point of pushing **library-specific** branches and tags up to the top level?
As you can imagine I would very much prefer to have independent per project tree. Something along these lines: python/ trunk/ branches/ releases/ tags/ config trunk/ branches/ releases/ tags/ core trunk/ branches/ releases/ tags/ and so on. I don't see why svn structure should reflect the one we use for delivery. I also don't see why we need notion of sandbox in this scenario. Every library gets it's own tree and may or may not be part of accepted boost libraries set. The only question is how to build using this structure. We either need to make changes along the lines I pitched before or create reflection tree using externals: (this tree will only include accepted libraries) boost config-> external reference to config/trunk python->external reference to python/trunk and so on. This should allow existing make system work as expected. Gennadiy
Gennadiy Rozental wrote:
As you can imagine I would very much prefer to have independent per project tree. Something along these lines:
python/ trunk/ branches/ releases/ tags/ config trunk/ branches/ releases/ tags/ core trunk/ branches/ releases/ tags/
and so on.
I don't see why svn structure should reflect the one we use for delivery. I also don't see why we need notion of sandbox in this scenario. Every library gets it's own tree and may or may not be part of accepted boost libraries set.
Currently the reasons not to do it that way are that it's not the way Boost has worked politically. And I really don't want to get into such a debate on this thread. If you want to raise the idea of library modularity, again, I would suggest another thread. I'm just trying to drive people into considering what SVN arrangement accommodates our current and historical uses.
The only question is how to build using this structure. We either need to make changes along the lines I pitched before or create reflection tree using externals: (this tree will only include accepted libraries)
boost config-> external reference to config/trunk python->external reference to python/trunk
and so on.
This should allow existing make system work as expected.
Externals, as currently implemented in SVN, and as the Boost svn server is set up, do *not* work in the general case. If we want to do that we either have to redo/adjust the server set up, or wait until SVN implements the "internals" feature. So yes, any changes that break up the Boost tree would require considerable changes to the building and testing infrastructure. -- -- 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
"Rene Rivera" <grafikrobot@gmail.com> wrote in message news:465E6021.7060407@gmail.com...
Currently the reasons not to do it that way are that it's not the way Boost has worked politically.
What politic do you mean? I am usually politically ignorant, so please be more specific.
And I really don't want to get into such a debate on this thread. If you want to raise the idea of library modularity, again, I would suggest another thread. I'm just trying to drive people into considering what SVN arrangement accommodates our current and historical uses.
My idea of "library modularity" or rather independent library releases is kinda orthogonal. Though obviosly related. It's more has to do with what we put in <lib>/releases and how we deploy boost as a whole. The above svn structure is more natural for my approach - that's true. But it has the value of it's own even with existing build/deployment practice, don't you agree? Among other things it gives nice logical and phisical separation of all the libs with their private branches. And we donlt have to duplicate tree structure for accepted/proposed libs.
The only question is how to build using this structure. We either need to make changes along the lines I pitched before or create reflection tree using externals: (this tree will only include accepted libraries)
boost config-> external reference to config/trunk python->external reference to python/trunk
and so on.
This should allow existing make system work as expected.
Externals, as currently implemented in SVN, and as the Boost svn server is set up, do *not* work in the general case.
I've seen some post in this regard. Could you clarify what the problem is again?
If we want to do that we either have to redo/adjust the server set up,
How difficult is this?
or wait until SVN implements the "internals" feature.
What is "internals" and when can we expect it to be implemented?
So yes, any changes that break up the Boost tree would require considerable changes to the building and testing infrastructure.
I hoped we could split the difference. Move to better (IMO obviosly), independent code structure while keep using existing infrastructure. Eventually we can employ all the power of independent component development. Gennadiy
On Thu, May 31, 2007 at 02:33:29AM -0400, Gennadiy Rozental wrote:
"Rene Rivera" <grafikrobot@gmail.com> wrote in message news:465E6021.7060407@gmail.com...
Currently the reasons not to do it that way are that it's not the way Boost has worked politically.
And I really don't want to get into such a debate on this thread. If you want to raise the idea of library modularity, again, I would suggest another thread. I'm just trying to drive people into considering what SVN arrangement accommodates our current and historical uses.
My idea of "library modularity" or rather independent library releases is kinda orthogonal. Though obviosly related. It's more has to do with what we put in <lib>/releases and how we deploy boost as a whole. The above svn structure is more natural for my approach - that's true. But it has the value of it's own even with existing build/deployment practice, don't you agree? Among other things it gives nice logical and phisical separation of all the libs with their private branches. And we donlt have to duplicate tree structure for accepted/proposed libs.
There are very compelling reasons to do it this way (branches as subdirs of projects) that do *NOT* involve splitting up the boost C++ libraries themselves (the hot issue that I'm trying to avoid). It: * doesn't inflict the universe of branch names on each developer * allows per-project access control in the repository (access control, not versioning, like restricting commits to release branches) * allows for versioning associated code/resources (e.g. autobuild scripts/infrastructure, fop/docboock stuff that goes with quickbook), that must be in version control and will need to be easily updated by users on a timescale that doesn't match overall releases of boost.
Externals, as currently implemented in SVN, and as the Boost svn server is set up, do *not* work in the general case.
I've seen some post in this regard. Could you clarify what the problem is again?
Let's take the externals stuff to another thread.
If we want to do that we either have to redo/adjust the server set up,
How difficult is this?
or wait until SVN implements the "internals" feature.
What is "internals" and when can we expect it to be implemented?
So yes, any changes that break up the Boost tree would require considerable changes to the building and testing infrastructure.
I hoped we could split the difference. Move to better (IMO obviosly), independent code structure while keep using existing infrastructure. Eventually we can employ all the power of independent component development.
I think I agree with you, but there's lots to be debated first and no compellng reason to do this now... In any case such a transformation would happen piecemeal after a basic import into svn. -t
David Abrahams wrote:
on Wed May 30 2007, Stefan Seefeld <seefeld-AT-sympatico.ca> wrote:
Rene Rivera wrote:
[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)
I'm still not convinced that the branching in the sandbox should happen outside the projects (as opposed to let each sandbox project organize its own substructure), but I don't have a strong opinion there.
I agree with Stefan. And that goes for the non-sandbox areas too. What is the point of pushing **library-specific** branches and tags up to the top level?
I agree too. Things that have different release cycles should not be mixed unnecessarily. Additionally, one could also set up a completely different repository for the sandbox, to make logs/history less cluttered. Has that been considered? /Marcus
On May 31, 2007, at 4:32 AM, Marcus Lindblom wrote:
Additionally, one could also set up a completely different repository for the sandbox, to make logs/history less cluttered. Has that been considered?
It was. We (I?) decided to put it into the same Subversion repository, so that it would be easy to keep all of the sandbox history for a library when it is accepted into Boost. With SourceForge, this was a real pain: we had to either beg SF staff to move over the CVS history, or we had to just re-import and lose easy access to that history. Subversion dumpfiles can make this a little easier, and the Subversion server is under our control now, but it still requires user intervention. - Doug
Douglas Gregor wrote:
On May 31, 2007, at 4:32 AM, Marcus Lindblom wrote:
Additionally, one could also set up a completely different repository for the sandbox, to make logs/history less cluttered. Has that been considered?
It was. We (I?) decided to put it into the same Subversion repository, so that it would be easy to keep all of the sandbox history for a library when it is accepted into Boost. With SourceForge, this was a real pain: we had to either beg SF staff to move over the CVS history, or we had to just re-import and lose easy access to that history. Subversion dumpfiles can make this a little easier, and the Subversion server is under our control now, but it still requires user intervention.
Ok. That makes sense. I didn't think about the sandbox as a "soon-to-be-boostified" storage, but rather as a wild playground. :) Cheers, /Marcus
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@gmail.com>:
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@gmail.com>
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
Henrik Sundberg wrote:
I think it could be better to have trunk/tags/branches on the topmost directory level, and to use trunk instead of devel.
I agree. See below.
[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)
I think there should be one main devel/trunk, and everything else should be in branches, including 'stable'. Most likely stable is in fact a release branch, and so should be under branches. So: boost trunk branches release_1_34 other_branch etc
Thanks for pointing this out, Rene.
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)
I don't like having everything live under "boost", because users will then just "svn co https://svn.boost.org/svn/boost/boost" and wonder why they just downloaded 10GB. Not good. Instead, I prefer [boost-svn] stable devel 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)
Same complaint with the sandbox: I'd prefer that we put the latest and greatest into "sandbox", and have separate branches/tags, e.g., [boost-svn] sandbox xml explore sandbox-branches xml_b0 explore_b0 sandbox-tags xml_for_review explore_for_review - Doug
On Wed, May 30, 2007 at 04:59:12PM -0400, Doug Gregor wrote:
Thanks for pointing this out, Rene.
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)
I don't like having everything live under "boost", because users will then just "svn co https://svn.boost.org/svn/boost/boost" and wonder why they just downloaded 10GB. Not good. Instead, I prefer
[boost-svn] stable devel 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)
There's always the risk that somebody will blindly check out the entire get everything. I'm almost certain there is a way (via svn hook scripts) to prevent anonymous users from doing this in a way that does not disturb others. The current mapping of the URL to the repository doesn't make much sense to me. I'd prefer the base of the repo to be http://svn.boost.org/svn and in the root of the repository a directory 'boost'. I'm sure this is a simple tweak of <Location> in an apache .conf file. If https://svn.boost.org/svn did map to the root of the repository, (rather than to a redirect as it does currently) the repo could contain boost/ stable/ devel/ branches/ (etc) sandbox/ devel etc branches etc tags and the desired http://svn.boost.org/svn/boost/(stable|devel) works, and your repository root is also left open, for instance for infrastructure (like autobuild stuff or the latest-greatest quickbook setup) that needs to be in source control but doesn't belong in the distribution since it is distributed on a different time scale. Personally I prefer boost/ trunk/ releases/ v1.33.1/ v1.34.0/ branches/ etc/ and_so_on/ I omit 'tags' since I don't personally end up with 'tags' that arent releases. Something is either a frozen release, or a branch. We use per-directory access-control to enforce that releases aren't modified by anyone other than release managers.
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)
Same complaint with the sandbox: I'd prefer that we put the latest and greatest into "sandbox", and have separate branches/tags, e.g.,
[boost-svn] sandbox xml explore sandbox-branches xml_b0 explore_b0 sandbox-tags xml_for_review explore_for_review
But in this structure the branch names of all sandbox library authors are incident on all other authors. The number of entries in sandbox-branches will quickly get out of hand. Authors also must be careful about how they name their branches, and have nowhere to put things that, as with the quickbook/autobuild stuff, might need to be in source control but aren't part of the distribution. It is also very kludgy to provide per-project access controls when the contents of one logical project is spread across the repository in this way. In this structure: sandbox xml trunk branches abortive_attempt will_be_useful_later dont_remember_what_i_was_doing releases v0.0.666 explore trunk branches for_review // this sounds convenient xml // copy of sandbox/xml/trunk explore It isnt necessary in the normal course of business to look past the branch names of others; one can augment the trunk/branches/releases scheme if necessary for associated stuff without disturbing others, and it is easy to provide per-project access controls. -t
troy d. straszheim wrote:
There's always the risk that somebody will blindly check out the entire get everything. I'm almost certain there is a way (via svn hook scripts) to prevent anonymous users from doing this in a way that does not disturb others.
Perhaps you should consider using mod_dontdothat on the server side to "restrict" certain things you dont want people to do... like checkout from the root. See: http://svn.collab.net/repos/svn/trunk/contrib/server-side/mod_dontdothat/REA...
eg wrote:
troy d. straszheim wrote:
There's always the risk that somebody will blindly check out the entire get everything. I'm almost certain there is a way (via svn hook scripts) to prevent anonymous users from doing this in a way that does not disturb others.
Perhaps you should consider using mod_dontdothat on the server side to "restrict" certain things you dont want people to do... like checkout from the root.
I don't understand the desire for all this hand-holding. I'd trust users (or at least the majority of them) to know what they are doing. (I was similarly irritated to see that a fresh boost checkout (CVS) made all files read-only, when I started using the repository directly some years ago. How annoying !) </rant> Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Perhaps you should consider using mod_dontdothat on the server side to "restrict" certain things you dont want people to do... like checkout from the root.
I don't understand the desire for all this hand-holding. I'd trust users (or at least the majority of them) to know what they are doing.
(I was similarly irritated to see that a fresh boost checkout (CVS) made all files read-only, when I started using the repository directly some years ago. How annoying !)
</rant>
I don't know about "hand-holding" for this project, but there are lots of things that you can do with SVN but they might not fit your usage policy. For example, we use hooks to enforce users to enter certain commit log messages and don't allow commits to "tag" directories, because it is a lot easier to do this up front. Some might consider this hand-holding, but it fits with our environment. You are correct in one sense that the decision to use the mod_dontdothat is more for administrators than for end users... if you get too many people hitting your servers checking out the entire tree, it consumes resources, which you might not want. The tool (mod_dontdothat) was written with that in mind. I only pass the info along as people here are just starting out with SVN and might not know it exists.
Rene Rivera wrote:
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)
It would be nice to have an empty directory (named "empty") in the tree at the top level so users can "svn switch" various subdirectories/projects to it and get rid of working copies they dont want to have around. GCC does this. See the following for details (look at the section titled "Optimize disk usage"): http://gcc.gnu.org/wiki/SvnSetup
On Wednesday 30 May 2007 22:29:05 Rene Rivera wrote:
[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)
boost/stable would contain a copy of boost/tags/boost_1_34_0 currently and both would be equal to what you get when you download the tarballs/zips, right? Further, if I want to finally finish the port to Windows CE, admins could create a branch and assign commit-rights to me (I don't have them otherwise) so I don't have to use my company's private repository and so that everybody can see and contribute. When the code has been thoroughly tested, the changes can be merged into boost/devel. Is that one of the goals?
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)
I wonder what we need the sandbox for? I would say that it's for separated development of features. However, for that I could as well use a branch like above that includes a complete Boost tree. This wasn't the case for CVS, where copying files around had significant overhead IIRC, but with Subversion you get cheap copies. Now, if someone wants to test then new lib, they simply 'svn switch' their working copy from boost/devel to boost/branches/some-new-lib and run their buildscripts. IOW, having a complete tree will reduce the barrier to testing it (theoretically, the only changes are that one library and all other code will remain unaffected) and will also reveal when library experimenters fail to regularly merge changes from boost/devel to their tree, which in the other direction affects the ability to merge their new library to boost/devel. Of course, this requires some discipline: People need to know which version their branch is based on. Further, they need to know which of the possible changes to their base have been merged. The first can rather easily be determined from the logs, but the second requires some manual work because Subversion doesn't yet feature merge tracking (due in version 1.5 or 1.6). Example: I'd do my above port based on 1.34 first, simply because that one is well tested and stable. Later, I would split off a development version and merge the changes between 1.34 and the current version into it, to prepare for the changes to be merged back. Once the changes are merged back, the development branch could be deleted again.
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.
I don't think that updating boost/stable happens often, but that of course depends on what you want to put there. Can you tell us what you want there? Uli
On Jun 1, 2007, at 1:29 AM, Ulrich Eckhardt wrote:
On Wednesday 30 May 2007 22:29:05 Rene Rivera wrote:
[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)
boost/stable would contain a copy of boost/tags/boost_1_34_0 currently and both would be equal to what you get when you download the tarballs/ zips, right?
At the moment that the release manager builds the tarball, they will be identical. However, "stable" will evolve during releases, as we move well-tested code from devel over to stable.
Further, if I want to finally finish the port to Windows CE, admins could create a branch and assign commit-rights to me (I don't have them otherwise) so I don't have to use my company's private repository and so that everybody can see and contribute. When the code has been thoroughly tested, the changes can be merged into boost/devel. Is that one of the goals?
Yes, that's one of the reasons to use branches. - Doug
on Fri Jun 01 2007, Ulrich Eckhardt <doomster-AT-knuut.de> wrote:
Subversion doesn't yet feature merge tracking
FWIW, there is a script called 'svnmerge' that will do SVN merges with tracking. http://www.orcaware.com/svn/wiki/Svnmerge.py I don't know if there's a way to enforce that people use it, though... -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (12)
-
Aaron W. LaFramboise -
David Abrahams -
Doug Gregor -
Douglas Gregor -
eg -
Gennadiy Rozental -
Henrik Sundberg -
Marcus Lindblom -
Rene Rivera -
Stefan Seefeld -
troy d. straszheim -
Ulrich Eckhardt