Add option to filter latest N changesets instead of date filter, to avoid empty views
I'd like an alternative to date filters, so that views will not be empty by default if I look at a branch or a repo that has been is inactive for more than 3 months. I'd rather have a setting "Show 100(+/-) changesets". Sometimes you want to look at a certain time period, but I think more commonly you just want to limit the sheer amount of data being displayed?
This might need an addition to the "cm find" query language, to specify "the N latest changesets" etc, similar to SQL "SELECT TOP(N) ... ORDER BY ..."?
Also, an empty Branch Explorer displays "No data found, server did not return any data for specified filter". This indication should be used in all other filtered views too (Changesets, Branches etc).
Göran Wallgren
shared this idea
-
Walter Nicholls
commented
Same problem in the new Web UI. Although at least there the date filter is in clear view at the top of the page, so the reason is obvious,
In the GUI, it is often quite baffling as to what has gone wrong.
-
Walter Nicholls
commented
"While it is certainly comfortable for repos or branches you don't use often... well, by definition you don't use it often, so the current restriction won't hit you often either... so probably it is not a key thing to implement."
I'm going to call you out on that. I work on many different projects, some of which are not touched for months. I mostly work on projects alone, so recent history on a project is in my head: I *know* what I've been doing.
It's the older projects that aren't touched often, for which I most need to know what the activity on the project has been.One example. Businesses operate on a monthly cycle, so say a problem shows up (in a mature system) on the 1st of May during the billing process. Programming effort to resolve the issue (or perhaps add some features) is done during the month - say on the 10th. It then has to go through testing, documentation, training etc. One way or another this finally gets installed in live system mid-June. Then on 1st July a problem shows up. A programmer is sent back to look at the source to see what might be the cause.. now the change set view is empty, because the last checkin was over 1 month ago.
This is an old uservoice post, but I'm sure I've mention t his
-
Yep, the thing is that we handle the following database backends:
* SQL Server
* SQL Server CE
* Firebird
* SQLite
* MySQL
* Postgres
* OracleAnd in each of them the TOP clause is different and performs differently too.
That's why we've been reluctant to add this feature in the past.
While it is certainly comfortable for repos or branches you don't use often... well, by definition you don't use it often, so the current restriction won't hit you often either... so probably it is not a key thing to implement.
