[Rivet] Minor problems in Rivet 1.5.0

[Andy Buckley]

Thanks, Ben. I guess the trick is to implement it in a more useful way 
than adding a voluntary --break-inconveniently command line switch ;)

As this particular crash only happens in the very last microseconds of 
the process exiting, i.e. after the AIDA file has been written out, it's 
essentially a cosmetic thing. So I'm still tempted to enable it in the 
trunk once 1.5.1 is out.

Andy


On 10/05/11 22:33, Ben Waugh wrote:
> Hi Andy,
>
> On 10/05/11 13:49, Andy Buckley wrote:
>> On 10/05/11 13:39, Frank Siegert wrote:
>>> Hi Andy,
>>>
>>> On 10/05/11 14:13, Andy Buckley wrote:
>>>> and I think we should then
>>>> pull the singleton into the trunk, where it *will* break things.
>>>
>>> I would prefer if this could go on a branch as long as we know that
>>> it'll break things (and won't be fixed within a day or so). There are
>>> quite a few people who are using Rivet trunk (partly because we have
>>> recommended this!) and might not be aware of the update freeze that they
>>> should adhere to. So by principle of least surprise I'd say let's leave
>>> trunk in a working state as far as we can.
>>
>> I was trying to find a way to ensure that "developers" other than myself
>> would have to confront this issue. My suspicion is that if it sits on a
>> branch then only I will check it out, and all that will happen is that
>> the truck changes get periodically merged onto the branch! Any
>> suggestions? Yes, I know it's a problem in "my bit", and no, I don't
>> really know how to fix it ;)
>
> I don't know how to fix it, or even exactly what you are fixing, but a
> general approach that *might* help is so-called "branch by abstraction"
> (as opposed to "branch by source control"). Basically you have both
> implementations in the trunk, with some additional layer of abstraction
> above them. Then you can switch implementations easily, but other users
> can continue with the existing working one. It doesn't force other
> developers to confront anything of course, but it does keep the trunk in
> a usable (and releasable) state and means other developers at least
> *have* the new version without having to check out a separate branch.
>
> For a better but longer description, see
> http://continuousdelivery.com/2011/05/make-large-scale-changes-incrementally-with-branch-by-abstraction/
>
>
> The devil is in the details, and this may not be helpful at all, but I
> thought I'd mention it.
>
> Cheers,
> Ben
>
>>
>> Andy
>>
>


-- 
Dr Andy Buckley
SUPA Advanced Research Fellow
Particle Physics Experiment Group, University of Edinburgh

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.