RE: Re: [viewvc-dev] user alternative when row_limit is exceeded

> On 05/03/2011 05:46 PM, David Carson wrote:
> > 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.
> 
> David, this observation is, in my opinion, the single most important one you
> could have made.  Subversion support in the commits database is a bolt-on --
> a contributor's quick work to make Subversion commits searchable while still
> maintaining DB schema compatibility with the old CVS-centric Bonsai product
> -- and that results in a number of interesting side effects:
> 
>   - no commit history for directories
>   - excess metadata storage
>   - insufficient handling of copies
>   - zero support for branches/tags
>   - etc.
> 
> There is zero version-control-system abstraction in the cvsdb code such as
> you might find in the general "vclib" submodule.
> 
> Is the solution here to design a new schema that's suitable for Subversion
> and can solve as many of these shortcomings as possible?
> 

I would certainly agree that this is the correct long-term solution.  Are you suggesting there be multiple schemas or just a new schema replacing the old one, which would better suit SVN but could also handle CVS?

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

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