Commit access for trunk

[Phil Longstaff]

Derek Atkins wrote:
> Hi,
>
> Phil Longstaff <plongstaff at rogers.com> writes:
>
>   
>> Do I have commit access for trunk?   For changes which would make the 
>> gda backend easier (e.g. further work on converting engine objects to be 
>> GObject based), I would prefer to make the change in the trunk and then 
>> merge into the GDA branch.  If I don't have access, may I have it?
>>     
>
> I'm going to give you access in a minute, however I think
> we'd prefer if the gobject work were done on its own branch
> and then that branch merged into trunk.  I can create a
> branch for you or, once I give you access, you can do it
> yourself.  Whichever you prefer.
>
> Thanks!
>   
OK.  There have been a couple of kinds of changes I have wanted or 
needed in the main code:

1) Add const for pointer function parameters
2) Add begin-edit/commit-edit function calls around multiple instances 
where values are set in an object
3) GObject work.  For each db field, the gda backend can get/set values 
either 1) by using a gobject parameter name 2) by getting the 
getter/setter functions registered with qof 3) by using generic 
getter/setter functions.  The order of checking which method to use is 
(1), (2) and then (3) and I am happiest using them in that order.  In 
some cases, only a getter is registered with qof even though the 
parameter can be set.
4) In a dialog which creates a new object, don't create the object until 
the user presses the OK.  What happens now is that the object is created 
when the dialog opens and removed if cancel is pressed or updated if OK 
is pressed.  This is a little clumsy.  It also causes some problems with 
some field definitions where I want to indicate that the value is not 
NULL.  In a scheduled transaction, for example, there needs to be a 
start date, but when it is saved because the sx is created when the New 
SX dialog is opened, the start date is NULL.

Type (1) just provides extra compile-time checking and can go into trunk.
Type (2) reduces the number of times the backend is called to commit 
changes.  It doesn't really affect the XML backend but is not really GDA 
related - can go directly into trunk
Type (4) is also not directly related to gda and could go into trunk.
Type (3) is not related to gda, so I don't want to introduce all of that 
code in the gda backend branch.  As far as I am concerned, it can go 
into trunk or into another branch.  If it goes into another branch, I 
would commit the change there and then merge it into gda, and leave it 
to you to merge what you want into trunk.  I assume the svn merge 
facility can keep track of all of that.

If there is any other way you would like me to handle these kinds of 
cases, just let me know.

Phil