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