[KDev4] CVS plugin

[Matt Rogers]

On Apr 12, 2007, at 10:30 AM, Robert Gruber wrote:

> On Thu, 12 Apr 2007 07:13:51 Matt Rogers wrote:
>
>> 1. No documentation, unless there's some in the code, which I've yet
>> to look at. An explanation of how the plugin is designed, where
>> people can find things, etc. would be nice to have. Makes it easier
>> for others to go looking through the code for hints, tips, and  
>> examples.
> Take a look at the API documentaion, for example:
> http://www.kdevelop.org/HEAD/doc/api/html/classCvsProxy.html
>
> But I'll write down some additional pieces and commit a file with  
> some background information.
>

Thanks. Even just a file that says "here where x is at, here's where  
y is at, etc." is helpful to people that are looking at the code for  
the first time.

>> 2. No testing. How do we know it works? Are you sure it doesn't have
>> any bugs? How do we prevent the code from regressing while developing
>> it? Adding tests answers all three of those questions. Please
>> consider adding some unit and/or functional tests. Qt provides a nice
>> library called QTestLib for that sort of thing.
> At the moment I don't see any reason nor any possibility to write
> unit tests. All that the plugin does (till now) is calling the
> cvs commandline client and displaying it's output.
> Therefor any tests would need a connection to a CVS-server and a
> checked-out working-copy of a specific repository from that server.
> So if I would write and commit a test nobody else than me would be
> able to execute it, as no one would have that working-copy and
> nobody has access to my CVS server.
>

If a person has CVS installed, we could create a test repository,  
fill it with some files, and check it out if needed.
Just because all you're doing is called the CVS client doesn't mean  
that we shouldn't test the parsing of that output. And for that, we  
wouldn't even need a CVS checkout, just some examples of what we get  
out of the CVS server.

>
>> 3. Filenames, and possibly classnames that are abbreviated. Please s/
>> dlg/dialog/ in your filenames and your classnames if you followed the
>> filename  = classname convention.
> Done.
>
>
>> 4. files with underscores in their name. please remove those.
> I don't want to point the finger at somebody else, but this
> seams to be common practice. Almost all plugins named the files
> that implement the plugin-class *_part.[cpp|h]
> That's the only reason why I did so too.
> But I'll be happy to change that...
>
>
> Robert
>

Thanks. I'd like to remove all the underscores from the filenames,  
and i'm even guilty of it it in my cmake tests, i think.
--
Matt