Boost logo

Boost :

Subject: Re: [boost] Git hardlinks, and developing
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2013-12-04 15:12:27

On 12/04/2013 05:48 PM, Steven Watanabe wrote:
> On 12/04/2013 08:04 AM, John Maddock wrote:
>>> 1) I checked out modular Boost as per
>>> 2) Changed libs/multiprecision to the develop branch also as per
>>> 3) Added some pending changes from the old SVN Trunk that I didn't
>>> commit before the changeover.
>>> 4) Ran the tests and everything failed, even though it was passing on
>>> SVN :-(
>>> The issue was that the headers under boost/ were now *copies* of the
>>> last release and no longer pointers to the new "develop" code.
>>> Interestingly some of the hard links were updated when I ran bjam, but
>>> apparently not all :-(
>>> Running bjam -a fixes the issue, but it's a very easy trap for the
>>> unwary.... John.
>> And another thing....
>> Ran "bjam -a headers" from the root directory to force the headers to be
>> rebuilt, and the tests now build and pass OK... except that's a mistake
>> because I see that old test results that depend on those headers were
>> *not* rebuilt. So you need to bjam -a from the libs/mylib/test
>> directory as well whenever you change branches :-(
> The reason that this is failing is probably that the
> timestamps on some of the headers that you copied in
> were older than the timestamps on the original.

Some thoughts:

Assuming we have changed b2 headers to prefer symlink for individual files:

Then, in the cases where hardlinks are still used by b2 headers, does it
not make sense for b2 headers to always, unconditionally fix all
hardlinks -- all the time...? Maybe even a post checkout/reset hook in
git where the b2 headers command is allowed to fail with a warning only.

On platforms where copy is still used by b2 headers, forced
unconditional copy would trigger redundant rebuild and would make no
sense. However with a content change detection based condition for the
copy, forced copy may make a lot of sense. Maybe even better if it is
possible to also set filetime on the copy to the same as the original.
I do not think we should attempt to do this in both directions, as it
complicates too much to be worth it -- so this would not fix all
potential issues with copies, but maybe the more surprising ones that
are not self inflicted by editing files directly in the boost folders.


Boost list run by bdawes at, gregod at, cpdaniel at, john at