Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
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