[cvsnt] CVS Server Side Reporting Tools?

[Bo Berglund]

On Mon, 17 Nov 2008 15:39:01 +1100, "Arthur Barrett"
<arthur.barrett at march-hare.com> wrote:

>Tony,
>
>> It's a lot more than a couple of days work..  most of the API 
>> is C++ and has all sorts of dependencies.
>> 
>
>I was thinking of a very very basic implementation of just
>CGlobalSettings and CLibraryAccess, not the whole API.
>
>Besides I didn't say I'd finish it in a couple of days, but that it'd
>give Bo something to work with, eg: if Bo can see what pattern I'm
>following then maybe he or someone else can offer to finish it off
>themselves...

Don't put too much weight on my interest. I cannot promise to do a lot
because I still have only limited time free....
I hate to see you lose time over this just because I started
commenting on this subject.

I think I will first make a simple approach and build on the code
supplied by Ronaldo Capaverde after converting it to MSSQL and also
making it more configurable for other ADO database connections.
The original code has (in my view) put too much into designtime
component properties. I will most probably change that into regular
objects instead.

If that works out OK I may look at the database end via the audit API
calls.

So first test using the parsing of RCS files from Ronaldo Capaverde
but towards a MSSQL database.

Next I will probably test it using ODBC against a SQLite database.

Then switching to getting the info via regular cvs calls rather than
direct access to the RCS files. Have to figure out how to do that in a
good way though. Any ideas how ViewVC did it when they switched from
GNU rcs calls to using the cvsnt cvs.exe?

Finally trying to get the database stuff going via audit API calls (if
at all possible for me). THis would decouple the database knowledge
from the importer.

>COM is an interesting suggestion, but I wouldn't spare more than a
>couple of minutes thinking about it until someone confirmed that things
>like Delphi really play well with it.  I know from experience that even
>though Uniface supports COM there are many COM types that it doesn't
>support and I wouldn't be at all surprised to learn that other languages
>have similar limits on the COM support.  Secondly many developers 'need'
>to learn how to call Win32 'C' functions but never bother to learn how
>to call COM functions.  At least any effort put into a 'C' API (for want
>of a better term) will benefit the largest possible base of users
>(windows/hp/solaris etc).
>

COM is a pig!
We use COM (or rather DCOM) in our automation software since 2002. It
has caused a lot of grief concerning the handling of the type
libraries and the evolution of those in order not to crash older
versions of our software. Microsoft has failed to make a reasonable
way to version type libraries so that an installer can check that it
does not inadvertently replace a newer tlb with an older one, thus
breaking existing installed applications!
We had to make a dll out of the tlb and include our own versioning
info in that so we can make the installer (still InnoSetup!) do the
right thing.
Very strange errors can also happen like when a customer had a service
pack for XP installed and the system stopped working. Noone even knew
about the SP at first and we tried in vain to get it going until we
finally found that the SP had changed the fundamental base handling in
Winows of DCOM and RPC. Had to put a strange registry entry in place
to fix that....
And lost about a week's worth of service engineer time on location (of
course half way across the world too). Not funny.

Unfortunately we are now stuck with it...
Had we known at the time we might have designed the whole system
without COM....

-- 

/Bo
(Bo Berglund, developer in Sweden)