[git] Boost.Build location
I am wondering what will be the location of Boost.Build after the git switch. It seems to be part of http://github.com/boost-lib/boost right now. Maybe, it would be best to have separate git repository for Boost.Build? In particular, that would allow to fork just Boost.Build, which is important given git's inability to handle partial checkouts. It would also allow giving push access for Boost.Build to other people, without also giving access to superproject. Comments? Thanks, Volodya
2012/12/26 Vladimir Prus <ghost@cs.msu.su>:
I am wondering what will be the location of Boost.Build after the git switch. It seems to be part of http://github.com/boost-lib/boost right now.
It has its own repository: https://github.com/boost-lib/build -- Daniel
On 26.12.2012 13:26, Daniel Pfeifer wrote:
2012/12/26 Vladimir Prus <ghost@cs.msu.su>:
I am wondering what will be the location of Boost.Build after the git switch. It seems to be part of http://github.com/boost-lib/boost right now.
It has its own repository: https://github.com/boost-lib/build
Oh, that's good. Will that eventually include full version history from SVN? Thanks, Volodya
On 26.12.2012 21:30, Vladimir Prus wrote:
On 26.12.2012 13:26, Daniel Pfeifer wrote:
2012/12/26 Vladimir Prus <ghost@cs.msu.su>:
I am wondering what will be the location of Boost.Build after the git switch. It seems to be part of http://github.com/boost-lib/boost right now.
It has its own repository: https://github.com/boost-lib/build
Oh, that's good. Will that eventually include full version history from SVN?
In fact, could this repository be adjusted to be content of current tools/build/v2 ? There's very little practical reason to have history from Boost.Build V1 be present in git, and the "v2" directory at the top level makes no sense. Thanks, Volodya
On 12/26/2012 11:48 AM, Vladimir Prus wrote:
On 26.12.2012 21:30, Vladimir Prus wrote:
On 26.12.2012 13:26, Daniel Pfeifer wrote:
2012/12/26 Vladimir Prus <ghost@cs.msu.su>:
I am wondering what will be the location of Boost.Build after the git switch. It seems to be part of http://github.com/boost-lib/boost right now.
It has its own repository: https://github.com/boost-lib/build
Oh, that's good. Will that eventually include full version history from SVN?
In fact, could this repository be adjusted to be content of current tools/build/v2 ?
There's very little practical reason to have history from Boost.Build V1 be present in git, and the "v2" directory at the top level makes no sense.
What I would suggest is that we convert from svn to git manually into our own repo (since the current bridge doesn't keep history). Then push the new, full history version, into the boost subrepo. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
2012/12/26 Rene Rivera <grafikrobot@gmail.com>:
On 12/26/2012 11:48 AM, Vladimir Prus wrote:
On 26.12.2012 21:30, Vladimir Prus wrote:
On 26.12.2012 13:26, Daniel Pfeifer wrote:
2012/12/26 Vladimir Prus <ghost@cs.msu.su>:
I am wondering what will be the location of Boost.Build after the git switch. It seems to be part of http://github.com/boost-lib/boost right now.
It has its own repository: https://github.com/boost-lib/build
Oh, that's good. Will that eventually include full version history from SVN?
In fact, could this repository be adjusted to be content of current tools/build/v2 ?
There's very little practical reason to have history from Boost.Build V1 be present in git, and the "v2" directory at the top level makes no sense.
What I would suggest is that we convert from svn to git manually into our own repo (since the current bridge doesn't keep history). Then push the new, full history version, into the boost subrepo.
The current bridge is preliminary, but the final conversion will not convert history either. All libraries will start with a fresh git repository without history (History can be made accessible by grafting). If you prefer to have all history directly in your repository, you may convert it manually, of course. -- Daniel
On 27.12.2012 04:28, Daniel Pfeifer wrote:
2012/12/26 Rene Rivera <grafikrobot@gmail.com>:
On 12/26/2012 11:48 AM, Vladimir Prus wrote:
On 26.12.2012 21:30, Vladimir Prus wrote:
On 26.12.2012 13:26, Daniel Pfeifer wrote:
2012/12/26 Vladimir Prus <ghost@cs.msu.su>:
I am wondering what will be the location of Boost.Build after the git switch. It seems to be part of http://github.com/boost-lib/boost right now.
It has its own repository: https://github.com/boost-lib/build
Oh, that's good. Will that eventually include full version history from SVN?
In fact, could this repository be adjusted to be content of current tools/build/v2 ?
There's very little practical reason to have history from Boost.Build V1 be present in git, and the "v2" directory at the top level makes no sense.
What I would suggest is that we convert from svn to git manually into our own repo (since the current bridge doesn't keep history). Then push the new, full history version, into the boost subrepo.
The current bridge is preliminary, but the final conversion will not convert history either. All libraries will start with a fresh git repository without history (History can be made accessible by grafting).
Wait, what? As far as I'm concerned, conversion to git that loses history is simply unacceptable. Version control is used for software development for a good reason. Not do I find it acceptable to impose history conversion task on every individual developer. Can somebody from the Steering Committee clarify what's going on here? Thanks, Volodya
On 27.12.2012 04:28, Daniel Pfeifer wrote:
2012/12/26 Rene Rivera <grafikrobot@gmail.com>:
On 12/26/2012 11:48 AM, Vladimir Prus wrote:
On 26.12.2012 21:30, Vladimir Prus wrote:
On 26.12.2012 13:26, Daniel Pfeifer wrote:
2012/12/26 Vladimir Prus <ghost@cs.msu.su>: > > > I am wondering what will be the location of Boost.Build after > the git switch. It seems to be part of > http://github.com/boost-lib/boost right now.
It has its own repository: https://github.com/boost-lib/build
Oh, that's good. Will that eventually include full version history from SVN?
In fact, could this repository be adjusted to be content of current tools/build/v2 ?
There's very little practical reason to have history from Boost.Build V1 be present in git, and the "v2" directory at the top level makes no sense.
What I would suggest is that we convert from svn to git manually into our own repo (since the current bridge doesn't keep history). Then push the new, full history version, into the boost subrepo.
The current bridge is preliminary, but the final conversion will not convert history either. All libraries will start with a fresh git repository without history (History can be made accessible by grafting).
Wait, what? As far as I'm concerned, conversion to git that loses history is simply unacceptable. Version control is used for software development for a good reason. Not do I find it acceptable to impose history conversion task on every individual developer.
Can somebody from the Steering Committee clarify what's going on here?
Frankly, that particular piece of information is news to me as well. Granted nobody ever explicitly said history would be preserved in the process (as far as I remember), but neither did anybody explicitly say it would be lost. And I missed to ask about this - doh! I agree losing history or having to manually preserve it is unacceptable. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
On Thu, Dec 27, 2012 at 8:55 PM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
On 27.12.2012 04:28, Daniel Pfeifer wrote:
2012/12/26 Rene Rivera <grafikrobot@gmail.com>:
On 12/26/2012 11:48 AM, Vladimir Prus wrote:
On 26.12.2012 21:30, Vladimir Prus wrote:
On 26.12.2012 13:26, Daniel Pfeifer wrote: > > 2012/12/26 Vladimir Prus <ghost@cs.msu.su>: >> >> >> I am wondering what will be the location of Boost.Build after >> the git switch. It seems to be part of >> http://github.com/boost-lib/boost right now. > > > It has its own repository: https://github.com/boost-lib/build
Oh, that's good. Will that eventually include full version history from SVN?
In fact, could this repository be adjusted to be content of current tools/build/v2 ?
There's very little practical reason to have history from Boost.Build V1 be present in git, and the "v2" directory at the top level makes no sense.
What I would suggest is that we convert from svn to git manually into our own repo (since the current bridge doesn't keep history). Then push the new, full history version, into the boost subrepo.
The current bridge is preliminary, but the final conversion will not convert history either. All libraries will start with a fresh git repository without history (History can be made accessible by grafting).
Wait, what? As far as I'm concerned, conversion to git that loses history is simply unacceptable. Version control is used for software development for a good reason. Not do I find it acceptable to impose history conversion task on every individual developer.
Can somebody from the Steering Committee clarify what's going on here?
Frankly, that particular piece of information is news to me as well. Granted nobody ever explicitly said history would be preserved in the process (as far as I remember), but neither did anybody explicitly say it would be lost. And I missed to ask about this - doh!
I agree losing history or having to manually preserve it is unacceptable.
FWIW, this was mentioned on the wiki: https://svn.boost.org/trac/boost/wiki/ModCvtSvn2Git I think this was also mentioned by someone from the Committee on the list.
On 27 December 2012 11:07, Andrey Semashev <andrey.semashev@gmail.com>wrote:
https://svn.boost.org/trac/boost/wiki/ModCvtSvn2Git
I think this was also mentioned by someone from the Committee on the list.
It was discussed on the steering committee list at < https://groups.google.com/d/msg/boost-steering/XWGZYeR607I/8PNf7yRHveYJ>. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
On 27 December 2012 11:07, Andrey Semashev <andrey.semashev@gmail.com>wrote:
https://svn.boost.org/trac/boost/wiki/ModCvtSvn2Git
I think this was also mentioned by someone from the Committee on the
list.
It was discussed on the steering committee list at < https://groups.google.com/d/msg/boost-steering/XWGZYeR607I/8PNf7yRHveYJ>.
Thanks for pointing this out - so it's my fault entirely for not being aware of this (as was to be expected...). Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
Hartmut Kaiser wrote:
On 27.12.2012 04:28, Daniel Pfeifer wrote: Wait, what? As far as I'm concerned, conversion to git that loses history is simply unacceptable. Version control is used for software development for a good reason. Not do I find it acceptable to impose history conversion task on every individual developer.
Can somebody from the Steering Committee clarify what's going on here?
Frankly, that particular piece of information is news to me as well. Granted nobody ever explicitly said history would be preserved in the process (as far as I remember), but neither did anybody explicitly say it would be lost. And I missed to ask about this - doh!
I agree losing history or having to manually preserve it is unacceptable.
Hmmm.. Let's suppose for a moment that the modularization effort resulted in a repository which didn't include the current history. There's no reason that the old SVN has to go way. I guess it could be made read only. It would also be convienient that the web browsing feature be re-enabled. That is, pre-history would still be available - just not a conveniently as now. Robert Ramey
Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Thu, Dec 27, 2012 at 12:45 PM, Robert Ramey <ramey@rrsd.com> wrote:
Hmmm.. Let's suppose for a moment that the modularization effort resulted in a repository which didn't include the current history. There's no reason that the old SVN has to go way. I guess it could be made read only.
Of course! That's been the plan all along, just as we didn't blow away the old CVS repo when we switched to SVN. The point at which SVN becomes read-only has been shown on the schedule and on the action plan right from the start. See https://svn.boost.org/trac/boost/wiki/MoveToModularizedGit and https://svn.boost.org/trac/boost/wiki/ModCvtSchedule
It would also be convienient that the web browsing feature be re-enabled.
Good point. The load on the IU server should be a lot less after we switch to GitHub.
That is, pre-history would still be available - just not a conveniently as now.
As Dave points out in a subsequent post, there will likely be several ways to supply history via Git in addition to SVN. --Beman
on Thu Dec 27 2012, Beman Dawes <bdawes-AT-acm.org> wrote:
On Thu, Dec 27, 2012 at 12:45 PM, Robert Ramey <ramey@rrsd.com> wrote:
Hmmm.. Let's suppose for a moment that the modularization effort resulted in a repository which didn't include the current history. There's no reason that the old SVN has to go way. I guess it could be made read only.
Of course! That's been the plan all along, just as we didn't blow away the old CVS repo when we switched to SVN.
The point at which SVN becomes read-only has been shown on the schedule and on the action plan right from the start.
See https://svn.boost.org/trac/boost/wiki/MoveToModularizedGit and https://svn.boost.org/trac/boost/wiki/ModCvtSchedule
It would also be convienient that the web browsing feature be re-enabled.
Good point. The load on the IU server should be a lot less after we switch to GitHub.
There will also always be the GitHub browser usable on the converted history repository. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
On 28.12.2012 01:54, Dave Abrahams wrote:
on Thu Dec 27 2012, Beman Dawes <bdawes-AT-acm.org> wrote:
On Thu, Dec 27, 2012 at 12:45 PM, Robert Ramey <ramey@rrsd.com> wrote:
Hmmm.. Let's suppose for a moment that the modularization effort resulted in a repository which didn't include the current history. There's no reason that the old SVN has to go way. I guess it could be made read only.
Of course! That's been the plan all along, just as we didn't blow away the old CVS repo when we switched to SVN.
The point at which SVN becomes read-only has been shown on the schedule and on the action plan right from the start.
See https://svn.boost.org/trac/boost/wiki/MoveToModularizedGit and https://svn.boost.org/trac/boost/wiki/ModCvtSchedule
It would also be convienient that the web browsing feature be re-enabled.
Good point. The load on the IU server should be a lot less after we switch to GitHub.
There will also always be the GitHub browser usable on the converted history repository.
These all sounds like poor substitutes for actual history. If I run "git log" in program_options checkout, I really would like to see all changes ever made to what is boost/program_options and libs/program_options in the current layout. I certainly don't expect that repository to contain entire history of Boost, and so it should not be 200+ MB. But I think conveniently looking at history is one of the primary use cases of a version control system. And one of the advantages of git was supposed to be effective storage of entire history. If we're going to require that I poke at some other git repo, or svn, or commit mailing lists, or anything else for such a basic task, then I suppose we can switch to RCS just as well. Thanks, Volodya
on Fri Dec 28 2012, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
On 28.12.2012 01:54, Dave Abrahams wrote:
on Thu Dec 27 2012, Beman Dawes <bdawes-AT-acm.org> wrote:
On Thu, Dec 27, 2012 at 12:45 PM, Robert Ramey <ramey@rrsd.com> wrote:
Hmmm.. Let's suppose for a moment that the modularization effort resulted in a repository which didn't include the current history. There's no reason that the old SVN has to go way. I guess it could be made read only.
Of course! That's been the plan all along, just as we didn't blow away the old CVS repo when we switched to SVN.
The point at which SVN becomes read-only has been shown on the schedule and on the action plan right from the start.
See https://svn.boost.org/trac/boost/wiki/MoveToModularizedGit and https://svn.boost.org/trac/boost/wiki/ModCvtSchedule
It would also be convienient that the web browsing feature be re-enabled.
Good point. The load on the IU server should be a lot less after we switch to GitHub.
There will also always be the GitHub browser usable on the converted history repository.
These all sounds like poor substitutes for actual history. If I run "git log" in program_options checkout, I really would like to see all changes ever made to what is boost/program_options and libs/program_options in the current layout. I certainly don't expect that repository to contain entire history of Boost, and so it should not be 200+ MB. But I think conveniently looking at history is one of the primary use cases of a version control system. And one of the advantages of git was supposed to be effective storage of entire history.
Yes, and we can do that as long as it's clear to everyone that what you're getting for isn't "actual history;" it's a modularized past. There are a number of features of "actual history" (which is monolithic), such as changes made across several modules at once, that it won't capture.
If we're going to require that I poke at some other git repo, or svn, or commit mailing lists, or anything else for such a basic task, then I suppose we can switch to RCS just as well.
Please, let's not be dramatic about this. It would be a step you would take once for any given clone of a modularized repo. Thereafter, it would work just as you'd expect. I'm happy to go either way, as long as we are making the choice with our eyes fully open. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
on Thu Dec 27 2012, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
On 27.12.2012 04:28, Daniel Pfeifer wrote:
2012/12/26 Rene Rivera <grafikrobot@gmail.com>:
On 12/26/2012 11:48 AM, Vladimir Prus wrote:
On 26.12.2012 21:30, Vladimir Prus wrote:
On 26.12.2012 13:26, Daniel Pfeifer wrote:
2012/12/26 Vladimir Prus <ghost@cs.msu.su>: > > > I am wondering what will be the location of Boost.Build after the git > switch. It seems to be > part of http://github.com/boost-lib/boost right now.
It has its own repository: https://github.com/boost-lib/build
Oh, that's good. Will that eventually include full version history from SVN?
In fact, could this repository be adjusted to be content of current tools/build/v2 ?
There's very little practical reason to have history from Boost.Build V1 be present in git, and the "v2" directory at the top level makes no sense.
What I would suggest is that we convert from svn to git manually into our own repo (since the current bridge doesn't keep history). Then push the new, full history version, into the boost subrepo.
The current bridge is preliminary, but the final conversion will not convert history either. All libraries will start with a fresh git repository without history (History can be made accessible by grafting).
Wait, what? As far as I'm concerned, conversion to git that loses history is simply unacceptable.
Ahem; I don't think Daniel was being very clear about how we're handling history. I completely understand why you got alarmed given what was written above. Let me clarify. First of all, we are not going to "lose" history, by any stretch. A perfectly(**) accurate Git translation of Boost's history would be a sequence of snapshots of each state of the SVN filesystem. We can capture that at any time, for sure, if someone wants it. However, because SVN doesn't have first class branches or tags (you're expected to uses subdirectories as ad-hoc branches and tags), that probably wouldn't be very useful, so maybe it would be better to simply preserve the final SVN repository for that purpose A nearly perfectly accurate---but-also useful---Git translation would make all the ad-hoc SVN branches and tags into real Git branches and tags. That is what we intend to capture in the boost-history repository. Now, storing that history takes ~233M on disk, which has some implications. As noted in https://svn.boost.org/trac/boost/wiki/ModCvtSvn2Git#History, it doesn't make sense to reproduce that entire history in each modularized repo. Therefore, when someone wants a continuous look at the past, they're going to use the "git replace" command (http://git-scm.com/2010/03/17/replace.html) to link up modularized history with the monolithic history. With some standardized tag names in each repository we can make this command a one-liner for any given branch. I'm presently working on a detailed description of exactly how this can work, and expect to post it shortly. We *could* also attempt to "modularize the past" and so provide a continuous view of each library's history in its own modularized repo back to the library's first commit, by excluding all the other material that's in SVN. I am wary of doing that, for two reasons. First, it seems potentially error-prone. Second, it doesn't represent reality. The past was monolithic, not modularized. If you rewind to a given commit in one library's "modularized past," there's no way to know against which commits of other libraries it was tested or was expected to work. In fact, the second point is tied to the first point; it isn't entirely clear what a "correct" modularization of the past should look like. However, the fact that I'm wary doesn't mean I've ruled it out completely. It would certainly be possible to provide a best-effort "modularization of the past," while adding the necessary tags so that the "modularized past" can be quickly replaced with monolithic history using git-replace. I'm open to discussion about this approach. (**) Some Subversion concepts, such as properties, simply don't translate to Git, which is another reason to keep the original SVN repo archived somewhere.
Version control is used for software development for a good reason. Not do I find it acceptable to impose history conversion task on every individual developer.
Fortunately, *that* was never in the plan. I hope the above makes that clear. Regards, -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
________________________________ From: Dave Abrahams <dave@boostpro.com> Now, storing that history takes ~233M on disk, which has some implications. As noted in https://svn.boost.org/trac/boost/wiki/ModCvtSvn2Git#History, it doesn't make sense to reproduce that entire history in each modularized repo. Therefore, when someone wants a continuous look at the past, they're going to use the "git replace" command
I'm sorry but projects way bigger and complext than boost handle entire history and use full code (Linux... for example) Sorry I don't buy it.
Version control is used for software development for a good reason. Not do I find it acceptable to impose history conversion task on every individual developer.
Fortunately, *that* was never in the plan. I hope the above makes that clear.
See, loosing the integrated svn history would make everything much harder, branches, checks, merges and more. I have **never** seen any serious project loosing its history duing SCM transition, if you would try to do such a thing in a software company you would be stopped before you begin. I'm sorry but it not only HUGE surprise for any developer that had ever switched SCM, it is just tastes badly. Please either STOP it now for find a solution before it is too late. Seriously IMHO, it is just irresponsible. Boost is not the first project moving from SVN to GIT. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/
2012/12/27 Artyom Beilis <artyomtnk@yahoo.com>:
________________________________ From: Dave Abrahams <dave@boostpro.com> Now, storing that history takes ~233M on disk, which has some implications. As noted in https://svn.boost.org/trac/boost/wiki/ModCvtSvn2Git#History, it doesn't make sense to reproduce that entire history in each modularized repo. Therefore, when someone wants a continuous look at the past, they're going to use the "git replace" command
I'm sorry but projects way bigger and complext than boost handle entire history and use full code (Linux... for example)
Sorry I don't buy it.
Version control is used for software development for a good reason. Not do I find it acceptable to impose history conversion task on every individual developer.
Fortunately, *that* was never in the plan. I hope the above makes that clear.
See, loosing the integrated svn history would make everything much harder, branches, checks, merges and more.
I have **never** seen any serious project loosing its history duing SCM transition, if you would try to do such a thing in a software company you would be stopped before you begin.
I'm sorry but it not only HUGE surprise for any developer that had ever switched SCM, it is just tastes badly.
Please either STOP it now for find a solution before it is too late.
Seriously IMHO, it is just irresponsible.
Boost is not the first project moving from SVN to GIT.
Don't forget that we want to move from SVN to _modularized_ Git. Boost is not the first project doing this either. Have a look at Qt for example: The modularized repositories for Qt5 don't contain the monolithic history of Qt4. This does not mean that the history is lost! The history is preserved and can be attached to a modularized repository. -- Daniel
On Fri, Dec 28, 2012 at 2:56 AM, Daniel Pfeifer <daniel@pfeifer-mail.de> wrote:
Don't forget that we want to move from SVN to _modularized_ Git. Boost
Can't we first move to Git and only afterwards modularize things? -- Olaf
On 12/28/12 07:21, Dave Abrahams wrote:
Olaf van der Spek <ml <at> vdspek.org> writes:
Can't we first move to Git and only afterwards modularize things?
We could have decided to do that, but we didn't, and I think we made the right decision
Could you please explain a bit more why it was the right decision? Olaf's suggestion sounded reasonable to me. OTOH, I'm certainly not' familiar with git; hence, I'm probably missing something obvious to you and the others who are pioneering this effort( thanks for that). -regards, Larry
on Fri Dec 28 2012, Larry Evans <cppljevans-AT-suddenlink.net> wrote:
On 12/28/12 07:21, Dave Abrahams wrote:
Olaf van der Spek <ml <at> vdspek.org> writes:
Can't we first move to Git and only afterwards modularize things?
We could have decided to do that, but we didn't, and I think we made the right decision
Could you please explain a bit more why it was the right decision?
1. I believe that in this case, two disruptions are more disruptive than one. 2. I believe that without modularization, the move to Git does not sufficiently decouple development of individual libraries to be a win for Boost. 3. We're ready now; we have considered all the decisions for years and we believe the plan is solid. 4. Personally, my availability to work on this is likely to get much smaller soon. If we don't get this done now, the modularization parts (which I consider paramount) might never get done. 5. Maintaining the unofficial modularized mirrors without having them be official for an indefinite period going forward is a resource drain I don't think we can afford.
Olaf's suggestion sounded reasonable to me. OTOH, I'm certainly not' familiar with git; hence, I'm probably missing something obvious to you and the others who are pioneering this effort( thanks for that).
You're welcome. Thank you for your trust in our several years of research and work on this. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
On 28.12.2012 18:32, Dave Abrahams wrote:
on Fri Dec 28 2012, Larry Evans <cppljevans-AT-suddenlink.net> wrote:
On 12/28/12 07:21, Dave Abrahams wrote:
Olaf van der Spek <ml <at> vdspek.org> writes:
Can't we first move to Git and only afterwards modularize things?
We could have decided to do that, but we didn't, and I think we made the right decision
Could you please explain a bit more why it was the right decision?
1. I believe that in this case, two disruptions are more disruptive than one.
2. I believe that without modularization, the move to Git does not sufficiently decouple development of individual libraries to be a win for Boost.
3. We're ready now; we have considered all the decisions for years and we believe the plan is solid.
4. Personally, my availability to work on this is likely to get much smaller soon. If we don't get this done now, the modularization parts (which I consider paramount) might never get done.
Dave, Those last two points seem weak to me. - It really does not matter how much calendar time you've spent on this, if the proposed plan raises concerns - Rushing a solution that has concerns just because you'll be out of time tomorrow, or because there's some other deadline, simply creates technical debt, which presumably you expect to be paid by others - if only in terms of extra dancing around necessary when "git blame" fails to report anything meaningful. From a user point of view, I don't see what's wrong with having each module contain changes to its original content adjust for directory layout change. Thanks, Volodya
I don't have anything really specific to post here. I would just like to say that I support the efforts of the people doing this and really appreciate the effort and sacrifice that they are undertaking. I really doubt that it's appreciated to the extent that it should be. Boost has grown by a huge amount over the past 10 years. (maybe close to factor 10) This growth of a large system of coupled (some loosely and some not so loosley) components doesn't scale. We see it all the time in * slower testing and more demand on testing resources. * infrastructure loading and maintainence (e.g. SVN is slower and slower and we had to disable SVN browsing through track) * more time required to actually make a boost library and make it available for review. * longer and longer review queue. * The C++ community (and spefically Boost) with the most meager of resources has managed to bring evil empires to their knees and force the dark powers to concede that their weapons (java, C#, etc ....) are no match more powerful tools in the hands of a small band of zealots who worship the cause of pristine code. But with victory comes certain responsabilities. In particular this means actually providing the solutions that we claim the others have failed to provide. We have C++11 - now we need more libraries. - lot's more. Modularization of Boost is an essential step along this path. I'm not saying it won't be painful or inconvenient. But statements like "it's unacceptable to ..." ignore the fact that the only really "unacceptable" thing is the status quo. Robert Ramey
"Robert Ramey" <ramey@rrsd.com> writes:
Modularization of Boost is an essential step along this path. I'm not saying it won't be painful or inconvenient. But statements like "it's unacceptable to ..." ignore the fact that the only really "unacceptable" thing is the status quo.
+100 Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)
on Fri Dec 28 2012, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
On 28.12.2012 18:32, Dave Abrahams wrote:
on Fri Dec 28 2012, Larry Evans <cppljevans-AT-suddenlink.net> wrote:
On 12/28/12 07:21, Dave Abrahams wrote:
Olaf van der Spek <ml <at> vdspek.org> writes:
Can't we first move to Git and only afterwards modularize things?
We could have decided to do that, but we didn't, and I think we made the right decision
Could you please explain a bit more why it was the right decision?
1. I believe that in this case, two disruptions are more disruptive than one.
2. I believe that without modularization, the move to Git does not sufficiently decouple development of individual libraries to be a win for Boost.
3. We're ready now; we have considered all the decisions for years and we believe the plan is solid.
4. Personally, my availability to work on this is likely to get much smaller soon. If we don't get this done now, the modularization parts (which I consider paramount) might never get done.
Dave,
Those last two points seem weak to me.
You're entitled to that opinion. I was merely answering Larry's question about the source of my opinion.
- It really does not matter how much calendar time you've spent on this, if the proposed plan raises concerns
- Rushing a solution that has concerns just because you'll be out of time tomorrow, or because there's some other deadline, simply creates technical debt, which presumably you expect to be paid by others - if only in terms of extra dancing around necessary when "git blame" fails to report anything meaningful.
From a user point of view, I don't see what's wrong with having each module contain changes to its original content adjust for directory layout change.
Only that it isn't an entirely accurate picture of history. It might still be better than the alternative, though. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
Hi, On Fri, Dec 28, 2012 at 7:04 AM, Artyom Beilis <artyomtnk@yahoo.com> wrote:
make sense to reproduce that entire history in each modularized repo. Therefore, when someone wants a continuous look at the past, they're going to use the "git replace" command
I'm sorry but projects way bigger and complext than boost handle entire history and use full code (Linux... for example)
Sorry I don't buy it.
I don't, either. Please just 'git clone' pulls ENTIRE HISTORY. Less than 100GB of storage is not so huge in (almost) 2013. Even the low-end SSD can contain ~128GB. If the storage really matters, he can always use 'shallow repository', using 'git clone --depth N'. -- Ryo IGARASHI, Ph.D. rigarash@gmail.com
On December 28, 2012 5:59:22 AM Ryo IGARASHI <rigarash@gmail.com> wrote:
Hi,
On Fri, Dec 28, 2012 at 7:04 AM, Artyom Beilis <artyomtnk@yahoo.com> wrote:
make sense to reproduce that entire history in each modularized repo. Therefore, when someone wants a continuous look at the past, they're going to use the "git replace" command
I'm sorry but projects way bigger and complext than boost handle entire history and use full code (Linux... for example)
Sorry I don't buy it.
I don't, either. Please just 'git clone' pulls ENTIRE HISTORY. Less than 100GB of storage is not so huge in (almost) 2013. Even the low-end SSD can contain ~128GB.
If the storage really matters, he can always use 'shallow repository', using 'git clone --depth N'.
As Dave mentioned, the entire history is ~233MiB. Multiply that by the number of libraries in Boost and you easily reach multi-GiB checkouts when using the monolithic Boost (as we all are supposed to be for the moment). I think this is unacceptable either, even though I'm not a maintainer. If the history is preserved, it should also be split between the library repositories.
On December 28, 2012 5:59:22 AM Ryo IGARASHI <rigarash@gmail.com> wrote:
Hi,
On Fri, Dec 28, 2012 at 7:04 AM, Artyom Beilis <artyomtnk@yahoo.com> wrote:
make sense to reproduce that entire history in each modularized repo. Therefore, when someone wants a continuous look at the past, they're going to use the "git replace" command
I'm sorry but projects way bigger and complext than boost handle entire history and use full code (Linux... for example)
Sorry I don't buy it.
I don't, either. Please just 'git clone' pulls ENTIRE HISTORY. Less than 100GB of storage is not so huge in (almost) 2013. Even the low-end SSD can contain ~128GB.
If the storage really matters, he can always use 'shallow repository', using 'git clone --depth N'.
As Dave mentioned, the entire history is ~233MiB. Multiply that by the number of libraries in Boost and you easily reach multi-GiB checkouts when using the monolithic Boost (as we all are supposed to be for the moment). I think this is unacceptable either, even though I'm not a maintainer. If the history is preserved, it should also be split between the library repositories.
Is there no way to have each library share the same copy of the monolithic history? Then the new monolithic repo should be about the same size as the current one. Regards, Nate
on Fri Dec 28 2012, Nathan Ridge <zeratul976-AT-hotmail.com> wrote:
On December 28, 2012 5:59:22 AM Ryo IGARASHI <rigarash@gmail.com> wrote:
Hi,
On Fri, Dec 28, 2012 at 7:04 AM, Artyom Beilis <artyomtnk@yahoo.com> wrote:
make sense to reproduce that entire history in each modularized repo.
Therefore, when someone wants a continuous look at the past, they're going to use the "git replace" command
I'm sorry but projects way bigger and complext than boost handle entire history and use full code (Linux... for example)
Sorry I don't buy it.
I don't, either. Please just 'git clone' pulls ENTIRE HISTORY. Less than 100GB of storage is not so huge in (almost) 2013. Even the low-end SSD can contain ~128GB.
If the storage really matters, he can always use 'shallow repository', using 'git clone --depth N'.
As Dave mentioned, the entire history is ~233MiB. Multiply that by the number of libraries in Boost and you easily reach multi-GiB checkouts when using the monolithic Boost (as we all are supposed to be for the moment). I think this is unacceptable either, even though I'm not a maintainer. If the history is preserved, it should also be split between the library repositories.
Is there no way to have each library share the same copy of the monolithic history? Then the new monolithic repo should be about the same size as the current one.
There is a way, but it comes with caveats. This, like shallow cloning, is something that could be done entirely under script control but I wouldn't want to have people use it casually. For more detail, see http://kerneltrap.org/mailarchive/git/2007/6/5/248246 -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
on Thu Dec 27 2012, Ryo IGARASHI <rigarash-AT-gmail.com> wrote:
I don't, either. Please just 'git clone' pulls ENTIRE HISTORY. Less than 100GB of storage is not so huge in (almost) 2013. Even the low-end SSD can contain ~128GB.
If the storage really matters, he can always use 'shallow repository', using 'git clone --depth N'.
http://stackoverflow.com/questions/6900103/why-cant-i-push-from-a-shallow-cl... explains that shallow clones do not work very well for everyday use cases, and are (at best) quite complex to use correctly. We could conceivably use them as part of automatic testing, *if* we got the scripts just right. I don't believe it would be a good idea to ask anyone to use them directly. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
Artyom Beilis <artyomtnk <at> yahoo.com> writes:
I'm sorry but projects way bigger and complext than boost handle entire history and use full code (Linux... for example)
Right, but those projects aren't being split into hundreds of individual modules which will often coexist in separate repositories on the same machine. Always storing the full history of all of Boost in each of those individual repositories doesn't make sense. Part of the point of this transition is to make development less encumbered for everyone, and that would have the opposite effect.
I'm sorry but projects way bigger and complext than boost handle entire history and use full code (Linux... for example) Right, but those projects aren't being split into hundreds of individual modules which will often coexist in separate repositories on the same machine. Always storing the full history of all of Boost in each of those individual repositories doesn't make sense. Part of the point of this transition is to make development less encumbered for everyone, and that would have the opposite effect.
isn't there a middle way between `lose all history' and `keep all history'? i didn't follow the whole discussion, but from my understanding the new layout for a lib `foo` is basically the content of libs/foo and boost/foo moved to include/boost/foo. so isn't it possible to rewrite the history in a way to keep the the old history, but filter out everything which is not in libs/foo or boost/foo? then each modular repository would have only the history relevant for that specific lib. it will require some `git filter-branch` magic, but in theory it should work. something like: * git-svn to import the full trunk * git filter-branch --index-filter '${remove everything except libs/foo and boost/foo}' * git mv boost libs/foo/include * git mv libs/foo . that should leave the resulting repository at an acceptable size, but keep the history that is relevant for the individual modules ... has this been considered or are there arguments against this approach? tim
on Fri Dec 28 2012, Tim Blechmann <tim-AT-klingt.org> wrote:
I'm sorry but projects way bigger and complext than boost handle entire history and use full code (Linux... for example) Right, but those projects aren't being split into hundreds of individual modules which will often coexist in separate repositories on the same machine. Always storing the full history of all of Boost in each of those individual repositories doesn't make sense. Part of the point of this transition is to make development less encumbered for everyone, and that would have the opposite effect.
isn't there a middle way between `lose all history'
Stop. We are not proposing to lose all history.
and `keep all history'?
In fact, we are proposing to keep all history.
i didn't follow the whole discussion,
I suggest following it more closely. This alarmism about losing history has gotten seriously out-of-hand, IMO, and the only way to bring it under control is for people to pay close attention to what's actually being proposed.
but from my understanding the new layout for a lib `foo` is basically the content of libs/foo and boost/foo moved to include/boost/foo.
Not exactly, but the moral equivalent.
so isn't it possible to rewrite the history in a way to keep the the old history, but filter out everything which is not in libs/foo or boost/foo? then each modular repository would have only the history relevant for that specific lib.
that should leave the resulting repository at an acceptable size, but keep the history that is relevant for the individual modules ... has this been considered or are there arguments against this approach?
Please re-read http://article.gmane.org/gmane.comp.lib.boost.devel/237389/ where I called this "modularizing the past." We can do it, but I have some concerns. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
i didn't follow the whole discussion, I suggest following it more closely. This alarmism about losing history has gotten seriously out-of-hand, IMO, and the only way to bring it under control is for people to pay close attention to what's actually being proposed.
well, i *did* check the history of the libraries at github, which contain a lot of `latest from svn' messages, which is not exactly helpful when annotating sources or reading log messages ... but having lost my history when importing my libs from git into svn, i personally don't really care ... it could however be an issue for people working on older libraries ...
so isn't it possible to rewrite the history in a way to keep the the old history, but filter out everything which is not in libs/foo or boost/foo? then each modular repository would have only the history relevant for that specific lib. that should leave the resulting repository at an acceptable size, but keep the history that is relevant for the individual modules ... has this been considered or are there arguments against this approach? Please re-read http://article.gmane.org/gmane.comp.lib.boost.devel/237389/ where I called this "modularizing the past." We can do it, but I have some concerns.
keeping the history in an archive and outside of the new modularized repositories *is* the equivalent of loosing the archive for development purposes, as it cannot be used during the development workflow (e.g. IDE integrations for annotations). of course, a modularized history is not `reality' and we won't be able to bisect issues for example or checkout specific tags ... iac, i'd rather have a `modularized past', knowing where certain code comes from and why it is there than a fully working `past' (if this is required, one can always go to the archive) ... tim
On 12/28/2012 9:24 AM, Tim Blechmann wrote:
i didn't follow the whole discussion, I suggest following it more closely. This alarmism about losing history has gotten seriously out-of-hand, IMO, and the only way to bring it under control is for people to pay close attention to what's actually being proposed.
...snip...
well, i *did* check the history of the libraries at github, which contain a lot of `latest from svn' messages, which is not exactly helpful when annotating sources or reading log messages ... but having lost my history when importing my libs from git into svn, i personally don't really care ... it could however be an issue for people working on older libraries ...
so isn't it possible to rewrite the history in a way to keep the the old history, but filter out everything which is not in libs/foo or boost/foo? then each modular repository would have only the history relevant for that specific lib. that should leave the resulting repository at an acceptable size, but keep the history that is relevant for the individual modules ... has this been considered or are there arguments against this approach? Please re-read http://article.gmane.org/gmane.comp.lib.boost.devel/237389/ where I called this "modularizing the past." We can do it, but I have some concerns.
iac, i'd rather have a `modularized past', knowing where certain code comes from and why it is there than a fully working `past' (if this is required, one can always go to the archive) ...
I have followed the whole discussion, and think the "modularized past" is an optimal middle ground. A simple note somewhere, to the effect that commits made before X date are from the monolithic era and are not expected to compile, would explain the situation to new developers. I'm not a fan of git, but I totally understand that it's a necessary evil for a project as large and with as many developers as Boost, so thank you for handling the migration. It will be interesting to see how the modularization will play with my current usage of BCP to distribute the boost source subset we use. Thanks, -Matt
on Fri Dec 28 2012, Tim Blechmann <tim-AT-klingt.org> wrote:
i didn't follow the whole discussion, I suggest following it more closely. This alarmism about losing history has gotten seriously out-of-hand, IMO, and the only way to bring it under control is for people to pay close attention to what's actually being proposed.
well, i *did* check the history of the libraries at github,
That's not what I'm talking about.
which contain a lot of `latest from svn' messages, which is not exactly helpful when annotating sources or reading log messages ... but having lost my history when importing my libs from git into svn, i personally don't really care ... it could however be an issue for people working on older libraries ...
Those repositories are not an example of what you'll see eventually. The history in those repos is entirely artificial and will be blown away.
so isn't it possible to rewrite the history in a way to keep the the old history, but filter out everything which is not in libs/foo or boost/foo? then each modular repository would have only the history relevant for that specific lib. that should leave the resulting repository at an acceptable size, but keep the history that is relevant for the individual modules ... has this been considered or are there arguments against this approach?
Please re-read http://article.gmane.org/gmane.comp.lib.boost.devel/237389/ where I called this "modularizing the past." We can do it, but I have some concerns.
keeping the history in an archive and outside of the new modularized repositories *is* the equivalent of loosing the archive for development purposes, as it cannot be used during the development workflow
No, that's wrong. After the appropriate "git replace" command it's just as though the history was included in the first place.
(e.g. IDE integrations for annotations).
I don't know what you mean here.
of course, a modularized history is not `reality' and we won't be able to bisect issues for example or checkout specific tags ...
iac, i'd rather have a `modularized past', knowing where certain code comes from and why it is there than a fully working `past' (if this is required, one can always go to the archive) ...
As noted earlier, we can create a "best effort" modularized past. However, there are some caveats. For example, some files have probably been moved around in ways that could cause that history to appear to lose the file in any given modularized repo, while it shows up in some other modularized repo. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
On Fri, Dec 28, 2012 at 11:02 AM, Dave Abrahams <dave@boostpro.com> wrote:
on Fri Dec 28 2012, Tim Blechmann <tim-AT-klingt.org> wrote:
... of course, a modularized history is not `reality' and we won't be able to bisect issues for example or checkout specific tags ...
iac, i'd rather have a `modularized past', knowing where certain code comes from and why it is there than a fully working `past' (if this is required, one can always go to the archive) ...
As noted earlier, we can create a "best effort" modularized past. However, there are some caveats. For example, some files have probably been moved around in ways that could cause that history to appear to lose the file in any given modularized repo, while it shows up in some other modularized repo.
Speaking as a developer, the most common everyday use I (and probably others) make of history is to look at the log for a library (or subset) and then look at a particular changeset. IIUC, a "best effort" modularized past would work fine for that use, except for the rare case where a file moved between libraries. It is very rare for me to want to switch all of a Boost working copy back to some past tag or revision. So as long as all the known caveats are documented, I'd prefer "best effort" modularized history, at least as I currently understand it. --Beman
on Thu Dec 27 2012, Artyom Beilis <artyomtnk-AT-yahoo.com> wrote:
________________________________ From: Dave Abrahams <dave@boostpro.com> Now, storing that history takes ~233M on disk, which has some implications. As noted in https://svn.boost.org/trac/boost/wiki/ModCvtSvn2Git#History, it doesn't make sense to reproduce that entire history in each modularized repo. Therefore, when someone wants a continuous look at the past, they're going to use the "git replace" command
I'm sorry but projects way bigger and complext than boost handle entire history and use full code (Linux... for example)
Sorry I don't buy it.
Version control is used for software development for a good reason. Not do I find it acceptable to impose history conversion task on every individual developer.
Fortunately, *that* was never in the plan. I hope the above makes that clear.
See, loosing the integrated svn history would make everything much harder, branches, checks, merges and more.
But, as noted, we are NOT losing any history. And, no, I don't believe the plan we have in place will make anything much harder.
I have **never** seen any serious project loosing its history duing SCM transition, if you would try to do such a thing in a software company you would be stopped before you begin.
Thank you for educating me on how things are done in software companies ;-)
I'm sorry but it not only HUGE surprise for any developer that had ever switched SCM, it is just tastes badly.
Please either STOP it now for find a solution before it is too late.
Seriously IMHO, it is just irresponsible.
Boost is not the first project moving from SVN to GIT.
This history splitting is not about which SCM we're using, it's about the combined effects of modularization and DVCS use, and apparently other projects, such as Qt, did exactly the same thing we are proposing when they modularized. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
2012/12/27 Dave Abrahams <dave@boostpro.com>:
on Thu Dec 27 2012, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
On 27.12.2012 04:28, Daniel Pfeifer wrote:
2012/12/26 Rene Rivera <grafikrobot@gmail.com>:
On 12/26/2012 11:48 AM, Vladimir Prus wrote:
On 26.12.2012 21:30, Vladimir Prus wrote:
On 26.12.2012 13:26, Daniel Pfeifer wrote: > > 2012/12/26 Vladimir Prus <ghost@cs.msu.su>: >> >> >> I am wondering what will be the location of Boost.Build after the git >> switch. It seems to be >> part of http://github.com/boost-lib/boost right now. > > > It has its own repository: https://github.com/boost-lib/build
Oh, that's good. Will that eventually include full version history from SVN?
In fact, could this repository be adjusted to be content of current tools/build/v2 ?
There's very little practical reason to have history from Boost.Build V1 be present in git, and the "v2" directory at the top level makes no sense.
What I would suggest is that we convert from svn to git manually into our own repo (since the current bridge doesn't keep history). Then push the new, full history version, into the boost subrepo.
The current bridge is preliminary, but the final conversion will not convert history either. All libraries will start with a fresh git repository without history (History can be made accessible by grafting).
Wait, what? As far as I'm concerned, conversion to git that loses history is simply unacceptable.
Ahem; I don't think Daniel was being very clear about how we're handling history. I completely understand why you got alarmed given what was written above.
Apologies. I thought we were talking about the conversion that creates the "boost-lib/build" repository (among others), not the conversion to Git in general.
Let me clarify. First of all, we are not going to "lose" history, by any stretch.
A perfectly(**) accurate Git translation of Boost's history would be a sequence of snapshots of each state of the SVN filesystem. We can capture that at any time, for sure, if someone wants it. However, because SVN doesn't have first class branches or tags (you're expected to uses subdirectories as ad-hoc branches and tags), that probably wouldn't be very useful, so maybe it would be better to simply preserve the final SVN repository for that purpose
A nearly perfectly accurate---but-also useful---Git translation would make all the ad-hoc SVN branches and tags into real Git branches and tags. That is what we intend to capture in the boost-history repository.
Now, storing that history takes ~233M on disk, which has some implications. As noted in https://svn.boost.org/trac/boost/wiki/ModCvtSvn2Git#History, it doesn't make sense to reproduce that entire history in each modularized repo. Therefore, when someone wants a continuous look at the past, they're going to use the "git replace" command (http://git-scm.com/2010/03/17/replace.html) to link up modularized history with the monolithic history. With some standardized tag names in each repository we can make this command a one-liner for any given branch. I'm presently working on a detailed description of exactly how this can work, and expect to post it shortly.
We *could* also attempt to "modularize the past" and so provide a continuous view of each library's history in its own modularized repo back to the library's first commit, by excluding all the other material that's in SVN. I am wary of doing that, for two reasons. First, it seems potentially error-prone. Second, it doesn't represent reality. The past was monolithic, not modularized. If you rewind to a given commit in one library's "modularized past," there's no way to know against which commits of other libraries it was tested or was expected to work. In fact, the second point is tied to the first point; it isn't entirely clear what a "correct" modularization of the past should look like.
However, the fact that I'm wary doesn't mean I've ruled it out completely. It would certainly be possible to provide a best-effort "modularization of the past," while adding the necessary tags so that the "modularized past" can be quickly replaced with monolithic history using git-replace. I'm open to discussion about this approach.
(**) Some Subversion concepts, such as properties, simply don't translate to Git, which is another reason to keep the original SVN repo archived somewhere.
Version control is used for software development for a good reason. Not do I find it acceptable to impose history conversion task on every individual developer.
Fortunately, *that* was never in the plan. I hope the above makes that clear.
If Rene suggests to convert Boost.Build's history manually, I don't see a reason to interfere.
Regards,
-- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
on Thu Dec 27 2012, Daniel Pfeifer <daniel-AT-pfeifer-mail.de> wrote:
Version control is used for software development for a good reason. Not do I find it acceptable to impose history conversion task on every individual developer.
Fortunately, *that* was never in the plan. I hope the above makes that clear.
If Rene suggests to convert Boost.Build's history manually, I don't see a reason to interfere.
Me neither. In fact, concerns about "modularizing the past" probably are much less of an issue with Boost.Build than with the other libraries, most of which have other library dependencies. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
On 28 December 2012 14:51, Dave Abrahams <dave@boostpro.com> wrote:
If Rene suggests to convert Boost.Build's history manually, I don't see a reason to interfere.
I'll probably do the same for quickbook and boostbook. Also, the odeint developers want to use their existing git repo.
On 28.12.2012 06:27, Daniel Pfeifer wrote:
(**) Some Subversion concepts, such as properties, simply don't translate to Git, which is another reason to keep the original SVN repo archived somewhere.
Version control is used for software development for a good reason. Not do I find it acceptable to impose history conversion task on every individual developer.
Fortunately,*that* was never in the plan. I hope the above makes that clear. If Rene suggests to convert Boost.Build's history manually, I don't see a reason to interfere.
I would much rather such conversion is done by whomever is pushing for git conversion, rather that putting this on Rene's plate. - Volodya
on Fri Dec 28 2012, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
On 28.12.2012 06:27, Daniel Pfeifer wrote:
(**) Some Subversion concepts, such as properties, simply don't translate to Git, which is another reason to keep the original SVN repo archived somewhere.
Version control is used for software development for a good reason. Not do I find it acceptable to impose history conversion task on every individual developer.
Fortunately,*that* was never in the plan. I hope the above makes that clear. If Rene suggests to convert Boost.Build's history manually, I don't see a reason to interfere.
I would much rather such conversion is done by whomever is pushing for git conversion, rather that putting this on Rene's plate.
I agree. If there's consensus for synthesizing a "modularized past," we'll do it for everyone. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
participants (18)
-
Alexander Lamaison -
Andrey Semashev -
Artyom Beilis -
Beman Dawes -
Daniel James -
Daniel Pfeifer -
Dave Abrahams -
Hartmut Kaiser -
Larry Evans -
Matt Chambers -
Nathan Ridge -
Nevin Liber -
Olaf van der Spek -
Rene Rivera -
Robert Ramey -
Ryo IGARASHI -
Tim Blechmann -
Vladimir Prus