monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] commit, queue, and post design


From: graydon hoare
Subject: [Monotone-devel] commit, queue, and post design
Date: 18 Nov 2003 17:46:11 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

I'm sorry I haven't responded to this yet, it appears I either didn't get
it delivered or my mail queue (which I was reorganizing over the weekend)
ate it. I just found it in gmane..

> The immediate problem is that I have a bunch of packets queued for
> depots that no longer exist. Yes, I know I can delete them with sql,
> and that a command would be easy to add. Another warning sign for me
> is my confusion about not being able to push and unchanged fetched
> tree to my depot, and whether I ought to push the history or not.

ok. these are some concrete problems, but I see they lead to a sense
of irritation with the queue design. 

> Essentially, right now monotone stores "state" about each
> depot. That seems overly complex and error-prone.

well, it stores three bits of state about a network server (note that
this applies to news servers too, and the latter 2 to mail servers):

  - the last major/minor pair of sequence numbers fetched from a given
    server, in the sequence_numbers table

  - the entire list of manifests thought to exist (either by 
    fetching or posting) on a given server, in the netserver_manifests
    table

  - the outgoing packet queue

now, you have a good point that the last one can really be synthesized
at posting time, if you keep enough state to know which set of heads,
and on which branches and URLs, you are interested in posting. I'd
like to at least make notes about these commitments though, if not
actually queue them, so that you don't *have* to do a "monotone post"
from within each working directory, individually.

I don't think we can do away with server-related state altogether,
since some of the servers involved (eg. NNTP servers) are very
dumb. if we were limiting ourselves to depots, yeah, we could just
invent run some kind of setwise synchronization protocol, but we're
not.

> Am I off course here?

not at all, seems a sensible concern. I'm open to something better. if
you can propose a clear set of changes which improves things, I'd love
to hear it.

-graydon





reply via email to

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