monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Re: branch review for net.venge.monotone.multihead


From: Nathaniel Smith
Subject: Re: [Monotone-devel] Re: branch review for net.venge.monotone.multihead
Date: Wed, 12 Jul 2006 21:30:14 -0700
User-agent: Mutt/1.5.11+cvs20060403

On Tue, Jul 11, 2006 at 06:40:54PM -0700, Zack Weinberg wrote:
> I rewrote CMD(merge) again according to your suggestions; please have a 
> look?

I made a few small tweaks (message tweaks, adding a safe_insert,
tweaking the test to document the real old algorithm).  Looks good!

Merged to mainline.

> I was thinking about using commit date as a further heuristic, i.e.
> when we have two LCAs neither of which is an ancestor of the other,
> merge the newest one first; furthermore, when we have three or more
> heads with the same LCA, merge the newest two first.

I don't have any really clear picture of whether this heuristic would
help or hurt.  My general bias is towards simple and predictable
systems that involve minimal cognitive clutter (you can just _hear_ my
math background seeping through), so this doesn't excite me too much
but, you know, hey, if you can make it work :-).

I think I've said before that my guess is that the basic topological
heuristic is the 90% benefit/10% work point, though.

> However, it
> seems like a huge pain to get from a revision_id to its commit date,
> and in fact I'm not sure the date cert is guaranteed to exist.

These are both true.

(In addition to the mechanisms mentioned elsewhere on the thread, a
simple interrupted netsync can leave one with a revision but not all
of its certs.)

-- Nathaniel

-- 
"The problem...is that sets have a very limited range of
activities -- they can't carry pianos, for example, nor drink
beer."




reply via email to

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