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

[Nathaniel Smith]

On Thu, Sep 07, 2006 at 07:55:06PM +0200, Christof Petig wrote:
> 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?)

Should be either "cvs:revision" or "mtn:cvs-revision", following the
"namespace:name" convention.  It looks like cvs2svn uses
"cvs2svn:cvs-revnum", which doesn't strike me as an obvious and
elegant example to follow...

> 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.

One option is an attr on the root directory (the one called,
in manifests and revisions, the empty string); another is in a cert.

> > 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)

I think you only need to worry about elaborate delta coding stuff for
svn if you are planning to support such monstrosities.  Otherwise, for
both git and svn, all you need to store for each revision is a single
short string, which again could be in either a cert or a root attr.
It's only CVS where stating version information for a tree takes
kilobytes and kilobytes worth of space.

-- Nathaniel

-- 
Eternity is very long, especially towards the end.
  -- Woody Allen