Go to bug ID
Hello, guest. We have noticed that you are not registered at this bug tracker. Your experience will be greatly enhanced if you log in. To do so, you first must register by clicking on the Register tab at the top. If you are already registered, you can login at the Login tab.
Syndicate Syndicate Listing Display Search Login/Register
Bug Id ?
Reporter ?
Ankit Singla
Product/Version ?
Crimson Editor / Version 3.72 (beta, prior to r241)
Status ?
Severity ?
Duplicate Of ?
- none -
Summary ?
SVN revision number needs to be accessible for non-release builds
Report Time ?
August 9, 2007 11:42:15 PM
Assignment ?
Ankit Singla
Resolution ?
Priority ?
Dependencies ?
- none -

For: 0 (0%)
Against: 0 (0%)
Total: 0

August 9, 2007 11:42:15 PM Ankit Singla
Making this high priority so that we can track where bugs are coming from/when they appear/if they should be gone.

I'm thinking a nice workaround is just to install a file called "revision <number>" into the install directory until I can get this in Help>About. I need ideas as to which string to edit and how to edit it for when we actually put it into the build.

Also, I'm happy with only adding this for official builds...i.e. if you use the script to make the exe/zip/tar.gz/etc., then you'll see the correct revision number, but otherwise it's not guaranteed. How do other people feel about this?

August 10, 2007 01:44:10 AM Ankit Singla
Well, I took care of that workaround I mentioned. It was rather simple. I'm lowering the priority on this now and will work on getting it in the About dialog later...if people still want it. If we feel this is good enough, we can write a short if statement in the batch file to only create the file if this is not a release, probably by using some sort of environment variable or checking to see if we're in tags or trunk or something, and tell NSIS to install it only if it exists. I can't imagine this would be so hard.

August 10, 2007 08:59:30 AM Pvt_Ryan
Actually the svn rev would be usefull for both releases and pre-releases.

The text file in the install dir is what i was going for anyway, although i may modify your script later to intergrate it with my updater..

I was thinking that the releases should follow the standard: 3.70,3.72, but we could append a 3rd number to that which would be the svn repo verison it was built against. so if i build against rev 186 we get 3.72.186. This would provide us with all the information required for regression testing and bug reporting.

August 10, 2007 01:14:46 PM Ankit Singla
I don't think we should add that third number. Although if we only add it for releases (tagged versions), it wouldn't be too bad to implement. I think having the file, though, will be good enough. It's zero bytes after all ;)

August 10, 2007 02:15:20 PM Pvt_Ryan
yes, but it can be accidently deleted by the user.

August 10, 2007 02:54:19 PM Ankit Singla
I figure if the user is messing around with that directory, they probably know what it's for anyway. Most users don't go around deleting things in C:\\Program Files\\*. Were you planning on only adding the third number for releases? If so, that's fine, because then we can manually edit the string without a problem, but otherwise, it would be frustrating to have to do it.

August 10, 2007 05:28:46 PM Pvt_Ryan
I was considering it for the release where i intergrate my updater and CE. as then i could just check the for the version define and see what it says the current version is.

Also i am using a xml file for the updater cfg. so i will likely change your changes to get it to update that file instead.

September 16, 2007 10:26:03 PM Pvt_Ryan
closing this as we have a viable workaround for now and i have implemted a version system for full builds / release candidates.