As far as I can see, scaling Boost up to a much larger number of libraries implies decentralization and decoupling, probably in the form of per-library modules or something similar. Modularization seems to have been missed in the discussions of Subversion, Git, and Mercurial. Do distributed version control systems in general and Git in particular have any important advantages/disadvantages over svn for highly modularized projects? Please, let's not waste everyone's time with a rehash of general DCVS vs CCVS pros and cons. We have beat that to death. Let's focus this thread on modularization support, particularly as it applies to Boost. Thanks, --Beman
On 04/04/2012 12:13 AM, Beman Dawes wrote:
> As far as I can see, scaling Boost up to a much larger number of
> libraries implies decentralization and decoupling, probably in the
> form of per-library modules or something similar.
>
> Modularization seems to have been missed in the discussions of
> Subversion, Git, and Mercurial. Do distributed version control systems
> in general and Git in particular have any important
> advantages/disadvantages over svn for highly modularized projects?
As far as I am aware there are two big Opensource Projects which are
highly modularized and use git:
1) Xorg (http://cgit.freedesktop.org/):
They provide one git repository per module, when building any
module from source, one has to track the dependency manually, and point
the build system to the other modules locations.
2) KDE (https://projects.kde.org/ and http://quickgit.kde.org/):
Same setup as above.
I don't know if they were modularized before they switched to git.
IMHO, one of the downsides is the lack of build tool support. Meaning,
that it is a little cumbersome to collect all necessary modules and
setup the build process for the different modules. I don't think the
DCVS approach has any significant advantage over SVN when merely looking
at splitting up one big repository into smaller ones.
However, the advantages discussed in other threads will lead to better
possibilities in integrating externally developed boost modules.
>
> Please, let's not waste everyone's time with a rehash of general DCVS
> vs CCVS pros and cons. We have beat that to death. Let's focus this
> thread on modularization support, particularly as it applies to Boost.
>
> Thanks,
>
> --Beman
>
> _______________________________________________
> Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 04/04/2012 09:15 AM, Thomas Heller wrote: > On 04/04/2012 12:13 AM, Beman Dawes wrote: >> As far as I can see, scaling Boost up to a much larger number of >> libraries implies decentralization and decoupling, probably in the >> form of per-library modules or something similar. >> >> Modularization seems to have been missed in the discussions of >> Subversion, Git, and Mercurial. Do distributed version control systems >> in general and Git in particular have any important >> advantages/disadvantages over svn for highly modularized projects? > As far as I am aware there are two big Opensource Projects which are > highly modularized and use git: > 1) Xorg (http://cgit.freedesktop.org/): > They provide one git repository per module, when building any > module from source, one has to track the dependency manually, and > point the build system to the other modules locations. > 2) KDE (https://projects.kde.org/ and http://quickgit.kde.org/): > Same setup as above. > > I don't know if they were modularized before they switched to git. > IMHO, one of the downsides is the lack of build tool support. Meaning, > that it is a little cumbersome to collect all necessary modules and > setup the build process for the different modules. I don't think the > DCVS approach has any significant advantage over SVN when merely > looking at splitting up one big repository into smaller ones. > However, the advantages discussed in other threads will lead to better > possibilities in integrating externally developed boost modules. I forgot one thing ... this whole build-tool support might not be a big problem for linux users, as they can easily get the boost modules with dependency tracking and such from their distribution. How will this look in windows? For boost contributors this might not be a big issue, cause it is a one-time setup. What about users who need the latest greatest version from version control? Please say that I rate this problem too high and that there is an easy solution. FWIW, I am all for a modularized boost! >> >> Please, let's not waste everyone's time with a rehash of general DCVS >> vs CCVS pros and cons. We have beat that to death. Let's focus this >> thread on modularization support, particularly as it applies to Boost. >> >> Thanks, >> >> --Beman >> >> _______________________________________________ >> Unsubscribe& other changes: >> http://lists.boost.org/mailman/listinfo.cgi/boost >
On 2012-04-04 09:34, Thomas Heller wrote:
I forgot one thing ... this whole build-tool support might not be a big problem for linux users, as they can easily get the boost modules with dependency tracking and such from their distribution. How will this look in windows? For boost contributors this might not be a big issue, cause it is a one-time setup. What about users who need the latest greatest version from version control? Please say that I rate this problem too high and that there is an easy solution. FWIW, I am all for a modularized boost!
Just add a separate repository called "The Boost Libraries", maintained by the Boost Release Manager team. Have the library (module) developers maintain a separate branch called for-release-team, and have the release team pull in and assemble "the boost libraries", once per release. So the users can just pull in Boost from a centralized repository. Users shouldn't be bothered with dependency tracking and other fancy stuff. If really needed, daily snapshots could be provided, too. Developers, on the other hand, may be required to be able to pull in the latest stuff from dependent modules. Cheers, Rutger
Thomas Heller wrote:
On 04/04/2012 09:15 AM, Thomas Heller wrote:
As far as I am aware there are two big Opensource Projects which are highly modularized and use git: 1) Xorg (http://cgit.freedesktop.org/): They provide one git repository per module, when building any module from source, one has to track the dependency manually, and point the build system to the other modules locations. 2) KDE (https://projects.kde.org/ and http://quickgit.kde.org/): Same setup as above.
I don't know if they were modularized before they switched to git. IMHO, one of the downsides is the lack of build tool support. Meaning, that it is a little cumbersome to collect all necessary modules and setup the build process for the different modules. I don't think the DCVS approach has any significant advantage over SVN when merely looking at splitting up one big repository into smaller ones. However, the advantages discussed in other threads will lead to better possibilities in integrating externally developed boost modules.
I forgot one thing ... this whole build-tool support might not be a big problem for linux users, as they can easily get the boost modules with dependency tracking and such from their distribution. How will this look in windows? For boost contributors this might not be a big issue, cause it is a one-time setup. What about users who need the latest greatest version from version control? Please say that I rate this problem too high and that there is an easy solution. FWIW, I am all for a modularized boost!
Isn't this exactly the problem that the Ryppl folks hope to solve by adopting zeroinstall? In fact, isn't this entire topic already covered by the people at Ryppl, anyway? Perhaps we should ask them to explain the current state of their ideas first. -Julian
Beman Dawes wrote:
As far as I can see, scaling Boost up to a much larger number of libraries implies decentralization and decoupling, probably in the form of per-library modules or something similar.
100 % aggree with this.
Modularization seems to have been missed in the discussions of Subversion, Git, and Mercurial. Do distributed version control systems in general and Git in particular have any important advantages/disadvantages over svn for highly modularized projects?
Hmmm - if boost is "modularized" - wouldn't that mean that each library has it's own repository. Or that each developer can decide where he want's to store his version? I would think that the testing/deployment process could update/export each library from a different place without much problem. Robert Ramey.
On 4/4/2012 3:20 PM, Robert Ramey wrote:
Beman Dawes wrote:
As far as I can see, scaling Boost up to a much larger number of libraries implies decentralization and decoupling, probably in the form of per-library modules or something similar.
100 % aggree with this.
+1
Modularization seems to have been missed in the discussions of Subversion, Git, and Mercurial. Do distributed version control systems in general and Git in particular have any important advantages/disadvantages over svn for highly modularized projects?
Hmmm - if boost is "modularized" - wouldn't that mean that each library has it's own repository. Or that each developer can decide where he want's to store his version?
I suggest starting modular SVN repositories -one for each library + core. Such decoupled/modular SVN repositories can immediately be used with any DVCS such as Git/Hg. I'll also plead that each modular library author be given the right to issue write access to anyone within the confines of its repository. Also, I wouldn't mind wherever the repository is actually hosted.
I would think that the testing/deployment process could update/export each library from a different place without much problem.
That would be in the core. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
On 04/04/2012 09:20 AM, Robert Ramey wrote:
Beman Dawes wrote:
As far as I can see, scaling Boost up to a much larger number of libraries implies decentralization and decoupling, probably in the form of per-library modules or something similar. 100 % aggree with this.
Modularization seems to have been missed in the discussions of Subversion, Git, and Mercurial. Do distributed version control systems in general and Git in particular have any important advantages/disadvantages over svn for highly modularized projects? Hmmm - if boost is "modularized" - wouldn't that mean that each library has it's own repository.
I think this is a good idea as a basic assumption. Further I think an official repository should be available somewhere well known for each module from where the integration process can pull the changes.
Or that each developer can decide where he want's to store his version?
maybe
I would think that the testing/deployment process could update/export each library from a different place without much problem.
Not very clear what testing/deployment process mean here, but I think this can work fine. However, I think there also should be simple ways of using subset of modules from boost without fetching them from a release of the complete thing. Also, it should be simple to patch with per module hot-fixes that never makes it into a main boost dot release. This implies support for per module dependency control with explicit declaration of versions of the dependencies supported with each version of a module. Stuff like git submodule may provide part of the solution to this, but there are issues that need to be resolved such as the fact that currently a boost library does not fall into a a single mount point in the boost structure. Typically there is at least 3: * lib/x/ * boost/x.hpp * boost/x/ This is something git-submodule does not handle well out of the box, at least I think so. We have been down this path before on the list, I think possible appealing alternatives are something like: * SCM tool support multiple/overlapping mount points [1] * SCM tool stage header files to common -I area [1][2][3] * Build tool stage header files to common -I area [2][3][4] * Move lib/x/.. files to boost/x/lib/... [5] A less appealing option is: * clients use multiple -I when building against boost modules that has not been integrated A related issue that need to be considered is the need for common baselines for dependencies, or at least some scheme for resolving valid combinations of module versions (e.g. git commits). In boost there are likely to multiple dependency paths to the same modules. How shall the tools and processes support this when modules not pipelined through a release process and aligned there? Assuming there will be such alignment process for boost releases, but not for assuring compatibility of more ad-hoc combinations of module versions. One thought that come to my mind is that Boost need to track which combination of module versions are tested in the test and release process. Maybe tool support for this tracking also can track compatibility of other module combinations not provided by the official boost release team. I guess in git this is simply a set of module names v.s. SHA1 keys similar to what git submodule uses. If there is a way to publish results of testing other module combinations and all these results are combined somehow into a sort of compatibility graph, this may be a good way of sharing test results. notes: [1] It should be simple enough for "possibly modified" git-submodule to support this in a naive solution. However this may open the door for an evil twin like problem that require some management. Evil twin is a term used IBM to denote when multiple elements (files) under SCM control map to the same file system path and one element eclipse (hides) the other, see http://www-01.ibm.com/support/docview.wss?uid=swg21125072 [2] This requires that header module files for module in boost/... are moved to lib/x/boost/... or something similar [3] Make sure the staged header files are links to the files under SCM control. Copied files are a real annoyance during debug - fix - debug cycles, believe me! So whatever tool that does such staging in a development environment should use links whenever possible, preferably hard links to files or directory links (symbolic). Only when this is not supported on the file system should the tool use copy. [4] evil twins are still a problem, but now a build time evil overwrite issue. [5] For this to be viable, boost/x.hpp files need to be in some common module. I guess this will not be bad as long as they are forwarding header and dependency from module x to common module is explicit end version controlled. -- Bjørn
Bjørn Roald wrote:
On 04/04/2012 09:20 AM, Robert Ramey wrote: maybe
I would think that the testing/deployment process could update/export each library from a different place without much problem.
Not very clear what testing/deployment process mean here, but I think this can work fine.
I had more specific thoughts on this but as it became clear that this would be significant issue, I deleted them from my post to avoid confusing things.
However, I think there also should be simple ways of using subset of modules from boost without fetching them from a release of the complete thing.
This is the essential thing to me. I want to pick and choose which libraries I want to download and install (subject to requirements for pre-requisites) the combination of libraries I want to install. Also, I absolutley need to have library by library usage/download statistics. Basically, I want to eliminate the requirement that all boost developers use the same repository/system. It can be just as well left up to the developer which/what to use. Robert Ramey
on Wed Apr 04 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Bj.rn Roald wrote:
On 04/04/2012 09:20 AM, Robert Ramey wrote: maybe
I would think that the testing/deployment process could update/export each library from a different place without much problem.
Not very clear what testing/deployment process mean here, but I think this can work fine.
I had more specific thoughts on this but as it became clear that this would be significant issue, I deleted them from my post to avoid confusing things.
However, I think there also should be simple ways of using subset of modules from boost without fetching them from a release of the complete thing.
This is the essential thing to me. I want to pick and choose which libraries I want to download and install (subject to requirements for pre-requisites) the combination of libraries I want to install.
Also, I absolutley need to have library by library usage/download statistics.
Basically, I want to eliminate the requirement that all boost developers use the same repository/system. It can be just as well left up to the developer which/what to use.
That is certainly a place we can get to eventually if we go with 0install. The shape of things is that 0install is looking like it will be much more essential to Ryppl, in the long run, than either CMake or Git, and choice of build tool/VCS can be more flexible in the long run. But we have to start somewhere. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Wed, 04 Apr 2012 00:13:49 +0200, Beman Dawes <bdawes@acm.org> wrote:
As far as I can see, scaling Boost up to a much larger number of libraries implies decentralization and decoupling, probably in the form of per-library modules or something similar.
Modularization seems to have been missed in the discussions of Subversion, Git, and Mercurial. Do distributed version control systems in general and Git in particular have any important advantages/disadvantages over svn for highly modularized projects?
Please, let's not waste everyone's time with a rehash of general DCVS vs CCVS pros and cons. We have beat that to death. Let's focus this thread on modularization support, particularly as it applies to Boost.
Modularization has its advantage for sure anyway it has to be evaluated carefully because managing a multi-repository project can require a lot of discipline. For instance lately LibreOffice has switched from a multi git repository layout to a monolithic one [1], because handling them separately was become a mess. I want to be clear I am not against modularization but I think also that we should be aware of any drawback of this solution. [1] http://wiki.documentfoundation.org/Development/One_Git_Conversion Regards, -- Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
on Tue Apr 03 2012, Beman Dawes <bdawes-AT-acm.org> wrote:
As far as I can see, scaling Boost up to a much larger number of libraries implies decentralization and decoupling, probably in the form of per-library modules or something similar.
Quite so.
Modularization seems to have been missed in the discussions of Subversion, Git, and Mercurial. Do distributed version control systems in general and Git in particular have any important advantages/disadvantages over svn for highly modularized projects?
Aside from the fact that boost is already modularized in Git, you mean? ;-) http://github.com/boost-lib
Please, let's not waste everyone's time with a rehash of general DCVS vs CCVS pros and cons. We have beat that to death. Let's focus this thread on modularization support, particularly as it applies to Boost.
Well, let's see... I guess *if* you want to treat modules as sub-modules, Git is a bit more flexible than SVN in that you have both submodules (roughly like svn externals) and git-subtree (in the next release of Git, or a separate add-on until then), so you can choose your poison. However, I don't think we're (mostly) going to be using either of those technologies. Instead, I believe we'll be using 0install to manage the interactions of related library versions, which will render most such questions moot. A library developer will (mostly) be working with only one repository at a time, and the dependency management system in 0install will take care of acquiring the others. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 04/04/2012 12:05 PM, Dave Abrahams wrote:
on Tue Apr 03 2012, Beman Dawes<bdawes-AT-acm.org> wrote:
As far as I can see, scaling Boost up to a much larger number of libraries implies decentralization and decoupling, probably in the form of per-library modules or something similar.
Quite so.
Modularization seems to have been missed in the discussions of Subversion, Git, and Mercurial. Do distributed version control systems in general and Git in particular have any important advantages/disadvantages over svn for highly modularized projects?
Aside from the fact that boost is already modularized in Git, you mean? ;-) http://github.com/boost-lib
Please, let's not waste everyone's time with a rehash of general DCVS vs CCVS pros and cons. We have beat that to death. Let's focus this thread on modularization support, particularly as it applies to Boost.
Well, let's see... I guess *if* you want to treat modules as sub-modules, Git is a bit more flexible than SVN in that you have both submodules (roughly like svn externals) and git-subtree (in the next release of Git, or a separate add-on until then), so you can choose your poison.
However, I don't think we're (mostly) going to be using either of those technologies. Instead, I believe we'll be using 0install to manage the interactions of related library versions, which will render most such questions moot. A library developer will (mostly) be working with only one repository at a time, and the dependency management system in 0install will take care of acquiring the others.
If things get to this stage - and I certainly hope they do - it seems the most important remaining question for version control systems re modularization is how easy it easy to transfer content (*and* associated history) between different the repositories as the boundaries of libraries shift or utility code is shared between them. My experience is that this works very well in git with the big caveat that the invocations to do it are pretty complex and frankly scary-looking to novices. But if I copy and paste what Stack Overflow tells me to do, it does exactly what I want. I can't speak knowledgeably of either Mercurial or SVN on this topic. Jim Bosch
I haven't used it yet, but there is a Mercurial plug-in, hg-git: http://hg-git.github.com/ that allows you to connect to git repositories (with history propagation) via a mercurial client.
On Wed, Apr 4, 2012 at 12:05 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Tue Apr 03 2012, Beman Dawes <bdawes-AT-acm.org> wrote:
As far as I can see, scaling Boost up to a much larger number of libraries implies decentralization and decoupling, probably in the form of per-library modules or something similar.
Quite so.
Modularization seems to have been missed in the discussions of Subversion, Git, and Mercurial. Do distributed version control systems in general and Git in particular have any important advantages/disadvantages over svn for highly modularized projects?
Aside from the fact that boost is already modularized in Git, you mean? ;-) http://github.com/boost-lib
The fact that we already have both the history conversion problem and the modularization problem solved using Git is no small advantage for Git, but I'm also trying to see if there is technical advantage one way or the other.
Please, let's not waste everyone's time with a rehash of general DCVS vs CCVS pros and cons. We have beat that to death. Let's focus this thread on modularization support, particularly as it applies to Boost.
Well, let's see... I guess *if* you want to treat modules as sub-modules, Git is a bit more flexible than SVN in that you have both submodules (roughly like svn externals) and git-subtree (in the next release of Git, or a separate add-on until then), so you can choose your poison.
OK, so that's the technical answer I was looking for. I'll read up on git-subtree so I can understand a bit better.
However, I don't think we're (mostly) going to be using either of those technologies. Instead, I believe we'll be using 0install to manage the interactions of related library versions, which will render most such questions moot. A library developer will (mostly) be working with only one repository at a time, and the dependency management system in 0install will take care of acquiring the others.
Good. Dependency management is seriously worrisome, so having a solution for that is another big step forward. Thanks, --Beman
Beman Dawes <bdawes@acm.org> writes:
Modularization seems to have been missed in the discussions of Subversion, Git, and Mercurial. Do distributed version control systems in general and Git in particular have any important advantages/disadvantages over svn for highly modularized projects?
Please, let's not waste everyone's time with a rehash of general DCVS vs CCVS pros and cons. We have beat that to death. Let's focus this thread on modularization support, particularly as it applies to Boost.
Modularization in Mercurial is done with something we call subrepositories: http://mercurial.selenic.com/wiki/Subrepository This lets you recursively checkout and operate on nested repositories. The repositories can be of different kinds: Hg, Git, or SVN. The system is quite simple: there are two version controlled files: * .hgsub tells Mercurial where each nested repository comes from and where it should be put in the working copy. You manage this file. * .hgsubstate tells Mercurial which exact revision to checkout for each subrepository. Mercurial manages this file. Mercurial always checks out the version mentioned in .hgsubstate. This means that each commit in the main repository will reference exactly one version of each subrepo -- this ensures that you get a consistent snapshot of the entire tree that way. This is very similar to using pegged svn:externals in Subversion. My company has written a subrepository guide that might be helpful: http://mercurial.aragost.com/kick-start/en/subrepositories/ I know that subrepositories are used in various big companies -- we've helped some of them by improving the subrepo support in Mercurial. There is now support for recursive 'hg status' and 'hg diff' and the goal is to make subrepos more and more transparent for users. That's all the good stuff about subrepos. The bad part is that working with them isn't as smooth as working with a single repo -- it's simply a more complex workflow. If you begin referencing the subrepos by several main repos (and if you don't, why are you using subrepos in the first place?) then you'll want to configure the server-side to link the subrepos. That's not obvious at first, but I've documented it here: http://stackoverflow.com/a/7318280/110204 I would also like to warn against a too tight coupling. When you use subrepos you introduce a very tight coupling: you say "73f4e05287b4 in foo needs exactly 0f1e621d3d3b from bar". You often don't need quite that strong dependencies: http://stackoverflow.com/a/8637556/110204 I'm happy to see the talk about 0install, which I understand is a tool that will manage the dependencies better. Mercurial doesn't have anything like 'git sub-tree', though 'hg convert' has the ability to re-write history so that it looks like a subtree was in a different place (with a file map). I think that could be used to make a tool very similar to 'git sub-tree'. Please let me know if you have more questions about subrepos -- since I was responsible for adding many of the --subrepos flags in Mercurial, I know the capabilities quite well. -- Martin Geisler Mercurial links: http://mercurial.ch/
As far as I can see, scaling Boost up to a much larger number of libraries implies decentralization and decoupling, probably in the form of per-library modules or something similar. Modularization seems to have been missed in the discussions of Subversion, Git, and Mercurial. Do distributed version control systems in general and Git in particular have any important advantages/disadvantages over svn for highly modularized projects? Please, let's not waste everyone's time with a rehash of general DCVS vs CCVS pros and cons. We have beat that to death. Let's focus this thread on modularization support, particularly as it applies to Boost.
Completely agree! I am not sure if I am using the same definition of "modularization", but here are my thoughts: I would like to see the top level modularization by category, as the one listed here: http://www.boost.org/doc/libs/?view=categorized This should make the library more usable and easier to explore for a new users. For example its much easier to explore Container libraries in case all of them are under top level directory with the same name. Andrii Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
on Wed Apr 11 2012, Andrii Sydorchuk <sydorchuk.andriy-AT-gmail.com> wrote:
As far as I can see, scaling Boost up to a much larger number of libraries implies decentralization and decoupling, probably in the form of per-library modules or something similar. Modularization seems to have been missed in the discussions of Subversion, Git, and Mercurial. Do distributed version control systems in general and Git in particular have any important advantages/disadvantages over svn for highly modularized projects? Please, let's not waste everyone's time with a rehash of general DCVS vs CCVS pros and cons. We have beat that to death. Let's focus this thread on modularization support, particularly as it applies to Boost.
Completely agree! I am not sure if I am using the same definition of "modularization", but here are my thoughts:
I would like to see the top level modularization by category, as the one listed here: http://www.boost.org/doc/libs/?view=categorized This should make the library more usable and easier to explore for a new users. For example its much easier to explore Container libraries in case all of them are under top level directory with the same name.
IMO that won't work for lots of reasons, not least that some libraries are in multiple categories. It makes sense to have a tagged index that makes it easy to explore, but not, IMO, to tie that to physical location of the repositories. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
on Wed Apr 11 2012, Martin Geisler <mg-AT-aragost.com> wrote:
I'm happy to see the talk about 0install, which I understand is a tool that will manage the dependencies better.
I'm currently standing up 0install feeds for modularized boost, e.g. http://ryppl.github.com/feeds/Boost.Signals2.xml This is work-in-progress; installation doesn't complete because of the many usage dependencies (other libraries you need in order to use Signals2) that I haven't generated feeds for yet, but you can see it beginning to work if you try it (and anyone who wants to help is most welcome). The use of 0install makes modularization a non-issue where the DVCS is concerned, so I truly don't think it's worth hashing over the different ways you can handle this with Hg or Git or SVN. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 04/11/2012 04:15 PM, Dave Abrahams wrote:
The use of 0install makes modularization a non-issue where the DVCS is concerned, so I truly don't think it's worth hashing over the different ways you can handle this with Hg or Git or SVN.
Oinstall based solution sounds like it is worth investigating, but I am a bit concerned you are concluding too fast here that DVCS alternatives for inter module dependency management is not needed. As you have stated in an earlier post, most boost developers are only working on one boost library, hence a 0install solution for pulling inn all dependencies sounds like it will meet the requirements - I agree on that. However, what about when there is a need to work on more than one library? Or for that sake a boost wide fix due to changes in config, boostbook, quickbook, build, etc. What then? I guess more add-hoc use of submodule, subtree, subrepo, externals, or whatever may be set up by a script, or in worst case even manually. For that to be reasonably simple, it may however require some preference alignment within boost for what (D)VCS to use and how to set it up. -- Bjørn
on Wed Apr 11 2012, Bjørn Roald <bjorn-AT-4roald.org> wrote:
On 04/11/2012 04:15 PM, Dave Abrahams wrote:
The use of 0install makes modularization a non-issue where the DVCS is concerned, so I truly don't think it's worth hashing over the different ways you can handle this with Hg or Git or SVN.
Oinstall based solution sounds like it is worth investigating, but I am a bit concerned you are concluding too fast here that DVCS alternatives for inter module dependency management is not needed. As you have stated in an earlier post, most boost developers are only working on one boost library, hence a 0install solution for pulling inn all dependencies sounds like it will meet the requirements - I agree on that. However, what about when there is a need to work on more than one library? Or for that sake a boost wide fix due to changes in config, boostbook, quickbook, build, etc. What then?
Daniel Pfeifer had a wonderful idea, that we provide a simple way to assemble a CMake project that includes all the parts you want to work on. Of course, you're welcome to set up whatever repositories you like, with whatever submodules you like, for your own purposes.
I guess more add-hoc use of submodule, subtree, subrepo, externals, or whatever may be set up by a script, or in worst case even manually. For that to be reasonably simple, it may however require some preference alignment within boost for what (D)VCS to use and how to set it up.
I'm strongly of the opinion that it will be better for users and developers if everything in Boost uses the same infrastructure technology. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (13)
-
Andrii Sydorchuk -
Beman Dawes -
Bjørn Roald -
Dave Abrahams -
David Stone -
Jim Bosch -
Joel de Guzman -
Julian Gonggrijp -
Marco Cecchetti -
Martin Geisler -
Robert Ramey -
Rutger ter Borg -
Thomas Heller