Nathaniel Smith schrieb: >>> They are pretty efficient -- most importantly, revisions only describe >>> changes in attributes, and they are stored inside the roster, which is >>> already delta-compressed as a whole. I can't think of any reason why >>> this would be noticeably less efficient than putting the same >>> information in a file. >> Using one (combined instead of three) attribute would _double_ the lines >> in the roster, using a single file only adds one. [Using three would >> quadruple the lines] > > Yeah, it would move a bunch of lines from a delta-compressed, gzipped > file, into the delta-compressed, gzipped roster :-). If you look at > the big picture, not that big a deal.
Ok. Unless rosters are needed a lot in history traversal there is no
slowdown. (I could only guess that there was a slight chance of slowdown
(especially if you have to calculate a sha1sum) and I wanted to avoid
bloating monotone's data structures by a highly specialized
application). If cvs_import uses the same storage method we can well
call it a standard.
Proposal:
attributes "cvs-revision" "1.2"
["cvs-keyword-expansion" "-kb"] (-kk is standard like in CVS?)
But where to store module path and root address? And what about svn and
git information? I was glad to have a single way to handle all external
synchronisation information in one central place.
> To see if I understand you right: I know it is possible to have a svn
> workspace that is a mix of different versions. You want to make it
> possible to import such mixed versions into monotone, and do
> svn_push/svn_pull type operations with such mixed versions?
I did not know about such monstrosities and did not plan to support them
(initially at least).
Being able to track a svn repository and (later) commit to it is
sufficient to my needs. (same goes for git)
Christof
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
