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.
Thanks for replying Tony. And I can by no means compare our knowledge of CVS internal. Still allow me to argue the following: > 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... First of all it is arguable whether commit or update should be faster, if there's a tradeoff. I for one think that update is a much more frequent operation. And with the BUILD tag method specified here I guess I would prefer an update which is fast not only on the HEAD. But that I suppose should be a "survey" of what the most common operations are. Secondly -- I would increase repository size, but not by much at all! I propose a hierarchical, or logarithmic, storage of the full versions. So the difference in the number of times the full version would be saved between 10,000 revisions and 20,000 is... 1. Not terrible at all. Finally -- I don't agree that I would slow commit considerably. If the diffs are stored hierarchly (with a limit on depth) then a new commit only needs to store the diff from one version, which by itself is a diff from no more than (depth) other versions, but given that a commit is an "MMI action" -- there is a user on the other side, and commits are not done on hundreds of files usuaully, the small time per file will not be noticed by the user who is also waiting for TCP sockets, the GUI to update, etc. In percentage it would be less than the time saved on updating. I'm guessing. :-) > 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. Tagging at a file level is important, at least for me. But isn't there a way to do so without writing to each file? I suppose you could store the tags in a linked list in the file, so that adding a tag to the file won't have to re-write the whole file. Or: could be stored in a different file altogether (still have to see how this affects 'update by tag' for files without that tag). As an idea: the client knows which revisions of which files it is currently holding. Just send that information to the server (recurse over all client-side directories) and call that a tag. Put in a file of it's own. Scalable, and quite fast. > 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. What's the idea behind hierarchical tags? And slightly related: is there a place I can read about ,v structure? ... and once again: sorry if I'm begin a little presumptious -- thought I'd take advantage of the fact you took the time to reply :-) Cheers, Nitzan