On 10/18/2013 11:05 AM, Daniel James wrote:
The smaller modules could still feed into your boost core/feature normalization module. Although that might be too difficult to do as part of the conversion. To be clear, I propose doing most/all of these modularization changes before the conversion to git.
Are you proposing to do them concurrently/at the asme time as migrating to git? Yes, or at least before modularization is in use. But I'll go along with whatever works for the people doing this.
That's good, but I don't think it's a position shared by everyone :).
The original plan was to break the functional module up, but there was a problem with doing that in the conversion, so I was going to look into doing it afterwards instead, What problem was encountered? it was here:
http://lists.boost.org/Archives/boost/2013/05/204230.php
IIUC the problem is that the modules need to be used to recreate old versions of boost. So if hash's files were moved into a new module, the files that are currently in libs/functional/hash would be in the wrong place. But I think it should be fine if they're moved to 'libs/functional_hash' in the future.
Thanks for the link. If any part of my plan can move forward (reading the mail from Beman, that is not a certainty), I can look into that issue.
which I think can be done while preserving history. How so? Replaying the history on top of master? That's still a loss of history really, but it's better than a straight addition-of-current-version. Possibly by including all the module history in each smaller module and, if possible, rewriting the history to only include the relevant headers (this would be done before the module is in use).
I don't really see a sense in having a non-zero time interval between considering a module converted to git and considering it 'in use'. As far as I understand your mail, you want to do this splitting after conversion, but before considering it 'officially in use' or something? You are talking about re-writing history of a git repo. I still recommend modularizing first.
This means there will be duplicate history in different modules, but I don't think that would cause any real problems. I admit I haven't thought this through or done any experiments, I was leaving that for later.
Ok. Thanks, Steve.