Re: [boost] Git hardlinks, and developing

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:
> AMDG
>
> On 12/04/2013 08:04 AM, John Maddock wrote:
>>> 1) I checked out modular Boost as per
>>> https://svn.boost.org/trac/boost/wiki/TryModBoost
>>> 2) Changed libs/multiprecision to the develop branch also as per
>>> https://svn.boost.org/trac/boost/wiki/TryModBoost
>>> 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.

--
Bjørn