Re: Refactoring common RunOptions code

On Thu, Aug 27, 2009 at 2:54 AM, Michael Haggerty<[email protected]> wrote:
> Of course it would be nice if the refactoring were done first, but I
> wouldn't reject the patches for that reason.  I guess the question is
> whether you gain anything by submitting-then-refactoring.  If so, then
> it's OK.
>
>> 2) how to refactor? it looks like the obvious thing to do is move the
>> common code up to RunOptions.  This will be trivial for HgRunOptions,
>> since I deliberately did not change the copied methods.  But
>> GitRunOptions might need a bit more work to re-unify.
>
> Sounds reasonable.  Any cleaning up that you do on GitRunOptions would
> be appreciated but of course you are not obligated to do it yourself.

OK, then I will concentrate on reducing duplication between
{SVN,Hg}RunOptions.  I've already made a small contribution towards
doing that with GitRunOptions, but I'll leave the heavy lifting for
you (or whoever is interested).

> BTW, how is the test framework coming along?

Errr, not at all.  I have a ton of *additions* to run-tests.py that
add 6 or 7 Mercurial-specific test cases.  And of course verify-all is
waiting in the wings.  I think we should continue to rely on
run-tests.py for catching the usual stupid errors (typos, missing
imports) and basic correctness.  Verification-based testing can come
later, and should be an extra layer of safety on top of what's in
run-tests.py.  (All IMHO of course.)

I have no plans to work on turning verify-* into modules.  I think
it's a great idea, but my priority is getting HgOutputOption committed
on the svn trunk.

> I would be a little bit
> nervous about committing changes to code that used to work without
> having at least some simple tests that you haven't broken anything.

Speaking of which... my tests of Mercurial output are a tad more
complete than the existing tests of git output.  ;-)  Let me go
prepare a preview patch so you can see what I'm talking about.  I'd
like your feedback on my testing style, and I encourage you to steal
whatever good ideas I had for similarly exhaustive testing of git
output.  But I don't want to write it.  One of the big reasons I use
Mercurial rather than git can be summed up in two words: "import
mercurial".  (I.e. writing tests of git output is harder because there
is no git API.  Although when the output is a fast-import dump, I
suppose it would suffice to simply examine the text.)

Greg

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1667&dsMessageId=2387868

To unsubscribe from this discussion, e-mail: [[email protected]].