W3C home > Mailing lists > Public > public-svg-ig@w3.org > April to June 2009

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

From: Bruce Rindahl <rindahl@lrcwe.com>
Date: Wed, 22 Apr 2009 09:04:49 -0600
Message-ID: <49EF3211.8040203@lrcwe.com>
To: Helder Magalh„es <helder.magalhaes@gmail.com>
CC: public-svg-ig@w3.org
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/
>
>
>
>   
Received on Wednesday, 22 April 2009 15:05:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:28:24 UTC