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

Tom Fukushima tom.fukushima at autodesk.com
Thu Mar 24 16:41:33 EDT 2011


Yeah, that sounds like the right way to hack Fusion.

Like Jason, I'm not thrilled about (but not totally against) in-place builds, but I'm not sure how to get a better solution.

Tom

-----Original Message-----
From: Zac Spitzer [mailto:zac.spitzer at gmail.com] 
Sent: Wednesday, March 23, 2011 11:56 PM
To: MapGuide Internals Mail List
Cc: Tom Fukushima
Subject: Re: [mapguide-internals] RFC 111 - Deploy Viewer Code with Subversion Attributes

when hacking on fusion, like with openlayers, you can simply switch to using the lib/fusion.js instead of the lib/fusion-SF.js file

once the hacking is complete, by having a svn working copy, you can simply generate a patch and then get your hands dirty with a fusion build

gettting started with hacking becomes easier because you can always revert or diff

ideally, to make hacking easier(tm), we could modify the fusion build process to do an in place build, instead of outputting it all to a new directory

z

On Thu, Mar 24, 2011 at 3:39 PM, Tom Fukushima <tom.fukushima at autodesk.com> wrote:
> I'm not sure what that would be called (svn working copy, svn attributes, etc.), but I think I understand now.
>
> For the AJAX viewer the proposal sounds like it will work well, and it will allow people to hack.
>
> I don't think that we should check the compiled Fusion files into the repository because that goes against the promote-hacking goal. For those who just want to take a fix but not hack, it will be a little more complicated, because they will need to "svn update" and then build (but this is not hard is it?). For those who find the svn update and build too complicated, I suggest providing downloads.
>
> Cheers
> 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: Wednesday, March 23, 2011 10:09 PM
> To: MapGuide Internals Mail List
> Subject: Re: [mapguide-internals] RFC 111 - Deploy Viewer Code with 
> Subversion Attributes
>
> Hi Tom,
>
> the intention is that when you install mapguide, the web viewers, (AJAX & Fusion) are installed with the .svn folders, as if you had done a svn checkout.
>
> I realise now that the svn attributes is the wrong term, svn working copy?
>
> z
>
> On Thu, Mar 24, 2011 at 2:49 PM, Tom Fukushima <tom.fukushima at autodesk.com> wrote:
>> OK, I don't understand what this RFC is for.  What is "subversion attributes"?
>>
>> 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: Wednesday, March 23, 2011 7:05 PM
>> To: MapGuide Internals Mail List
>> Subject: Re: [mapguide-internals] RFC 111 - Deploy Viewer Code with 
>> Subversion Attributes
>>
>> Tom,
>>
>> As any updates need to be checked into subversion anyway, putting them in the download area just complicates and all the steps your describing can be achieved with svn status & updates.
>>
>> Subversion might be for developers, but you need to be a bit technical to use mapguide anyway and I dare say, installing subversion and doing a svn update is a still a lot easier than manually copying and modifying individual files.
>>
>> Encouraging best practises like source control for our users is a good thing.
>>
>> For the AJAX viewer, all that is required to support this is removing the step which strips the .svn directories out of the build dir before the installer is bundled up.
>>
>> Fusion is more complex, but from discussions with Jackie, the build process for fusion mostly involves generating two javascript combined files and copying the mapguide templates into the fusion directory.
>>
>> How about moving the mapguide templates over into the fusion tree and including the combined files in subversion?
>>
>> Build logs sound good
>>
>> z
>>
>>
>>
>>
>>
>> On Wed, Mar 23, 2011 at 4:14 AM, Trevor Wekel <trevor_wekel at otxsystems.com> wrote:
>>> 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
>>>
>>>
>>> _______________________________________________
>>> mapguide-internals mailing list
>>> mapguide-internals at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>
>>>
>>
>>
>>
>> --
>> 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
>>
>
>
>
> --
> 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
>



--
Zac Spitzer
Solution Architect / Director
Ennoble Consultancy Australia
http://www.ennoble.com.au
http://zacster.blogspot.com
+61 405 847 168


More information about the mapguide-internals mailing list