RT 3.0.7pre2

Is now available. COntains a number of fixes and some minor new
features. See the UPGRADING file for instructions about database
updates.

Project “rt.3”, Branch 0 Page 1
Change Log Thu Nov 6 21:12:17 2003

rt.3.D000, C0, jesse, Thu Mar 13 20:43:23 2003, RT: Request Tracker, branch 3.0.
RT: Request Tracker, branch 3.0.

Change Delta  Brief Description

(updates since 3.0.6 release)

 297    243	  Conditionalizing Text::Quoted display, so as to avoid utf8
	  crashes
 299    244	  Merging bugfixes from ourinternet
 300    245	  A bunch of postgres correctness fixes
 301    246	  #2346: Resolving a deprecation warning
  84    247	  #3981: Ticket creation syntax fix
 298    248	  bps #1032: SelfService fixes
 302    249	  #3889: add/del fixes
 303    250	  #3822: Fix for cli bug (Inapropriate use of arrayref)
 305    251	  #3807: CLI example updates
 306    252	  #3907: New default templates for user, ticket and queue
 308    253	  More reference weakening
 307    254	  User objects weren't always destroyed, due to a circular
	  reference
 310    255	  Slightly better debugging on failure to send mail
  94    256	  Deep recursion issue on localization handle; missing language
	  selector
 313    257	  Adding back missing SelectLang
 311    258	  #3566: EditCustomField supports Default for FreeformSingle
 312    259	  Initial Informix port from akso.de
 316    260	  #3765: TicketsSQL is case-sensitive
 317    261	  #3613: searching on NOT LIKE
 318    262	  #3877: don't strip multi-line headers
 319    263	  #3551: Create values corrupted when adding new files
 321    264	  #3993: warn when installing with mod_perl2
 320    265	  #4087: allow non-ISO dates in transaction searches
 322    266	  #3439: custom fields patch
 323    267	  #3855: require Locale::Maketext::Lexicon 0.31
 325    268	  #3856: /REST/1.0/search/tickets should work in UTC
 326    269	  #3827: regression shouldn't drop db
 327    270	  #3801: note when transaction content is ellided
 328    271	  #3751: ParseNewMessageForTicketCcs
 332    272	  #3776: new indices
 329    273	  #3674: autohandler patch
 336    274	  New schema relationships diagram in .dot format
 337    275	  more work on the schema diagram
 330    276	  #3601: SelectRights patch
 331    277	  #3583: set Last Contacted date
 333    278	  #4088: Postgres performance improvements
 335    279	  fix attachment links in base RT
 338    280	  Updating storable dependency, to keep redhat 9 users from
	  hurting themselves
 339    281	  Small fix to ticket searching to cut down on # of joins needed

Request Tracker — Best Practical Solutions – Trouble Ticketing. Free.

?b 五, 2003-11-07 10:15, Jesse Vincent ?g?D?G

Is now available. COntains a number of fixes and some minor new
features. See the UPGRADING file for instructions about database
updates.

WARNING TO ALL POSTGRES USERS!

This line in UPGRADING:
UPDATE groups SET instance = instance::text::int where btrim(instance) <> ‘’;

has completely wrecked our Postgres RT installation, by clearing out the
"Instance" field in the Groups table.

I think Jesse means:
UPDATE groups SET instance = instance1::text::int where btrim(instance) <> ‘’;

but I’m not sure.

Moreover, we did not have a timely backup available.

Do not let it happen to you!

Thanks,
/Autrijus/

signature.asc (187 Bytes)

Is now available. COntains a number of fixes and some minor new
features. See the UPGRADING file for instructions about database
updates.

It would be useful to have an indication of which files/functions have
changed since the last update. I’ve been caught out by new versions of
functions I replace locally one too many times for my liking.

Thanks.

John

It would be useful to have an indication of which files/functions have
changed since the last update. I’ve been caught out by new versions of
functions I replace locally one too many times for my liking.

I agree. The only way to be sure we have all of the enhancements/bug
fixes is to either run diffs on the unmodified files from our current
installation and the unmodified files on the new installation, then make
changes to our local versions or just scrap our local versions and start
over–this however defeats the purpose of having local customized files.

Just a simple list of the files that have changed in each version would
be most helpful.

You just need to look in aegis, there you can look at every change and
see the diffs between the changes.-----Original Message-----
From: bill@daze.net [mailto:bill@daze.net]
Sent: Friday,07 November,2003 19:41
To: rt-devel@lists.fsck.com
Subject: [rt-devel] Re: RT 3.0.7pre2

It would be useful to have an indication of which files/functions have

changed since the last update. I’ve been caught out by new versions
of functions I replace locally one too many times for my liking.

I agree. The only way to be sure we have all of the enhancements/bug
fixes is to either run diffs on the unmodified files from our current
installation and the unmodified files on the new installation, then make
changes to our local versions or just scrap our local versions and
start over–this however defeats the purpose of having local customized
files.

Just a simple list of the files that have changed in each version would
be most helpful.
rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

You just need to look in aegis, there you can look at every change and
see the diffs between the changes.

Who what? Please give a little more detail for those of us (i.e. me) who
haven’t the foggiest how to do that. I’ve not even heard of aegis.

John

J. Sloan wrote:

