monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] mtnplain (aka dumb) revision order, epoch


From: Zbigniew Zagórski
Subject: Re: [Monotone-devel] mtnplain (aka dumb) revision order, epoch
Date: Fri, 23 Jun 2006 13:35:22 +0200
User-agent: Internet Messaging Program (IMP) 3.2.4

Hi,

Nathaniel Smith <address@hidden> wrote:
> On Fri, Jun 23, 2006 at 09:40:31AM +0200, Zbigniew Zagórski wrote:
> > ...
> > Question: How to obtain parent REV(s) from rdata packet without using 'mtn
> read'
> > ?
>
> I thought that someone else already fixed this in the current head of
> the .dumb branch -- the better solution is to make sure that when we
> write things out to the DATA file, we write them in the correct order,
> so that later on they can just be read in directly like they are now.
>
> It's possible that this is in fact fixed, but you're trying to pull
> from a "dumb" repository that was created before this was fixed, so
> the packets are still in the wrong order.
>
> I suggest doing a push into a fresh dumb repository, and then pulling
> from that, and seeing if that fixes the problem.

Unfortunately, ... you're right. I followed probably outdated Riccardo's e-mail
in which he written reordering is not ready :/. It works. Now I see that my
effort was so stupid :/. Ach ...
And yes I must have got some old 'dumb' repository which i overlooked. Sorry for
bugging with this.

> > Second problem.
> > ....
> What needs to be done to support them in mtn-dumb is:
>   1) create a new packet type for epochs
>   2) for each branch in the db, add this packet to the merkle trie
>      being synced.  Make sure to put these packets as early as
>      possible; just like revisions should come before certs, epochs
>      should come before revisions, and even before files.
>
> ...
> "mtn read" for locks on the database.)  (This is exactly how an
> in-monotone implementation of epoch packets would do, except with
> fewer caveats.)
>

Now after reading a little i think that 2) is perfect solution. I'll do
it so.
When it'll be finished, then 'mtnplain' will be quite complete solution.

> > PS. I think that 'plain' is better name for 'dumb'. And my proposition is
> > to name the tool is 'mtnplain'.
>
> Hmm, I'm not sure.  There are two problems:
>   1) "dumb" is sort of a stupid name, but it has a lot of history
>      behind it :-).  The standard word for using HTTP/FTP/etc. as a
>      VCS transport has been "dumb" for many years now, and it's been
>      used by a lot of different people (starting with the Arch
>      people).
>   2) "plain" is very ambiguous.  For instance, surely "plain" monotone
>      is what you get when you go to
>         http://venge.net/monotone/downloads/
>      right?

Hmmm, for now lets leave it to others. In fact i don't care about name.

> ...
> Want to send me a key, so you can use the venge.net server to
> distribute your work?

You've already added it some time ago, but from then i went sleep (in a mean of
development) and didn't pushed anything.
I'll push these changes ASAISFTFOS (as soon as.i find some free time for open
source).

--
Best regards, Zbyszek




reply via email to

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