Re: revision strategies [was RE: [Moderator Action] Re: Progress on SVG book]

This may not affect anyone but for those of you on Windows TortiseSVN is 
not compatible with ArcGIS.  It will lockup ArcGIS completely whenever 
you try to open or save a file in the ArcGIS interface.
FYI
Bruce

Helder Magalhães wrote:
> (Sorry for the somehow delayed message but it got stuck somewhere in
> between my SVG-IG join process. I hope that, now that my messages are
> directly accepted, that my participation within the SVG-IG can
> increase.)
>
> Hi David et. al.,
>
>
>   
>> I had not heard of Subversion, and  so read about it a bit on Wikipedia.
>>     
>
> It's fairly easy, even for GUI lovers (like myself, naturally
> depending on the scope), to get started with SVN. On Windows, there's
> the excellent TortoiseSVN [1] which integrates into Windows Explorer
> and makes revision control pretty intuitive. Of course there are also
> other SVN GUI frontends for other operating systems, but I imagine you
> are using Windows (from your statements about MS Word markup
> decontamination). The documentation is great so, even if you are not
> familiar with SVN (SubVersioN), for example in chapter 2 of the TSVN
> (TortoiseSVN) manual there's introductory information about versioning
> control concepts. ;-)  If you want to go deep into SVN, then you may
> consider reading The Book [2] (it's a great example of a collaborative
> effort in the sense we are trying here, by the way). :-)
>
>
>   
>> lists sorta like this:
>>
>> [
>>    1. /original text/revised text/
>>    2. /more text/more new text/
>>    .
>>    .
>>    .
>>    n.  /old stuff/new stuff/
>> ]
>>
>> that way I can find the stuff that needs to be changed.
>>     
>
> With version control you receive a patch and, while merging (applying
> the patch to your local copy), you can have a visual indication on
> what lines are to be changed from it. Pretty neat! :-)
>
>
>   
>> Right now, Shaun Roe has volunteered for an XSLT (/AJAX) section
>>     
>
> I might also give a hand there later. I've made some XML+XSL
> generating XHTML+SVG lately so I might give a hand or two. :-)  I have
> an item in my TODO stack (which keeps increasing no matter how) to
> published something about these experiments but I have no idea when
> will that be done, unfortunately... :-|
>
>
>   
>> Please review that list of topics to see if a) there is a topic or two
>> you might volunteer for or
>> b) if there is a topic missing from the book that really ought to be added to that list.
>>     
>
> Yes, I'll definitely take a look at it and compare with the set of
> high level suggestions I've been harvesting. :-)
>
>
>   
>> As I mentioned in a previous email I've also not put any live SVG in
>> the document, because of not wanting to crash IE which chokes when more than 100 or so separate SVG's are included.
>>     
>
> I'd suggest not doing it even if IE didn't crashes. Having tens or
> hundreds of SVG files being rendered will probably choke most
> implementations or, at least, put the CPU in a high stress level
> (SMIL, filters, etc.) when the user is probably not even looking at
> that particular set of images -- this would give a terrible impression
> about SVG, specially for newbies/starters. Also, using live examples
> may fail to catch a particular state of an SMIL animation, for
> example. So in my opinion best would be either:
>  * Using raster images and placing a link in them to the SVG file used
> to generate them;
>  * Use scripting to replace the image tag to an SVG object whenever
> activated (not focused):
>    * This just occurred to me and I haven't made any experiment yet
> but sounds like it would be neat!
>    * Raster images could have a (HTML) "title" attribute with
> something like "Activate/click to render image" or "Activate/click to
> see original file".
>
>
>   
>> Of course, once the infusion of real SVG into the document were done,
>> then one would want to make all the source listings be auto-generated
>> through JavaScript from the live SVGdocument, and that starts making
>> everything a bit more fragile.
>>     
>
> Yeah, that sounds tricky. Another approach would be inserting the
> source listings though a server-side script -- something like
> (HTML+pseudo-code):
>   <pre>
>     <code>
> 	insert-code-snippet(SOURCE_FILENAME, START_LINE_NUMBER, END_LINE_NUMBER);
>     </code>
>   </pre>
> This would allow inserting code snippets instead of whole files, as
> apparently is already being done. :-)
>
> In the current approach (static text embedded in the HTML as far as I
> was able to see), keeping the source listing and the live examples
> coherent can be a source of trouble but not hard to deal with: someone
> making changes or creating patches will just need to keep in mind that
> the changes need to be done in both places (naturally assuming the
> live SVG examples will be also put into version control).
>
>
> Cheers,
>  Helder
>
>
> [1] http://tortoisesvn.tigris.org/
> [2] http://svnbook.red-bean.com/
>
>
>
>