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

[Christof Petig]

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.

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]

> 
>> I wrote a command to retrieve the whole sync information per revision.
> 
> The manifest includes all file attributes; you can simply read them
> all off of there.

I see (mtn automate get_manifest_of).

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

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

   Christof

signature.asc
Description: OpenPGP digital signature