Show SVG Web Release Name and Revision in Right Click Menu

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Go to the demo page [1];
2. Right click on the SVG Web Flash canvas.

What is the expected output? What do you see instead?
I see an "About SVG Web" item in the context menu. I'd expect something
like "About SVG Web v.%VERSION% (r.%REVISION%)" or something equivalent
(for example, a modal dialog showing that information) in order to help
reporting bugs.

What version of the product are you using? On what operating system,
browser, and version of Flash?
Version in not applicable in this context! ;-)  I'm on Windows XP SP3,
using Flash 10.

Please provide any additional information below. Reduced test cases are
always appreciated!
The only way to retrieve the SVG Web version for a given deployment is to
find out where the "svg.js" library is located (by crawling through the
document), which is an unfeasible process -- specially for less advanced users.

I was somehow surprised this wasn't noticed before (is it by design?), as
I've crawled though the issue tracker and found nothing related.

[1] http://codinginparadise.org/projects/svgweb/samples/demo.html

Original issue reported on code.google.com by helder.magalhaes on 20 Oct 2009 at 11:08

[GoogleCodeExporter]

Update: I've noticed that, due to minification, the possible workaround of 
trying to
crawl for the version by opening the "svg.js" or "svg.htc" isn't viable... :-(

I'm not sure if this should be considered an enhancement, despite of my feeling 
of
"oh oh, now how am I supposed to guess the version?". ;-)

Original comment by helder.magalhaes on 20 Oct 2009 at 11:28

[GoogleCodeExporter]

Original comment by bradneub...@gmail.com on 20 Oct 2009 at 7:10

• Changed title: Show SVG Web Release Name and Revision in Right Click Menu

[GoogleCodeExporter]

I'm happy to implement this one so feel free to assign it to me if its not 
taken.

Original comment by jonfrost...@gmail.com on 21 Oct 2009 at 1:56

[GoogleCodeExporter]

I played around with Subversion and keywords recently (but it didn't work out 
for me
and svg-edit because we use googlecode to host that and it's not a checked-out 
copy.

I think it's as simple as:

$ svn propset svn:keywords "Revision" whatever_file

and then add $Rev$ to whatever file.  Subversion will automatically add the 
revision
number to the file when you check it out.

Original comment by codedr...@gmail.com on 21 Oct 2009 at 2:20

[GoogleCodeExporter]

Hi Jon, go ahead a grab this one. Sounds like Jeff's suggestion is a good one.

Original comment by bradneub...@gmail.com on 21 Oct 2009 at 6:58

[GoogleCodeExporter]

Yeah, the $Rev$ trick sounds like a good idea: it will be expanded to something 
like
"$Rev. NNN $" which, not being ideal, will work at least for now. The 
recommended
procedure would be using a command-line tool such as SubWCRev [1], in order to 
avoid
the "$Rev. $" stuff, but this can be made later (if at all!).

As stated the release name would also be useful, but the only way currently 
occurring
to me is by tweaking the string in each release.

[1] http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev.html

Original comment by helder.magalhaes on 21 Oct 2009 at 9:34

[GoogleCodeExporter]

(Reply to self, basically.)

Of course the "$Rev. NNN $" can be tweaked in run-time by using a regular 
expression
to extract the revision number only!... :-)

Original comment by helder.magalhaes on 21 Oct 2009 at 9:43

[GoogleCodeExporter]

In reply to comment 6:

Actually, if SVG Web was tagged/branched (at SVN level) before each release 
final
build, using a meaningful name for the tag name, then the "HeadURL" SVN keyword 
[1]
could also be used to achieve an effect similar to what was proposed (in 
comment 5)
for the revision number: using a regular expression to strip only the 
interesting
information from the URL, trunk build would appear like "trunk" (or replaced to
"Development version", "pre-release", etc.) and tags/branches would be 
displayed like
"Beholder", "UmberHulk", etc. (assuming those as tag/branch names). :-)

[1] http://svnbook.red-bean.com/en/1.5/svn.advanced.props.special.keywords.html

Original comment by helder.magalhaes on 22 Oct 2009 at 3:27

