Should GnuCash use an external QOF library?

[Neil Williams]

On Thursday 12 January 2006 2:50 pm, Derek Atkins wrote:
> Neil Williams <linux at codehelp.co.uk> writes:
> > Are you saying 
> > that  
> > entire trees can be merged? How much control is there over that process?
>
> I'm saying that entire trees can be merged.

OK, I now understand your idea. I didn't know svn could do that. In 
particular, the merging of just selected changesets.

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

Not to change any Makefile.am, nothing outside lib/libqof/qof/ or 
lib/libqof/backend/file - nothing unexpected I suppose. qofla-dir.h.in isn't 
actually synchronised between the two trees, a differently named variable is 
used in each. (The resulting qofla-dir.h is the same, given the same 
options.) I guess that is fixable.

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

Could you give me a sample command? One using selected changesets?

What if a changeset includes changes outside lib/libqof/ ?

I'm assuming all this is done via the local working copies.

> If you're really really really against this option, 

I'm not, but I don't particularly want to completely drop SF CVS either. I 
guess that's a rod for my own back.

It would be relatively easy to use makepatch to transfer changes between the 
two (SF CVS and gnc svn) because the structure of the two trees could be the 
same - that is my main problem with the gnucash internal qof code. Having it 
in libqof has helped considerably but it's still a double patch sequence.

Let me think on it.

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

That's as easy to do from my end with a little use of filters or grep on 
gnucash-changes. I always read every gnucash-changes email, even if only to 
read the list of changed files. It's just frustrating when a change is made 
just after a libqof release.

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

domain name, repository location. Maybe by retaining SF CVS as active this 
confusion would be minimised. It would be obvious that the svn tree exists to 
enable easier updates. It would almost be like having a development branch of 
QOF CVS.

If Anjuta supported svn I could also grant Chris' request for smaller 
increments in the changes but I can't see that being achievable, certainly 
not before G2. I DO want to retain SF CVS as a "pristine build" to coin a 
phrase from another painful thread on this list.
:-)

i.e. QOF CVS at SF will always, always, build make distcheck successfully.
(as does pilot-qof, since v0.0.5).

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

I try not to complain - I would like just to be involved some more prior to a 
commit.

You have a point about v2 though. 

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

It's inevitable that I carry the can for that. It is easier with lib/libqof 
but it's just part of the reality.

If the merge changeset syntax is as easy as you hint, it may make this process 
easier. However, I have to say that so far I have found svn merge to be a 
VERY difficult command with respect to the cashutil branch. It may be obvious 
to you but I am concerned that this merge tree system with selected 
changesets could be:
a) almost impossible to automate
b) easy to foul up - BADLY.

In contrast to you, I fear that using svn to merge entire trees could actually 
cause more data corruption, not less. This is grounded only in my own lack of 
confidence in svn merge commands. I respect your knowledge of svn but it'll 
be me doing the merges and I'm not at all sure I know enough to do it 
properly.

My biggest problem with the merges to the cashutil branch is just knowing 
which revisions to specify - it seems to be a black art. I've done one merge 
to bring updated gnucash trunk code into the cashutil branch (so that the 
branch had lib/libqof) and it took me ages to work out how to do it. e.g. How 
do I find out which is the starting revision? 

I did about a dozen dry runs and still got it wrong - twice. When I did 
commit, nothing appeared on gnucash-changes. Check for r12243 in 
gnucash-changes, Jan 3rd 2006. Trac seems to carry it (but times out) and it 
certainly committed, but I fouled up somewhere because no email was sent to 
gnucash-changes, only to gnucash-patches:
https://lists.gnucash.org/pipermail/gnucash-patches/2006-January/017345.html

I just don't have time to invest in learning svn like that. I get by but I 
don't think I'll ever be happy in svn.

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

All valid points - they trouble me too, from time to time. The only difference 
is that I'm willing to overlook all those for the other things that SF 
provides. Principally the homepages, tracker, mailing lists, file releases, 
statistics (not the summary, the graphs which are more accurate), 
documentation and just the sheer recognition that SF enjoys. 

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

I do understand. I just don't share your enthusiasm for svn or your confidence 
that it is "very easy" to merge in svn. I've found it v.difficult - probably 
because I'm so used to CVS and only use svn for this one project. 99% of my 
commits are via CVS.

This is my ongoing problem, I am working towards data freedom and constantly 
flitting between various projects to get each one to talk to the others. It 
is why my "focus" is so different (as you once commented) - I'm not looking 
just at one codebase, I'm trying to fill the cracks between six. 

It was a black day for me when one changed from cvs, despite fully 
understanding the reasons.

-- 

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/20060112/56694d8a/attachment.bin