You just need to look in aegis, there you can look at every change and
see the diffs between the changes.

Who what? Please give a little more detail for those of us (i.e. me) who
haven’t the foggiest how to do that. I’ve not even heard of aegis.
You could track throught rt-commit mailing list.
http://lists.fsck.com/mailman/listinfo/rt-commit
You could track throught rt anon cvs:
http://bestpractical.com/rt/cvs.html
You could track throught aegis web UI:
http://fsck.com/aegis/aegis.cgi?file@proj_menu+project@rt.3.0

You could track throught rt-commit mailing list.
http://lists.fsck.com/mailman/listinfo/rt-commit
You could track throught rt anon cvs:
http://bestpractical.com/rt/cvs.html
You could track throught aegis web UI:
http://fsck.com/aegis/aegis.cgi?file@proj_menu+project@rt.3.0

Thanks for a practical response, Ruslan, but trying to work out ‘which
files/functions have changed from 3.0.6 to 3.0.7’ from that isn’t so easy.

If I could write a report of ‘which files have been modified since
such-and-such a date’ to run across the data that aegis is reporting, that
would give me what I need, but doing this via the web (or via CVS) isn’t
so simple.

It was just a thought. I can always diff the new version files against my
current version files, but it would be nice not to have to.

John

In aegis click on history.
You will see the changes jesse sends you on every bumping to pres (you
will also see the bumping from one version to the other in the
description column).

Samuel-----Original Message-----
From: J. Sloan [mailto:js138@eng.cam.ac.uk]
Sent: Monday,10 November,2003 12:55
To: rt-devel@lists.fsck.com
Subject: Re: [rt-devel] Re: RT 3.0.7pre2

Thanks for a practical response, Ruslan, but trying to work out ‘which
files/functions have changed from 3.0.6 to 3.0.7’ from that isn’t so
easy.

If I could write a report of ‘which files have been modified since
such-and-such a date’ to run across the data that aegis is reporting,
that would give me what I need, but doing this via the web (or via CVS)
isn’t so simple.

It was just a thought. I can always diff the new version files against
my current version files, but it would be nice not to have to.

John

J. Sloan wrote:

You could track throught rt-commit mailing list.
http://lists.fsck.com/mailman/listinfo/rt-commit
You could track throught rt anon cvs:
http://bestpractical.com/rt/cvs.html
You could track throught aegis web UI:
http://fsck.com/aegis/aegis.cgi?file@proj_menu+project@rt.3.0

Thanks for a practical response, Ruslan, but trying to work out ‘which
files/functions have changed from 3.0.6 to 3.0.7’ from that isn’t so easy.

If I could write a report of ‘which files have been modified since
such-and-such a date’ to run across the data that aegis is reporting, that
would give me what I need, but doing this via the web (or via CVS) isn’t
so simple.
I wish such feature too, but now I don’t know any tricks to do such
report. I just do ‘diff -NrubB … …’ on fresh untarred RT tarballs
when I’m going to update. I’ve tried to write script and use BitKeeper
for better merging changes, but my Employer don’t want to know anything
about maintaining RT code so I don’t have time to finish it.

		Good luck. Ruslan.

If you would know how to do date-to-date diff then please write me also :slight_smile:

Thanks for a practical response, Ruslan, but trying to work out ‘which
files/functions have changed from 3.0.6 to 3.0.7’ from that isn’t so easy.

Would generating patches between stable releases suit your needs? That’s
definitely something we can do.

Really, if you’re making deep changes to any third-party product, you
probably want to be dropping those releases into some sort of revision
control system such as cvs, svn, aegis or bitkeeper to track the deltas.

If I could write a report of ‘which files have been modified since
such-and-such a date’ to run across the data that aegis is reporting, that
would give me what I need, but doing this via the web (or via CVS) isn’t
so simple.

cvs diff -D doesn’t do what you want?

It was just a thought. I can always diff the new version files against my
current version files, but it would be nice not to have to.

John


rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

Request Tracker — Best Practical Solutions – Trouble Ticketing. Free.

At Mon, 10 Nov 2003 11:54:30 +0000 (GMT),

Thanks for a practical response, Ruslan, but trying to work out ‘which
files/functions have changed from 3.0.6 to 3.0.7’ from that isn’t so easy.

Another way to do this is:

1- figure out Aegis revision ids for 3.0.6 and 3.0.7

2- :pserver:anoncvs@fsck.com:/raid/tracking-cvs rt.3.0 mirrors all
the aegis changes.

3- use the tagged versions ae<first> ae<second> ass diff points.

If I could write a report of ‘which files have been modified since
such-and-such a date’ to run across the data that aegis is reporting, that
would give me what I need, but doing this via the web (or via CVS) isn’t
so simple.

It’s quite easy in CVS.

Usage: cvs diff [-lR] [-k kopt] [format_options]
[[-r rev1 | -D date1] [-r rev2 | -D date2]] [files…]
-l Local directory only, not recursive
-R Process directories recursively.
-k kopt Specify keyword expansion mode.
-D d1 Diff revision for date against working file.
-D d2 Diff rev1/date1 against date2.
-r rev1 Diff revision for rev1 against working file.
-r rev2 Diff rev1/date1 against rev2.

-R