[Live-demo] Chat logs re collaborative development of GISVM

[Hamish]

Cameron wrote:
> * Ricardo is to send Stefan/LISAsoft a version of his
> latest GISVM desktop so that Stefan can help him with it.

nice

> * We are looking to set up a public GISVM server, which
> developers can rsync to their local GISVM. (We still need to
> confirm that this is feasible)

rsync is fine, I believe it handles sending just the chucks of a binary
file which have changed, and so a good fit for this task. (although
I've never tried it with something of this magnitude)

There is venerable sync/backup software based on rsync called "unison"
which you may wish to check out.
  http://www.cis.upenn.edu/~bcpierce/unison/

for two-way collaboration you will want to set up the rsyncd server
based on a ssh account, it would be unwise to allow random 3rd parties
on the internet to make what are essentially unlogged changes to the
image on the primary server.

.... which is really the downside of the rsync approach, there is no
automated change log, you either have to maintain the discipline to
keep a manual one in a HISTORY.txt file (hrumph) or just be bloody sure
to keep in daily IRC contact with each other as you go.

Tracking the change history is where Subversion really shines, but it
is primarily designed for merging text files, e.g. build scripts or
manifests. So it's a perfect fit for the live-helper approach to building
a liveCD*, could be plausible for a geodata repository, but it is
really no good for tracking changes within a single massive binary ISO
blob.

FWIW, OSGeo SVN space for the live-demo project is already operational
if it may be of any help.


I do not think it matters how rsync handles symlinks or not, as all it
will see is the binary .iso (or virtual image) file. All the filesystem
will be internal to that. Indeed, a .iso is in fact a complete ISO9660
filesystem bundled into one file.


go! go! go!

Hamish


[*] I'm trying hard to keep my mouth shut about the live-helper approach
to this until after the current FOSS4G 2009 project is out the door, but
I am more and more convinced that in the long run it's the best, perhaps
only, way to go. The overheads of investing approx a person-week of
labour to the disc every 6 months to keep it current is just far too high.