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

[Nathaniel Smith]

On Mon, Aug 28, 2006 at 11:46:18AM +0200, Christof Petig wrote:
> Nathaniel Smith schrieb:
> > On Sun, Aug 27, 2006 at 12:07:33AM +0200, Christof Petig wrote:
> >> The main reason for me to use a special file format is to have the
> >> information in one place (which also applies to attributes) and to base
> >> some logic upon whether this file was changed since the last revision.
> >>
> >> Yeah file attributes appeal to me, too (on second thought) (but that
> >> does not solve the "push can't change this information" problem).
> >>
> >> Do file attributes scale well enough? (since they are part of the
> >> revision information, I would need three per file ...)
> > 
> > What do you use the 3 for?
> 
> rcs-revision, keyword expansion, and possibly
> unchanged/original_id/whatever_you_call_it.

Nod.

> We might put all three into one attribute. And I would need to store
> server address and module and directory structure somewhere.
> 
> I was glad to have all of this in one place (one single file).
> 
> > 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.

> >> And I also had svn on my mind when I designed that feature.
> > 
> > Not sure what you mean here.  Surely for svn synchronization, you only
> > need to know svn's whole-repo version number, plus where in the svn
> > namespace this mtn branch belongs?  (I.e., "this mtn revision
> > corresponds to the /branches/foo/ subtree of svn revision 1234".)
> 
> That's right. Svn would only need a single number ... unless you start
> to take changed files into account (IIRC svn stores an unchanged copy of
> each file in the workspace). So I designed a mechanism which would work
> the same for the simple case (one number) and the complex case (a number
> per file).

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?

> >> My feeling is that I follow my chosen way further and see where I get
> >> to. Changing the storage form is not that difficult.
> > 
> > Nod.
> 
> mtn_cvs pull is finished and the tests are ok, I'm working on push
> functionality. (Porting the program from linking to monotone to using
> the automate interface was a good step but there is still some code
> which directly uses monotone internals - e.g. rosters, certs)

Cool.

-- Nathaniel

-- 
So let us espouse a less contested notion of truth and falsehood, even
if it is philosophically debatable (if we listen to philosophers, we
must debate everything, and there would be no end to the discussion).
  -- Serendipities, Umberto Eco