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..
KKRT
On Mon, 29 May 2006 22:45:30 -0400, Youness Alaoui
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
it
doesn't exist, then try the svn command, if it doesn't exist, then use
the
$::date
The 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,
KKRT
also, 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...
KaKaRoTo
On Mon, 29 May 2006 15:15:00 -0400, Sander Hoentjen
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
