[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconvenience
From: |
Christof Petig |
Subject: |
Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)) |
Date: |
Thu, 07 Sep 2006 19:55:06 +0200 |
User-agent: |
Thunderbird 1.5.0.5 (X11/20060728) |
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
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)),
Christof Petig <=
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Nathaniel Smith, 2006/09/08
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Christof Petig, 2006/09/08
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Markus Schiltknecht, 2006/09/08
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Daniel Carosone, 2006/09/08
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Daniel Carosone, 2006/09/08
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Markus Schiltknecht, 2006/09/08
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Christof Petig, 2006/09/08
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Markus Schiltknecht, 2006/09/08
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Daniel Carosone, 2006/09/08
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Markus Schiltknecht, 2006/09/09