Should GnuCash use an external QOF library?

[Derek Atkins]

Neil Williams <linux at codehelp.co.uk> writes:

> 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? 

I'm saying that entire trees can be merged.  It's a relatively simple
process to make sure changesets from one tree get merged into the other.
As for control over the process -- how much control do you want/need?

I don't know if it's possible for commits to go on both trees at the
same time without developers making the changes in both trees.

>> 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?

  svn merge tree1 tree2

> 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.

It's extremely unlikely that code changes will require Makefile
changes (at least from the GnuCash side)..  You can choose which
changesets to merge across.

If you're really really really against this option, another option to
inform you is that we could (try) to setup a post-commit process that
emails you personally the changeset diff whenever there's a change to
lib/libqof.  I don't know how easy it would be to do this offhand....

> 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.

What confusion?

> 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).

The reason was that Linas was very short on disk space, and his disk
kept filling up.  He didn't want to use the extra space.  That's the
only reason he moved to SF.

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

Well, if you're willing to pay the price, I'd ask that you not
complain about us making changes in our tree..  At least until after
2.0.  After 2.0 I think we can discuss internal v. external qof.
Before 2.0, I think internal qof needs to be considered a viable
development platform and unfortunately I think you're in the
unenviable position of playing double-duty and patch-master to make
sure our changes get propagated into SF.

> 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.

It's not that I don't like SF per se..  I do have issues with a number
of SF's technical shortcomings..  I don't like how the anon-cvs is
delayed by 24 hours.  I don't like the inability to get to the base
repository.  I don't like how often SF is unreachable or has other
downtime.  I don't like SF's CVS bandwidth limitations.

The fact remains, it's very easy to merge files from two different SVN
trees, so that we don't lose changes.  And yes, losing changes IS a
major concern.  It's happened in the past, and I'm afraid it will
happen again.

Indeed, losing changes is always a problem when trying to keep
multiple trees in sync...  It was a problem during the early 1.8
vs. HEAD days, too -- when do you pull up changes?  A changeset based
SCM (like SVN) can help significantly reduce the chance of lost
changesets....

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available