[Rivet] Refactoring [Re: Minor problems in Rivet 1.5.0]

[Ben Waugh]

It's something I read about while researching refactoring techniques for 
Atlantis. I've applied some of the thing I have learned, but not this 
one yet. I guess a command-line switch would be one possibility, or just 
to change a line in the code while working on the new implementation. Or 
if you had unit tests you could use those to get everything working 
before switching over, as described here: 
http://paulhammant.com/blog/branch_by_abstraction.html

But if it doesn't really break anything, and can be fixed quickly, then 
just replacing the existing trunk version might be OK as you say.

Cheers,
Ben

On 13/05/11 22:35, Andy Buckley wrote:
> 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 Ben Waugh                                   Tel. +44 (0)20 7679 7223
Dept of Physics and Astronomy                  Internal: 37223
University College London
London WC1E 6BT