[cvsnt] Re: Performance problems

[Tony Hoyle]

Nitzan Shaked wrote:
> That's interesting... I would imagine that systems such as CVS would store
> the complete file for versions of logarithmic revisions (say for revisions
> 1, 2, 4, 8, etc.). I would store diffs in the same manner: logarithmicaly
> between complete versions. Then each update on any revision whatsoever would
> take never more than O(log N). (I would also naturally store HEAD since it's
> very common to access it).

That would slow down the commit considerably....  it would also add 
quite a lot to the repository size - You may easily have 10,000 
revisions in a file...

The checkout is optimised - rebuilding the revisions is really not slow 
at all... the cvsnt_2_0_x branch was made a long time ago and hasn't 
suffered any noticable slowdown.

> I believe that for most operations things should be done in O(1) or O(log
> N), never more. In more  "modern" systems tagging, branching etc are O(1).

Revision storage is unreleated to tagging.  One of the advantages of cvs 
is you can make any tag point to any revision on any file, and can 
branch different parts of the repository at different times.  The cost 
of this is the tag is stored at file level - requiring the tag to be 
rewritten to each file.

You can't speed it up without imposing limitations - for example some 
systems only have a single version for the repository so tagging is only 
  possible at repository level.

It's possible to optimise the cvs way of doing it, using tag heirarchies 
for example (which would make rtag instant or at least very fast), but 
it's a fairly major change so is waiting for some other things to be 
done before anything like that goes in.

Tony