[mapguide-internals] RFC 111 - Deploy Viewer Code with Subversion Attributes

[Trevor Wekel]

Hmm... To update Fusion, Ant and Svn/TortoiseSVN would need to be installed and run locally.  This gets a little more complicated with Fusion because it is an svn external.  It does not reside in the MapGuide svn vault so the compiled version of Fusion would have to be checked into the Fusion vault.  Installing Ant and Subversion is ok for a developer but I'm not sure if it is a great "patch" solution for the community.

Beefing up the build logic for "developers" and tech savvy community members may get us part way there.  We could track the version and changelog for the various source trees.  Perhaps a separate buildlog file under root and branches/x.x?

http://svn.osgeo.org/mapguide/trunk/buildlog
http://svn.osgeo.org/mapguide/branches/2.2/buildlog

The buildlog file would be updated at the start of every build and would contain the following information:

Last changed rev + svn urls or svn export/checkout command for:

http://svn.osgeo.org/mapguide/trunk/MgDev
http://svn.osgeo.org/mapguide/trunk/Installer
http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev
http://svn.osgeo.org/fusion/trunk

Incremental logs since the last good build for all of the above, eg.:

svn log -r [last good build]:[this build] http://svn.osgeo.org/mapguide/trunk/MgDev
svn log -r [last good build]:[this build] http://svn.osgeo.org/mapguide/trunk/Installer
svn log -r [last good build]:[this build] http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev
svn log -r [last good build]:[this build] http://svn.osgeo.org/fusion/trunk

A lastgoodbuild file in the same directory would contain the contents of buildlog for the last successful build.  It would be written out on successful completion of the (Windows?) build.

The build version for the installers and zip files would correspond to the version of the buildlog file.  That way, we would know exactly what we have rolled into every build.  Individuals with Subversion and Ant already installed could perform the svn checkout and make whatever changes are required.

Would this help?

Regards,
Trevor


-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Tom Fukushima
Sent: March 22, 2011 10:16 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC 111 - Deploy Viewer Code with Subversion Attributes

Hi Zac,

This RFC looks to fix a big problem it seems.  The solution proposed in the RFC looks like a way to provide updates without actually creating an update installer.  What I suggest is that instead of checking the updated files into Subversion, to put them in the download area and then put descriptions of the updates somewhere on the release page that the updates apply to.  I think that it would be easier for people to get things from the download page over trying to figure out and get descriptions from Subversion.

Tom

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Zac Spitzer
Sent: Saturday, March 19, 2011 9:20 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RFC 111 - Deploy Viewer Code with Subversion Attributes

I have written up a new RFC

http://trac.osgeo.org/mapguide/wiki/MapGuideRfc111

please review and comment

z

-- 
Zac Spitzer
Solution Architect / Director
Ennoble Consultancy Australia
http://www.ennoble.com.au
http://zacster.blogspot.com
+61 405 847 168
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals