Re: [boost] Git Modularization Review no vote heads-up

Subject: Re: [boost] Git Modularization Review no vote heads-up
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2013-05-30 19:49:13

On Thu, 2013-05-30 at 15:34 -0700, Dave Abrahams wrote:
> on Fri May 24 2013, Bjørn Roald <bjorn-AT-4roald.org> wrote:
> 
> > On Thu, 2013-05-23 at 23:06 -0700, Dave Abrahams wrote:
> >> on Thu May 23 2013, Bjørn Roald <bjorn-AT-4roald.org> wrote:
> >> 
> >
> >> > Boost.Build would not
> >> > be the only submodule with dependencies to other submodules, would
> >> > it...
> >> 
> >> Yeah, but as Boost.Build is really the *only* client of Boost.Jam, it's
> >> hard to justify separating them.
> >
> > I understand that point of view, but if historic Jam could be used by
> > itself, why not have them as separate modules?
> 
> Because it makes everything harder.  If the Boost.Build maintainers
> would prefer to have them separated, we can do that, but I advise
> against it.

Agree, its their choice. Especially in the future.  My issue is more
about changing the past. 

> >> > This build --> jam dependency is also gone in current boost, 
> >> 
> >> I don't think so:
> >> http://ci.boost.org/svn-trac/browser/trunk/tools/build/v2/engine
> >
> > I was not aware there is a single line of history here - in case it is
> > it may be worth trying to re-join the histories if that is done by the
> > conversion.  but it seems odd to re-introduce tools/jam in
> > tools/build/jam, a new place where it has never been -- and move
> > tools/build to tools/build/build, where it has never been. 
> 
> You have to let go of the idea of the Boost super-repository having the
> actual historical paths to anything.

Ok, I can accept that, if that is how it is.  It just escapes me what
the super-repository's purpose is then.  But that is no big deal, I
guess it acts a holder of references to other boost code.

> >> > so I don't understand the need to bundle all in one repository.  It
> >> > complicates the conversion and changes file structure in history.
> >> 
> >> I don't know what you mean by "changes file structure in history" or how
> >> you conclude that it complicates the conversion.
> >
> > Well, are you saying I can check out any boost historic version from 
> > http://github.com/boostorg/boost and run the instructions of that
> > release to successfully build?  
> 
> No.  That *will not* be the case.  For that, use SVN.

Or tar-balls I guess.  This make sense as you say no global state of
history is kept or attempted to be kept, so that means no need to mangle
the history of the top level scripts in the modularized boost repo.

> > Those instructions will fail as structure of those historic commits
> > are changed beyond moving the headers. The changes in tools/build is a
> > prime example.
> >
> >> > It is better to try as far as feasible to make the conversion an
> >> > accurate reflection of history while getting a sensible set of
> >> > repositories representing modularized libraries.  Build is no a library,
> >> > and as a tool the modularization is good enough with two historic
> >> > repositories and a build --> jam dependency in the past. Current build
> >> > repository is self contained if I understand this correctly.
> >> 
> >> It's only self-contained because it contains jam in its "engine"
> >> directory.  If Boost.Jam is going to be there in the present, its
> >> revision history should be there in the past, so you can follow it.
> >
> > so are you are saying you will have some commit the build repository
> > history show how files are moved from tools/build/jam where they never
> > have been to tools/build/build/v2/engine where they never went?  Even if
> > you manage to make such a commit, how is that preserving file structure
> > in the history?
> 
> I didn't say anything about preserving file structure in the history.
> What I am saying is that you should be able to follow the changes to any
> file that is part of Boost.Jam through its history, 

Ok, In that case I follow the logic.

> and if those files
> are in the Build repository in the present but jump there from a different
> repository some time in the past, you won't be able to do that.

fair enough.  I guess I expected more than was feasible when you had
added history to the modularized boost repositories.  I understand the
need to restructure some, I guess it surprised me how many adaptations
has been done beyond the header file reorganization.

... snip...
> 
> Sorry, I just don't know what to do with this input.  I'm a bit
> overwhelmed with everything going on in my life at the moment, so I
> apologize.

no worries, I am happy with the replies given above and understands the
direction this is moving.  I have mo major issues with the choices that
has been made.

Best regards,
--
Bjørn