Archiving tickets, milestones, and metadata

[Florian Berger]

Over time, a busy Trac instance (think agile) accumulates a lot of tickets, milestones, and
associated metadata such as components or versions.

Especially when the need arises to search passed milestones or completed tickets, this may lead to
very long result lists including very old data. I may want to search 1 year back, but not 8 years.

Also, the "new ticket" form somewhat degrades in usability when there are components which are no
longer being used, or versions that are long released.

Simply deleting old tickets, milestones etc. is not an option if one wants to preserve project history.

So, I am thinking about strategies for archiving. That means I want to be able to easily access and
search old content (so a pure headless db backup would not suffice), but remove it from the running
instance without interrupting current data (so backing up at some point and setting up a fresh
environment is not an option).

The best plan I've come up with so far is to set up a second Trac instance, and then using some SQL
trickery to move the obsolete data to that instance, removing it from the current one. That way,
ticket numbers etc. should be preserved, while the original instance should continue to operate as
usual, i.e. incrementing ticket numbers correctly.

I haven't actually tried it, but looking at the db it seems certainly possible.

I've done a brief web search on the topic, but have not found Trac-specific resources.

Does anyone else do archiving of Trac tickets etc.?

If so, using which procedure?

Does mine sound doable? Anything I am overlooking?

Is there any documentation I am not aware of?


Thanks!

Florian

[Florian Berger]

On 19.11.23 19:31, Florian Berger wrote:
> Over time, a busy Trac instance (think agile) accumulates a lot of tickets, milestones, and
> associated metadata such as components or versions.

> [...]

>
> So, I am thinking about strategies for archiving. That means I want to be able to easily access and

> search old content [...], but remove it from the running
> instance without interrupting current data [...].

>
> The best plan I've come up with so far is to set up a second Trac instance, and then using some SQL
> trickery to move the obsolete data to that instance, removing it from the current one. That way,
> ticket numbers etc. should be preserved, while the original instance should continue to operate as
> usual, i.e. incrementing ticket numbers correctly.

As this has not attracted attention, and I want to start the work next week, again my question: Does
anyone, or has anyone ever done, regular ticket/milestone/component/... cleanup? If so, using which
strategy?

My Trac instance has been running since 2017, has 906 tickets, 440 milestones, 18 components, and 11
versions. I am sure there must be way larger instances, where e.g. ticket and milestone searches
must become progressively confusing, and where stale compoments clutter ticket creation.

Any reports and experiences are welcome.

Thanks,

Florian

[Clemens Feige]

Hello Florian

I answer your question about archiving TRAC but let me share some thoughts:

First, I do not know your particular setup, but I would not be too much
worried about performance. According to my experience TRAC is very well
able to run with thousands of tickets etc.

Second, I am not sure what is bothering you with that many tickets,
milestones and so on. Maybe it is that some lists and
drop-down-selectors etc. become rather long.
Here is just an idea: A totally different approach would be just to
modify the output on certain locations, but keep the TRAC database as it
is. For example you could use some JavaScript to shorten some drop-down
selectors. Maybe you could modify some TRAC templates and Python code to
hide unwanted output. This approach would be totally reversible and
would ensure full data integrity. Just an idea ...

Clemens