syncing two pcs

[hendrik at topoi.pooq.com]

On Sat, Aug 16, 2008 at 11:19:52AM -0400, Robert Heller wrote:
> At Sat, 16 Aug 2008 10:01:41 -0400 hendrik at topoi.pooq.com wrote:
> 
> > 
> > On Sat, Aug 16, 2008 at 08:09:01AM -0400, Mike or Penny Novack wrote:
> > > 
> > > >On July 6, 2008 09:37:45 pm Paul wrote:
> > > >  
> > > >
> > > >>Does anyone know if/how gnucash can be run on two pcs and sync them
> > > >>together?  I have duplicated both pc's file structures for the
> > > >>application but only one actually contains data.  Any help would be
> > > >>appreciated.
> > > >>
> > > >>    
> > > >>
> > > >
> > > >I just use rsync on both machines, and copy the file from the office machine 
> > > >to the laptop if it's the last one I updated. If I updated the laptop last, I 
> > > >just rsync in the opposite direction, and copy files from the laptop to the 
> > > >office machine. No muss, no fuss. Available on pretty much any distro.
> > > >
> > > >  
> > > >
> > > I'm not sure how what I am about to say will be taken.
> > > 
> > > If the data (the files) are on both machines and you depend upon 
> > > synching them by .......
> > > 1) After using the application on machine A copying the data to portable 
> > > media like a USB drive.
> > > 2) Before using the application on machine B "synching" the data from 
> > > the USB drive to machine B
> > > SOONER OR LATER you will forget and be screwed.
> > > 
> > > Far safer to have just ONE copy of the books (not counting backup copies 
> > > of course) left on the USB drive and then neither machine can alter the 
> > > data unless the USB drive is mounted to that machine -- if you forgot to 
> > > mount the UBS drive you'd get a "not found" looking for the files (the 
> > > directory in which they lived wouldn't appear in the "open" menu.
> > > 
> > > That I have this point of view is because that's the sort of problem 
> > > that used to come to my desk -- when somebody forgot and now an ad hoc 
> > > program had to be written to somehow merge the data (in my work context, 
> > > would be tens of thousands of transactions so one hell of a job to get 
> > > the data merged "by hand"). Best not to have a "system" dependent on 
> > > somebody never forgetting a vital step.
> > 
> > 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.
> 
> Wouldn't the XML file work for this?  Right now, gnucash's file is just
> a compress XML file.  If it was uncompressed, it would be a text/xml
> file, which most (all?) revision cotrol systems can handle just fine.

Except that they usually operate by keeping track of the insertion and 
deletin of lines, which does not guarantee to maintain the syntactic 
integrity of the XML.  For source code, maintained and edited in text 
form, this is OK, because the source code is the form in which the 
programmer normally sees it, and malmerge can be understood at that 
level.

For gnucash, it's not as simple, unless the user likes editing XML.

The merge has to guarantee the syntactic integrity of the file.  And 
when merges don't work (because of unfortunate sumiltaneous changes to 
one transaction of account, or whatever, gnucash will have to present 
this in a way that the user can resolve.

-- hendrik

> 
> > 
> > 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.
> > 
> > Most revision control systems maintain multiple working copies of the 
> > up-to-date versions, and save space by storing the rest as deltas.
> > It is usually these deltas that are used to compute the changes made 
> > since the base version, so that the sets of changes can be merged.  In 
> > the available revision control systems, the deltas are usually 
> > insertions and deletions of lines in the file, with mistakes repaired by 
> > hand.  Gnucash files are not particularly line-structured; that's 
> > why I said above that it would probably need a special-purpose sync 
> > tool.
> > 
> > What would have to happen to gnucash to make this work easily:
> > 
> > Every transaction and account would have to have a unique ID that can be 
> > used to determine which transactions in the several versions are the 
> > same.  If a transaction is changed, its unique ID stays the same.  This 
> > makes it easy to identify changes to a transaction.
> 
> I don't know about transactions, but I am pretty sure gnucash already
> has unique IDs for accounts and other major 'objects'. control systems,
> the deltas are usually

Accounts, yes.  I'm not so sure about transactions.

> 
> > 
> > There are probably other entities that will have to be identified by 
> > such unique IDs.
> > 
> > When edits conflict, the entities will have to be marked some way for 
> > manual resolution.  This manual resolution will have to be integrated 
> > with the normal gnucash user interface.
> 
> 
> 
> > 
> > -- hendrik
> > _______________________________________________
> > gnucash-user mailing list
> > gnucash-user at gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > -----
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
> > 
> >                                            
> 
> -- 
> Robert Heller             -- Get the Deepwoods Software FireFox Toolbar!
> Deepwoods Software        -- Linux Installation and Administration
> http://www.deepsoft.com/  -- Web Hosting, with CGI and Database
> heller at deepsoft.com       -- Contract Programming: C/C++, Tcl/Tk
>