[GoogleCodeExporter]

Agreed - release names would be cool too, but even then people could be using
slightly different revisions on their own website, so ultimately it seems like 
the
rev number is the ultimate indicator of what 'snapshot' the author used.

Original comment by codedr...@gmail.com on 22 Oct 2009 at 5:04

[GoogleCodeExporter]

Jon, thanks for the patch! I've reviewed it and unfortunately the SVN 'rev' 
keyword
won't work for us. It only records the last revision number for a specific 
file, not
the last update across the entire SVN repository so we can't use it.

Are you interested in taking another shot at this? Here's what I suggest. The
svnversion command _can_ give you the revision number for the head of SVN:

http://svnbook.red-bean.com/en/1.5/svn.ref.svnversion.re.html

Modify SVGViewer.as to have two variables, releaseName and releaseNumber, that 
you
set using tokens, such as:

var releaseName:String = "%SVG_WEB_RELEASE_NAME%";

Modify the Makefile to change these to the latest release number using some Bash
shell scripting and svnversion. For the release name, be able to pass in the 
flag
RELEASE_NAME set to the release name, such as Beholder. If it is not set 
default to
"Tip-Of-Subversion" for the release name.

Change the 'all' make target to do this on each go. 

Extra credit would be to change the target that creates the release archive to
incorporate this info.

Are you interested in doing this? Its a good starter project.

Original comment by bradneub...@gmail.com on 13 Nov 2009 at 3:10

[GoogleCodeExporter]

I just updated the SVGViewer.as file and wrote this bash/sed script to quickly 
replace the RELEASE_NAME And _NUMBER from the file:
$ sed 's/%SVG_WEB_RELEASE_NAME%/Beholder/g' SVGViewer.as > SVGViewer.as
$ sed 's/%SVG_WEB_RELEASE_NUMBER%/989/g' SVGViewer.as > SVGViewer.as

However, seeing as I am building using the MinGW and MSys in Windows 7, and 
also 
using Tortoise SVN, it looks like I need a slightly different Makefile than you 
are 
needing.  Instead of SVNVersion, Tortoise SVN would use the SubWCrev tool -
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev.html

I'll wait for your input on this, but I think its best if you finish off the 
Makefile changes for check-in.  Do keep in mind that at least a couple of the 
developers may not have access to SVNVersion.  Best.

Original comment by jonfrost...@gmail.com on 17 Nov 2009 at 12:35

Attachments:

• SVGViewer.as

[GoogleCodeExporter]

Perhaps you can test for the existence using 'which svnversion'; if that's not
present, you could then tests for existence of SubWCrev; if neither are present 
print
out a message to get either and then quit? Does SubWCrev run from the 
command-line
and provide similar results?

I'm surprised that the Makefile runs on Cygwin at all actually; hadn't tested 
in that
environment.

Original comment by bradneub...@gmail.com on 17 Nov 2009 at 12:39

[GoogleCodeExporter]

Good idea.  Yes, SubWCrev is command-line and returns similar results, so this 
should 
work.

Last week I decided to install LinuxMint to refresh my Linux skills - I hosted 
a 
bunch of websites on Linux back in the late 90s, but since then have only used 
it for 
security testing.  I'll get svnversion running so I can test both environments.

BTW, I didn't have to install Cygwin for this.  MinGW is its own little port of 
Linux 
for Windows:  http://en.wikipedia.org/wiki/MinGW#Comparison_with_Cygwin

Original comment by mmquino...@gmail.com on 17 Nov 2009 at 1:21

[GoogleCodeExporter]

Ah, I see that someone had not logged out of gmail on the bio-lab's computer - 
of 
course that last post was mine.

Original comment by jonfrost...@gmail.com on 17 Nov 2009 at 3:20

[GoogleCodeExporter]

This is the updated SVGViewer.as file and Makefile that is working for the 
MinGW 
environment in Windows.  Its not quite where we want it yet as I haven't had a 
chance to configure LinuxMint yet.  

Feel free to modify/improve or just send suggestions and I'll see what I can do 
before Turkey Week arrives.

