Should GnuCash use an external QOF library?

[Neil Williams]

On Wednesday 11 January 2006 8:38 pm, Derek Atkins wrote:
> Here's a wild idea.  Call me strange, but...

I might just do that - you must know lots of things about svn that I don't.
(not surprising)
:-)

> Neil: how would you feel about relocating QOF-CVS to it's own module
> on the GnuCash SVN server? 

Honestly? First thoughts were: "run away!!!"

> E.g., how would you feel about: 
>
>    http://svn.gnucash.org/repo/libqof/trunk/...
>                                      /branches/...
>                                      /tags/...
>
> This way the gnucash developers can still make changes to libqof, 

How is SF different to having QOF in svn on gnucash servers? It's still two 
separate trees. The files still need to be copied around between the two and 
that's as easily done on CVS as on svn.

Is it just the account setups? svn hooks? It's not that much harder to set up 
SF accounts and then attach those to QOF at SF.

If we all had SF accounts and I set QOF at SF so that each of us has CVS write 
access, how (exactly) does that differ from having QOF in svn at gnucash?
(apart from any personal dislike of SF)

TBH, I'm really not keen on converting QOF to svn. I tolerate svn for the sake 
of gnucash but it isn't my favourite and I am still *much* happier on CVS. 
(Plus my IDE does not support svn, it does support CVS.)

Are you saying commits can go to both trees at the same time? Or that entire 
trees can be merged? How much control is there over that process? 

> and it 
> would be easy to merge changes from libqof into gnucash (and back)..

How? I really don't understand that bit. How can it be easy to merge between 
different trees?

The build environment for QOF is very different to gnucash/lib/libqof and is 
likely to become more different as the embedded work progresses. gnucash has 
no need for the kind of cross-compiler / limited space build that QOF will be 
able to enable with a separate build configuration. So merging QOF code into 
lib/libqof cannot be done blindly, it needs a few tweaks - especially for the 
Makefile.am files.

> If there are additional libqof devs at SF I could get them an account
> on SVN..

Only Linas.
:-(

> Eventually, if you wish, you could migrate back to SF CVS if you really
> want.

(I think I would, yes!)
:-)

> Just a wild idea that might help everyone involved.

I'm unconvinced, sorry. I don't like svn enough to use it for another project. 
Then there's the confusion of mixing qof into gnucash space again.

QOF really doesn't benefit from being constantly linked to gnucash - it gives 
the wrong impression and could easily make others think that QOF has 
gnucash-like dependencies. You and I know different but sometimes those 
impressions matter. (They did with pilot-link and it took several long 
discussions to prove otherwise.)

I think it's better off at SF - Linas must have had his reasons to put it 
there too. (Otherwise qof and gnucash would have been on the same cvs).

True the file replacements take a little preparation (with a SF tracker) but 
they are handled promptly and that's a small price overall.

I know you don't like SF but I'm happy there. Much happier than I fear I would 
be with svn. Sorry. I do appreciate the idea.
:-(

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060111/d5f07fa7/attachment.bin