This was already discussed a long time ago, and we said that it should stay for sure in releases because it's needed by users when they get a bug... and want to report it we need the info. also, as Boris said, it's used in the bug reporting system, we send to the server the last X lines of each of those logs... What I suggested though is to remove the console, and to remove the entry from the status log, so people won't go playing in there and accidently create an empty cmsn_draw_online proc... but this is not a really good idea as we may need people to type stuff there if we're helping them debug...
About cvs_date Boris, you're right, we forgot about it, it's used by the bug reporting system, but if the file doesn't exist, it just returns the date of the release (as in $::date), so we're safe if the file is not there.. but we still need to find a way to get the SVN revision... How about a pre-commit script that would make svn think that cvs_date was modified ? this way, we get the svn_revision (aka. cvs_date) content updated on every commit without generating any additional revision number since the svn_revision file modification will be part of a single atomic commit. If someone knows how to do this, then we need to either find or create the script (maybe ask in #svn but last time I went there, they pissed me off), then ask a feature request to SF in order to get our script added. KaKaRoTo On Sun, 28 May 2006 14:35:18 -0400, Boris Faure (aka billiob) <[EMAIL PROTECTED]> wrote: > and BTW, we use it for the bug report !!! > > Also, what's new about the "cvs_date" issue ? > > 2006/5/28, Sander Hoentjen <[EMAIL PROTECTED]>: >> On Sun, 2006-05-28 at 20:19 +0200, Harry Vennik wrote: >> > Op zondag 28 mei 2006 20:08, schreef Sander Hoentjen: >> > > On Sun, 2006-05-28 at 13:31 +0200, Harry Vennik wrote: >> > > > Hi, >> > > > >> > > > In aMSN there exist some really useful debug utilities, like the >> status- >> > > > and protocol log, the console, etc. Especially for the logs, I >> think now >> > > > we have a branche, we could strip those from the release code. I >> don't >> > > > think of doing that right away, because it might come in handy for >> > > > debugging the RC1, but after that, we may want to strip it, >> because it is >> > > > a memleak, and normal users simply don't need it, and may be >> confused by >> > > > all that garbage when they accidentally hit one of the shortcut >> keys. >> > > > >> > > > What do you think? >> > > >> > > No way we should remove this. I think I used it for 95% of bugfixing >> > >> > Just to be sure you understood it the way I meant... I did not mean >> to remove >> > it completely from amsn, but only from the release: we ourselves need >> it >> > indeed, so we should always have it in amsn-svn. >> > >> I understand what you mean, but suppose we remove it, and someone >> reports a bug to me, most of the time I will want to know either the >> contents of the protocol/status-log or the output of some command in >> console or statuslog. >> >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.3 (GNU/Linux) >> >> iD8DBQBEeewWATrECtEe6c8RAlp9AJ9Kr8Xs1dEcishQSgppywI7c65x/QCcChbT >> +PartqrcI4GIjTkUcMW3yHo= >> =hIoL >> -----END PGP SIGNATURE----- >> >> >> >> >> _______________________________________________ >> Amsn-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/amsn-devel >> >> >> > > -- KaKaRoTo _______________________________________________ Amsn-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amsn-devel
