[Gnucash-changes] r13272 - gnucash/branches/cashutil - Halting the cashutil branch until further notice - development continues outside svn

[Neil Williams]

On Wednesday 15 February 2006 11:26 pm, you wrote:
> If you're going to kill it, kill it.  Don't "move" development outside of
> the SVN tree..  That does nobody any good.

Sorry, I simply cannot continue with the gnucash branch - I have said that 
off-list. The code is not in a maintanable state due to problems with svn 
merge, the builds take far too long because of the extra GUI code and keeping 
the branch updated with trunk changes has proved to be simply not worth the 
effort. 'svn merge' is nowhere near as easy as is frequently claimed. The 
basic problem of having separate translations for cashutil and gnucash has 
not gone away - in fact it has added to the complexity of the branch.

No-one here probably believes me, but IMHO it's actually easier to use CVS, 
makepatch and manifest files rather than svn merge. Why? Because I don't have 
to keep track of arbitrary numbers that are outside my control. r numbers may 
be the bees knees to others here but I just wish that trunk/ had separate r 
numbers for a branch and that different trees had their own r sequence, not a 
single sequential number for the entire repository. It perturbs me each time 
a commit to htdocs increments the revision number for trunk. Completely 
bizarre in my book. We'll have r numbers in the tens of millions by the time 
we get to gnucash3. With CVS and makepatch, I can script the entire process 
and just get on with viewing the changes, before applying the entire patch in 
a single operation.

As I'm the one doing the updates, I choose to step away from a system that 
simply does not work for me. It can only be good for development of the 
cashutil project.

> it should either be dead dead, or it should continue in SVN.

The only way cashutil can continue in gnucash svn is what I mentioned off-list 
- changing the branch into a tree. I understand why you don't like that 
option. I'm happy with that, I knew it was a longshot and that it has 
significant problems of it's own.

I'm not killing cashutil, cashutil continues. What has to die is a development 
method that simply failed to work - cashutil in a gnucash svn branch.

I tried it, I messed it up trying to get it to do what I wanted. There is more 
to free software development than an svn branch - it didn't work out for me, 
sorry, time to move on to a model that does work for me. It wasted several 
months and it's time to give up the branch as lost. No-one else appears 
likely to work on cashutil so it's up to me. GnuCash changed to svn to suit 
the development needs of the developers; cashutil is changing away from svn 
to suit the development needs of it's sole developer. Hey-ho, around we go. 
It's a no-op really.

Anyway, free software never dies - it just reaches a pause in development. 
There's nothing wrong with cashutil that a separate development tree can't 
fix. What IS wrong is the idea that it can be built as part of a gnucash 
branch. That idea, sadly, is dead. The project remains.

I've already got a new version of cashutil in the wings, updated to use 
gnucash 1.9.0 code. CashUtil is very much alive and is likely to go to 
SourceForge CVS in due course.

If anyone comes up with a solution for building multiple packages from a 
single tarball with separate translations (and dependencies) for each, then 
I'll look at it again AFTER G2 is released.

Until then, cashutil will revert to the development method prior to the svn 
branch creation and move to SF once a usable release is ready.

I see no reason to kill the project, I see no future in the svn branch. 
Something has to give.

-- 

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/20060215/d9322b50/attachment.bin