[Live-demo] Re: Dropbox on GISVM for script sharing

[Ricardo Pinho]

Hi Hamish,

> I have no problem with adding a dropbox per se, it's a fine idea.
> But for the script development specifically, IMO the most sane approach
> it to keep it in a single dedicated place.
> ...
> I would suggest to keep a single SVN repository (either hosted at OSGeo

Sorry if somehow I suggested to use Dropbox for development. I was only thinking on  sharing!
I''m not a developer so I really don't have much practice with SVN.
But obviously SVN is better than dropbox for development and we should keep using it!

My point here is to keep a syncronized copy of the scripts inside GISVM.
You propose:

> Keep an up to date copy on the GISVM side with
>  svn checkout https://svn.osgeo.org/osgeo/livedvd/gisvm/trunk/ osgeo_scripts
>
> then keep it in sync with
>  cd osgeo_scripts
>  svn up

Well, try to explain this to a MAC user! ;-)
Dropbox, like the name says, is a GUI sync tool, much more easy and user friendly than svn command!
It also makes a centralized copy of files very well!

Your proposal is also interesting if you make it transparent for the user.
Run it in background = daemon, or put a button on desktop to Sync!

But, in my opinion, it has less potential then Dropbox, in the user point of view!


Also, my opinion is that  scripts should only be syncronized inside GISVM after testing, etc (stable release).
So whenever a stable release  is created on SVN, it should be copied to dropbox (= GISVM).

And  other guys and vendors could also create their scripts folders and associate them with gisvm-dropbox account. 
Of course they should be responsible for maintenance of files in that folder...

The other aspect of having Dropbox installed, is that you can use it for other purposes, shuch like using GISVM with groups! (such as classrooms)
In those situations, teachers could make use of their own Dropbox account so that students could associate it to their GISVM computers.
This way all data/etc is sync between students !

> made my point yet? :)

Hope so. My apologies if I'm getting it all wrong!


Cheers,
Ricardo Pinho


----- Mensagem original ----
De: Hamish <hamish_b at yahoo.com>
Para: "live-demo at lists.osgeo.org" <live-demo at lists.osgeo.org>; Ricardo Pinho <rpinho_eng at yahoo.com.br>
Enviadas: Quarta-feira, 2 de Setembro de 2009 8:34:38
Assunto: Re: Dropbox on GISVM for script sharing

Ricardo wrote:
> I really think that we should implement a synchronized
> folder inside GISVM so that we could easily share and update
> the install scripts we are making.
> 
> The idea is to use the multi-platform engine: Dropbox.
> http://www.getdropbox.com/

I have no problem with adding a dropbox per se, it's a fine idea.
But for the script development specifically, IMO the most sane approach
it to keep it in a single dedicated place.

The whole point of SVN is to handle distributed source code management
without it becoming fragmented and out of sync. Also the revision control
and logs it gives are really really important when you are trying to
untangle some bug at some point in the future when short term memory
has faded. (everyone is supplying useful commit comments, yes? :)

I would suggest to keep a single SVN repository (either hosted at OSGeo
or at GISVM's server, I don't really care as long as we don't dilute
focus*) and make sure that everyone has write access to it. Public access
from the internet with no accountability log is a no-go. Simply too many
moronic vandals out there to deal with. All anyone has to do to get write
access on the OSGeo livedvd SVN is create yourself an OSGeo ID and let us
know what it is, it's very easy to add people.

[*] this is the "divide" part of "divide and conquer", it's a trap.


Keep an up to date copy on the GISVM side with
  svn checkout https://svn.osgeo.org/osgeo/livedvd/gisvm/trunk/ osgeo_scripts

then keep it in sync with
  cd osgeo_scripts
  svn up

If you wish to develop some here, develop some there, then merge the two
later, there are other SCM systems such as Mercurial and Git which are
very good at that. Subversion is geared to the single central host +
multiple local development copies model.

SCM is a wonderful wonderful thing and is well worth the learning curve.
We should not abandon or nullify its best features. The payoff is huge,
the pitfalls of not using it are many. made my point yet? :)


cheers,
Hamish


      ____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com