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
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.
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.
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.
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).
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.
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
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.
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.
