Register2

Geert Janssens janssens-geert at telenet.be
Thu Oct 24 03:32:18 EDT 2013


Robert,

Yet another option is to use gnucash' --extra switch. This is a runtime command line switch 
that is used to show some additional menu items in a menu called "Extra".

While developing you could move the actions related to Register2 to this menu and every user 
can test them simply by adding --extra to the gnucash command line.

The added advantage is that your code will get compiled each time. This helps prevent bitrot. 
With a configure option your code will only get compiled if a developer explicitly enables the 
option.

Geert

On Wednesday 23 October 2013 14:12:36 Robert Fewell wrote:
> OK, I have worked out how to add a configure option to disable the
> register2 parts, will raise bug with patch later.
> 
> Robert
> 
> On 23 October 2013 11:41, Geert Janssens <janssens-geert at telenet.be> wrote:
> > **
> > 
> > On Tuesday 22 October 2013 12:49:57 John Ralls wrote:
> > > On Oct 22, 2013, at 11:34 AM, Geert Janssens
> > > <janssens-geert at telenet.be>> 
> > wrote:
> > > > I do encourage you to get used to svn/git, and as John proposes,
> > > > 
> > > > clone the gnucash repository on github. I'm not sure what would
> > > > be
> > > > 
> > > > the best starting point for a branch, r23314 (which you would
> > > > 
> > > > revert immediately in your next commit), or r23313, which
> > > > doesn't
> > > > 
> > > > need any reverting. Both will cause some rebasing/merging issues
> > > > 
> > > > eventually. Perhaps John has a better idea.
> > > > 
> > > > 
> > > > 
> > > > In any case, it would be good if you regularly push your
> > > > development
> > > > 
> > > > branch in your github clone so other developers can follow your
> > > > 
> > > > progress.
> > > 
> > > On Oct 22, 2013, at 12:09 PM, Christian Stimming
> > > <christian at cstimming.de>> 
> > wrote:
> > > > Just removing the code will almost surely introduce plenty of
> > > > 
> > > > merging errors the next time any of us or you try to merge
> > > > 
> > > > non-trivial changes from gnucash SVN. Basically, if you remove
> > > > the
> > > > 
> > > > code, it means you are going to maintain a private branch of
> > > > 
> > > > gnucash SVN, not in any git or svn management, but just by
> > > > keeping
> > > > 
> > > > the changed files on your local harddisk. Out of the many
> > > > available
> > > > 
> > > > options of maintaining a separate branch (be it git somewhere or
> > > > 
> > > > svn somewhere or whatever), this one is definitely the worst
> > > > 
> > > > choice. I'd strongly suggest to create a configure switch
> > > > instead,
> > > > 
> > > > and keeping almost all code in SVN as well.
> > > 
> > > Looks like Geert reverted the reversion patch.
> > > 
> > > 
> > > 
> > > I was going to suggest that Robert branch after the reversion
> > > patch
> > > 
> > > and immediately revert it in his branch:
> > > 
> > > git revert 22eff28
> > > 
> > > Then he can rebase from trunk periodically
> > > 
> > > git rebase trunk reg-2-branch
> > > 
> > > to prevent bit-rot on his branch. I do this on my private feature
> > > 
> > > branches, it works quite well.
> > 
> > That approach is fine with me as well, but wouldn't that result in
> > more merge conflicts as time goes by ?
> > 
> > 
> > 
> > Hmm, I'll just stop reverting reversals and let Robert choose what
> > he
> > prefers.
> > 
> > 
> > 
> > Geert



More information about the gnucash-devel mailing list