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

Welcome Helder!  It's great to have you as part of the SVG Interest Group.

I'd like to hold a telcon next week, so could you enter your
availability here:


2009/4/22 Helder Magalh„es <>:
> (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>
> † †</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]
> [2]

Received on Wednesday, 22 April 2009 14:11:03 UTC