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.
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.