Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?))

[Christof Petig]

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