Original comment by jonfrost...@gmail.com on 18 Nov 2009 at 6:03

Attachments:

• SVGViewer.as
• TemplateReleaseNumberSubWCrev.txt
• Makefile

[GoogleCodeExporter]

I have linuxMint installed with svn and svnversion running.  I have the latest 
svgweb
source here in linux and I'm enjoying this OS.

I chatted with one of the other developers, Rindhal, a while back and he was 
using
MinGW on Windows, but if Rindhal is not active and you guys are all using Linux 
then
we may not need to bother with the SubWCrev command after all :-)

Original comment by jonfrost...@gmail.com on 19 Nov 2009 at 3:25

[GoogleCodeExporter]

I'm not sure what Rick is using actually; I use Mac OS X Leopard.

Original comment by bradneub...@gmail.com on 19 Nov 2009 at 5:19

[GoogleCodeExporter]

Original comment by bradneub...@gmail.com on 19 Nov 2009 at 9:47

• Added labels: Patch

[GoogleCodeExporter]

I have the svnversion logic working now using variables.  The key was to use 
double-
qoutes so that the variables would expend out w/in the sed string.  Just doing 
a 
little more testing.

The RELEASE_NAME defaults to "Tip-Of-Subversion" but can be passed in.  
Currently 
the makefile will use svnversion by default, but can be over-ridden using 
arguments.

Currently once the RELEASE_NAME and _NUMBER are set, they won't be updated 
until the 
SVGViewer.as file is retrieved from the repository.  So another feature we may 
want 
is the ability to keep the RELEASE_NUMBER up-to-date w/ each any file check-in 
without having to get the latest SVGViewer.as file from source (which would 
reset 
the tokens %SVG_WEB_RELEASE_NAME%).  If that's desired, just let me know - 
should be 
trivial to implement using placeholder variables.

Original comment by jonfrost...@gmail.com on 19 Nov 2009 at 10:39

[GoogleCodeExporter]

I've been traveling and am looking at a busy schedule for the next 3 weeks.  I 
was 
hoping to get to this tomorrow but was just asked to help at one of the places 
I 
volunteer at.

Hope you can finish off what I have so far, but if not I plan to wrap this up 
as 
soon as possible.  Best.

Original comment by jonfrost...@gmail.com on 21 Dec 2009 at 6:15

[GoogleCodeExporter]

Thanks Jon!

Original comment by bradneub...@gmail.com on 21 Dec 2009 at 10:58

[GoogleCodeExporter]

Original comment by bradneub...@gmail.com on 9 Apr 2010 at 2:27

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I wanted to make a clean build of the project using the Makefile (up to this 
point I'd just been compiling the swf via my IDE) so I could get JS 
compression, etc.  I found that the Makefile didnt support cygwin's windows 
path delimiter.  I changed the Makefile to detect cygwin using a uname and then 
set the appropriate path delimiter.  I then wanted to get the current SVN 
repository rev into the context menu.  I decided to implement it using compiler 
constants.  RELEASE_NAME and RELEASE_NUMBER can be passed in to make.  If they 
arent, then by default RELEASE_NAME is empty and RELEASE_NUMBER is the result 
of running svnversion.  The context menu will show either "RELEASE_NAME 
rRELEASE_NUMBER" or "rRELEASE_NUMBER" or "rSVN Rev keyword replacement" 
depending on whether both RELEASE_NAME and RELEASE_NUMBER are not empty, or 
just the RELEASE_NUMBER is not empty, or both are empty.

If you are using an IDE to compile things, you will need to add
BUILD::releaseNumber
and 
BUILD::releaseName
to your compiler constants configuration.

I've attached a svn diff which implements all these changes.

Original comment by bduncan%...@gtempaccount.com on 13 Jun 2010 at 7:06

Attachments:

• releaseNameNumber-fix.diff

[GoogleCodeExporter]

Fixed in r1183.
Thanks to Bruce Duncan for the patch.

Original comment by grick23@gmail.com on 14 Jun 2010 at 12:09

• Changed state: Fixed