syncing two pcs

[hendrik at topoi.pooq.com]

On Sat, Aug 16, 2008 at 11:28:47AM -0400, Mike or Penny Novack wrote:
> 
> >
> >This makes it plain that the gnucash database needs to be in a file 
> >format that can reliably be processed by a revision cotrol system, 
> >preferably a distributed one, probably a special-purpose one.
> >
> >All reliable miltoway sync operations need to have, in addition to the 
> >two files to be merged, a previous version that was the ancestor to 
> >both.  This means either multiple copies of the gnucash database, or 
> >having the database itself contain its history.
> >
> > 
> >
> .........
> This refers to a very different sort of issue --- not keeping sequential 
> use of the database in synch but synching concurrent use changes.
> 
> Not nearly as simple a matter as you describe.

I never said it was simple.

> There is nothing to 
> prevent concurrent users from making incompatible changes (that cannot 
> be synched by some sort of "version control" -- by which I don't mean 
> that a version control process can't come up with a "solution" but that 
> this might not be what EITHER updater of the database intended).

That's why incompatible changes will have to be resolved by hand.

> 
> If you are going to have an application that allows concurrent changes 
> to a database then you need a full blown "database manager". That allows 
> all users to read the database but only one at a time to update it. 
> During the moment of the update operation all other users "locked out" 
> until the operation completes, after which all users "see" the change 
> made and so cannot accidentally make a chanage incosistent with that -- 
> obviously the second could intentionally undue/upset the other's change

There does need th be a mechanism for resolving incompatible changes.

> 
> The issues around the logic of "concurrent processing" are really too 
> complex for a "user" discussion group. Leave this to "pros". In any 
> case, when the accounting chores become too onerous for one bookkeeper, 
> what's normal is to segment the work assignenments (so different 
> bookkeepers aren't handling the same sorts of transactions, only some of 
> them authorized to make changes affecting the chart of accounts, etc.). 
> In other words, the problems to which I am alluding would be partially 
> handled by "work flow" rules preventing inconsistent changes, etc.

The model I have in mind is ordinary domestic household accounts.  
There's a gnucash database on the home computer, and another on my, and 
my wife's handhels computers.  We enter everything on our handhelds as 
it occurs, and sync when we're home.

It is not feasible to suggest that all transactions be entered 
instantly by a direct net connections to a central server.

Having the database replicated also provides automatic backup.  It 
provided the advantages, and disadvantages, of a distributed revisioning 
system.  But by having it specialized to the application, I think the 
disadvantages can be minimized.

It seems that true conflicts will be rare, and easily resolved by hand.

a 'diff3' that respects XML syntax, and signals merge conflicts in the 
XML file in such a way that gnucash could present them for resolution 
(that will require gnucach to be aware of this) would probably suffice 
for many things.

I'm not saying this will be easy, or that users can be unaware of 
the mechanism.  Or that it's worth implementing this system for just 
gnucash.  The effort of implementing such a thing would clearly justify 
generalising it to make it work for other applications.

-- hendrik