[viewvc-dev] user alternative when row_limit is exceeded

To help introduce this topic to an audience wider than just me and Michael, I'll refer to Issue 433.  That's a LONG conversation, so at least please read the post which occurred here:
  -- ... Tue Apr 19 12:34:36 -0700 2011 ... --
and includes the drawing by Michael explaining what row_limit is for.

OK, so Issue 433 is headed for closure, with the fix being a warning that row_limit has been exceeded and a suggestion to narrow the query.

There is a problem with narrowing the query when in fact the intent is to see ALL activity on a branch.  Let's say the row_limit is 10K and the branch has 50 commits.  Let's also say that 3 very large commits went into this branch -- addition of an SDK or some such.  Those 3 large commits add up to 9,990 files changed/added.

So, even though we only want to see 50 commits, the row_limit will prevent it because there is no way to stay under the limit using the current query form.  (Remember that the "show at most X changed files per commit" variable does not come into effect until the bulk data has already been limited by row_limit.)  All other fields on the query form will reduce the number of commits, which we don't want, because we want to see all of them.

I started looking at the SQL query itself.  This reveals to me the fact that because this tool was designed back in the days of CVS, the DB is organized by commits as individual file changes.  In other words, one SVN commit with 3,000 files added creates 3,000 commit rows instead of one new row.

I'm not sure if there is a good generic solution here.  The problem is that, by design, the query returns everything and then ViewVC filters it (see Michael's picture in Issue 433 again).  In the current implementation, if VVC limits the number of file changes shown, for example, it KNOWS it is doing so and warns the user.  If the bulk data were reduced, VVC may not know that it is only showing a subset of file changes for a given commit and so would not know to warn the user.

So, I propose a feature that would allow a "log view" via a query.  In other words, checking the box would mean the user gives up the right to see the file changes associated with each commit, and will only see the individual commits (i.e., the log messages).  That will prevent confusion.  The results could also include a link for each individual revision that includes the file changes, so the user could easily pop over to it.

As I said before, the DB is designed for CVS, not SVN.  So how can we pull one row per commit instead of X rows per commit?  I tried "group by commits.revision" without changing any other column, which worked.  From what I can tell, this is not legal SQL syntax in all DBs, but apparently MySQL allows it.  It means you get an arbitrary record back for each commit, but we don't care because we only want to see the log message.

I'd love to hear other ideas, be they better SQL (please!) or different approaches altogether.  (I hit this row_limit a lot, which is why I opened Issue 433 in the first place.)

------------------------------------------------------
http://viewvc.tigris.org/ds/viewMessage.do?dsForumId=4251&dsMessageId=2729612

To unsubscribe from this discussion, e-mail: [[email protected]].