Re: [RFC][PATCH] Add --auto-close command line option

[Vincent Legoll <vincent legoll gmail com>]

On Sat, Mar 21, 2009 at 5:48 PM, Stephen Kennedy <stevek gnome org> wrote:
> Hi Vincent,

Hello

> vc testing would be fantastic. It's historically been a troublesome
> and fragile module.

Yeah, I've seen that myself, having to revert a patch that seemed
innocuous to me, but which broke almost all vc plugins in a subtle
way... (c.f. r1267 & r1268)

>What kinds of tests do you have in mind?

Currently what I have, is a test module that is capable of creating
repositories for various VCS, generate test files, commit them,
modify them, and then launch meld in that directory, this is working
great, but the code is not sufficiently clean as is, it needs polishing.

One advantage of doing it that way is you test the whole thing, i.e.
you test meld as it will be used. So this is not so much unit testing
the vc plugins but full blown meld VC tests. Vcview, filediff & even
dirdiff are tested.

The problem is just that if you want to be able to automate meld
testing you should have a way to ask it to automatically close
after having displayed the vcview, and diffed all files via
--auto-compare.

That was the purpose of the proposed patch, which is implemented
in some hacky way, but which works and so it is already useful to
me. I wanted to know if someone has ideas to implement the same
functionality in a cleaner way...

> I would hope that 90% of the tests could be completely separated
> from meld and only use the vc module. Most errors have been
> in the vc implementations themselves, not in vcview.

I do not intend to work on vc plugins unit testing, at least not now,
I think this should be done in anyvc, and we should try to use anyvc
and get that unit testing for free. When we will start with anyvc, we
will want it to be robust and well tested...

> The one exception to that is vcview.show_patch which has broken
> as the vc formats have changed.

Yeah, I cannot count the times I single stepped through that method
;-)

> The vc interface needs to be changed to give back filenames to be
> compared instead of a patch and the current messy regex application.

Yes yes yes, I have that high in my todo list, but I thought the automated
testing would be a good thing to have beforehand...

> Also, did you see the mail a while ago from the anyvc guys?

Yes, I've already read parts of anyvc code. But I can't tell I'm ready to
do the conversion right now, I'll need to get a better understanding on
the way vcview & vc plugins work together. And cleaning the interface
between those looks like required before trying to go straight to anyvc.

> It does seem like a pity to have two such similar codebases.

Indeed

> I don't know if it's much better than what's currently in vc but the
> maintenance factor and roadmap (e.g. history operations) sound
> tempting.

Clearly this is what we should strive for, and I intend to try it. If
anyvc lacks something we need we certainly could contribute work
to add it.

-- 
Vincent Legoll