[Top][All Lists]
[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