commited... try ::bugs::get_svn_revision using sxml, not xml2list, so it's the most secure method used.Also, try I re-enabled the sxml messages.. but set the default setting to silent.
If we want to have the debug, we put the silent back to 0, or do a ::sxml::set_attr $id silent 0 you can also use ::sxml::set_attr $id trace 3
(or just change it in the file, if you're testing something)by the way, I added output on start/end of parsing of any xml file... look at the attached log, how does it look ? you see the time it took to parse plugins.xml... a minute!! that's ONE of the reasons amsn takes time to load, it takes one huge minute on parsing one xml file... then it probably takes time for the skin to get loaded... also, everything is done twice.. settings.xml is parsed twice for example, but it doesn't take much time.. but everything is done twice, even plugins.xml is parsed twice.. only, the second time it's parsed, it takes 0 seconds to proceed... maybe because the info it received was already added to some variables... so maybe the parsing isn't long, it's the proc called, the processing we do... but we only load key/value pairs in an array, right...
this should maybe looked at.. KKRTOn Mon, 29 May 2006 22:45:30 -0400, Youness Alaoui <[EMAIL PROTECTED]> wrote:
On Mon, 29 May 2006 22:33:17 -0400, Karol Krizka <[EMAIL PROTECTED]> wrote:On Mon, 2006-29-05 at 15:39 -0400, Youness Alaoui wrote:Yes, but the file is not read... you should read the svn_rev file, if itdoesn't exist, then try the svn command, if it doesn't exist, then use the $::dateThe problem with this at the moment is that $::date variable is always used with a release. So we should probably replace this with a new variable called ::revision that will be updated just like $::date is now.not a bad idea....As for the svn_rev, we could do it like cvs_date, at least for now. Have it updated regulary with a cron job. I was looking through out the .svn directory and found a file that keeps the current revision embeded in bunch of XML. I would first like to figure out how the file is structured though so it dosn't change with different versions of svn.lol, I just did too, and I sent a msg on how to use it. I don't think they'll ever change the format, it should always be backward compatible.. anyways, if we fail to get the rev number with my code in the other mail, then use the 'svn info' command... btw, the svn tarball created should have the revision number in a svn_rev file created, before the tarring process...About the command line checking of revision. If it is a svn build, then the svn_rev file should be present. I don't think that there would be a need to start a shell and run the svn command. What are others views on this? I started working on this (web and client parts) on my computer. Will commit it when everything will be finished.cool, keep us informed. Thanks, KKRTalso, the revision number is not a date, so watch out for that, it may crash the bug reporting if the DB assumes it should receive a date, not a string... KaKaRoToOn Mon, 29 May 2006 15:15:00 -0400, Sander Hoentjen <[EMAIL PROTECTED]>wrote: > On Tue, 2006-05-30 at 00:19 +1000, Arieh Schneier wrote: >> Aren't you assuming that the user has svn support installed and is >> using the >> svn version? What about all the users that use the packages, or the >> tarball? >> > Yes I am asuming that. In packages and the tarball there should be this > info included._______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
-- KaKaRoTo
log
Description: Binary data
_______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
