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-26 16:39:55

On Sun, 2013-05-26 at 14:49 -0500, Rene Rivera wrote:

> I was about to mention something.. So thanks for the comment :-)
> 
> But if life is such a pain with squashing the v2 subtree.. I guess the b2
> maintainers will just have to squash the v2 at the source.. I.e. make the
> current Boost svn structure be tools/build/* moving all files and changing
> the scripts.. and especially painful adjusting the testing regression
> scripts. Which may impact the upcoming release schedules.

I may be misunderstanding you, but it was _not_ my suggestion for you to
change anything at all in svn.  Nor do I think you need to move
anything in git from tools/build/v2 to tools/build until you feel ready
for it.  E.g after next release.  I am concerned we are have different
approaches in mind and think we are talking of the same approach.

Basically, what I have in mind is keeping everything that is in active
use as-is.  Then when you are ready to restructure, at some time
convenient after the move to git, you simply do it in git.  History is
traced across a commit where you do 

git mv v2/* .  

I think, at least if done properly this should work fine, I tried it -
had to move the duplicated css file out of the way first.  

To some degree git tracing file history across moves depend on the tool
used for tracing history. There is not an explicit notion of a moved
file in git, just derived from commit changes.  So to some degree I
think it may be safer to get the conversion to do it if the result is
all tools/build/v2 files history are in tools/build.  But I would have
taken that risk and used git mv.  It is up to you though.

Off-cause you may do it in svn if you like, but then you are on a tight
schedule as you point out, and I would be checking with Daniel if the
conversion scripts can actually maintain your file history for the files
moved. I would not suggest to fix history later in git after the boost
repository commits are public.

The last option, is to ignore fixing the history with 

$ git filter-branch --tree-filter "find . -type f -maxdepth 1 -exec sed
-i -e 's|build[/\\]v2|build|g' {} \;"

all together, or just do it for the final conversion.  We do not need it
for getting all the other stuff right.  And it is questionable how
useful it is at all as special instructions or scripts are needed anyway
to build historic boost in modularized boost.  Maybe simply have a wiki
page with a bootstrap-historic.sh script along the lines of:

find . -type f -maxdepth 1 -exec sed -i -e 's|build[/\\]v2|build|g' {}
\;
... make-header-symlinks and other stuff ... 
./bootstrap.sh

--
Bjørn
> 
> 
> --