changeset_collapse_events should not be enabled by default

[Emmanuel Blot]

I've never been a big fan of the changeset_collapse_events feature and get caught once again with this feature.
I really don't think a user or an admin needs to dig into the configuration options to tell Trac should not try to be smart and leave the Subversion repository events as they are originally produced.

Real life example:

I've deleted three developer branches in one of our projects. The three branches share no relationship, but being user branches. I've used the same commit messages for the three deletion commit operation.

Trac messed up with the timeline, considering that the three unrelated branch deletions are part of the same event. It ends up showing:

Changesets [203-201]: Terminates delivered branch

Sometimes, automatic / smart features are not smart enough. I don't see a single reason why these deletion operations should be merged into one.
The fact that the number and content of timeline events a user "generates" depends on whether another user also commits into the same repository within the same timeframe is another argument against this "smart" feature.

Finally, the reverse changeset ordering ([203-201]) looks really un-natural for a Subversion repository.

Please comment on this feature.
It may be useful for some users, but I think it should not be enabled on a new Trac installation. This should be defined as an opt-in admin decision.

[Christian Boos]

Ok ok, you won ;-)

But the [203-201] order is simply a bug.

[Emmanuel Blot]

Replying to cboos:

Ok ok, you won ;-)

I believe we will rather win on support effort ;-)

But the [203-201] order is simply a bug.

I was not sure whether it was made on purpose or not (so that the most recent event appears first)

[Christian Boos]

Done in r6142 (not in trunk yet, so keep open for now).

[Christian Boos]

Now in trunk (r6158).