monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Packets or Packet I/O no longer works?


From: c . hintze
Subject: Re: [Monotone-devel] Packets or Packet I/O no longer works?
Date: Thu, 12 May 2005 19:33:01 +0200 (CEST)


On 12 Mai, Will Robertson wrote:

(...)

>> mentioned, this is impossible today! So do not use the full dump
>> mechanism, it is senseless.
> 
> That's interesting:  I had stopped using Monotone for a while, and
> hadn't realised they'd intorduced such requirements -- I s'pose
> somewhere around when the NetSync protocol was developed, with it's
> smarter sync methods.

No! First they introduced the Netsync protocol and while dismissing
the old packet oriented sync. So I wrote the scripts to allow me to
get back the packet I/O mechanism to a certain extend.

Afterwards they realize that Monotone's manifest concept was not
strong enough - because it did allow for cycles within the version
graph, there were a lot of problems with the merging of versions.

So they did introduce the concept of revisions. A revision contains a
reference to its associated manifest /and/ the parent revision and the
old manifest. That made it impossible to create version graphs. So
from there on Montone only handle version trees.

That solved a lot of headache concerning merging ... :-)

(...)

>> You could /not/ first importing 2, then 1. But you could import
>> 
>>   a) 1 + 2 + 3
>>   b) 1 + 3
> 
> So, does that mean if you try to import the same revision(s) more
> than once -- i.e if part of an exported packet -- the duplicated
> revisions will be ignored/skipped, and only the new revisions in
> that revision-chain will be imported?

Yes! You may verify this if you use the --debug switch during 'read'.
Already existing elements (revisions, manifests or files) will not
being imported again. Monotone know about them as theirs key is theirs
SHA hash ...

> I mean: when importing, will it fail and stop importing if it hits a
> revision which is already in the repository, thereby not importing
> revisions that come after that duplicated one, or will it attempt to
> apply all the revisions in a packet?

Yes! It will import all elements within your packet while silently
skipping existing ones. It will even import, IIRC, all elements if you
forgot to import a necessary parent revision. But because the revision
tree is broken (due to lacking parent revision) the revisions that
depends on that lacking revision will not being committed. Theirs
files and manifests may already be within your repository - only you
have no access because there is no revision referencing them.

But you probably could access them via plain SQL commands, though ;-)

> The reason why I ask is that there may be times when I have
> forgotten exactly which revisions I've applied to which repository,
> and it would be easier to guess and simply create a packet that will
> have more revisions than I need (on purpose) in order to be sure
> that I've not missed any.

No problem at all - I do it all the time along. But to make a
proposal: you could simply create a comment certificate via

  monotone comment <revision> "comment"

to the revision you dumped last! These comments may be found in the
logging output created via

  monotone log

So you would find where you was ...

(...)

> Thanks again, Clemens.
> 
> Do you mind if I bounce/forward your email and scripts back into the
> mailing-list so others can see them?

Not at all! I should had done it by myself already. Only I did not
dare ... :-}

> Maybe even persuade some C++ developer to reintroduce something
> similar   ;-)

That would really be nice ... perhaps I should ask Nathaniel if it
could be possible to allow importing-without-discarding of revisions
that lack its parent. Not sure if this is possible or even desirable,
though ...


Ciao,
Clemens.

-- 
Clemens Hintze  mailto: c.hintze (at) gmx.net




reply via email to

[Prev in Thread] Current Thread [Next in Thread]