From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,a326ac15995ef20e
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!postnews.google.com!i3g2000cwc.googlegroups.com!not-for-mail
From: njs@pobox.com
Newsgroups: comp.lang.ada
Subject: Re: ANNOUNCE: Debian build scripts on a public Monotone server
Date: 29 Sep 2006 17:03:02 -0700
Organization: http://groups.google.com
Message-ID: <1159574582.667087.127500@i3g2000cwc.googlegroups.com>
References: <871wpzd7js.fsf@ludovic-brenta.org>
   <1159259938.13504.19.camel@localhost>
   <1159263129.848672.286190@m7g2000cwm.googlegroups.com>
   <1159267398.13504.35.camel@localhost>
   <1159433540.824912.193400@i3g2000cwc.googlegroups.com>
   <sa4irj7w91x.fsf@margay.local>
NNTP-Posting-Host: 66.159.194.130
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: posting.google.com 1159574588 9445 127.0.0.1 (30 Sep 2006 00:03:08
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Sat, 30 Sep 2006 00:03:08 +0000 (UTC)
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.0.4) Gecko/20060406 Firefox/1.5.0.4
 (Debian-1.5.dfsg+1.5.0.4-1),gzip(gfe),gzip(gfe)
Complaints-To: groups-abuse@google.com
Injection-Info: i3g2000cwc.googlegroups.com; posting-host=66.159.194.130;
   posting-account=KBzYMg0AAADyIBsProrIrDf2NIzhUvb8
Xref: g2news2.google.com comp.lang.ada:6807
Date: 2006-09-29T17:03:02-07:00
List-Id: <comp.lang.ada>

Brian May wrote:
> Hmmm. Could get interesting. Consider the case of a user not using a
> given computer account for several years, and suddenly they wake up
> and do a sync operation.
>
> "Where did this fork from??? Everything in it is obsolete!"
>
> Just curious: Is it possible to somehow terminate a dead tree head
> without merging it?

You could merge it, and override the merge algorithm to say "resolve
all conflicts in my favor".   Basically you end up with a revision
graph that looks like:

     a   old
      \ /
       a (again)

We don't quite have a convenient UI for that right now, but we're
working on an overhaul of the UI for merging in general, and one of the
things that should fall out is a natural way of expressing this.  In
general merging is much better than simply marking a head as dead,
because it provides a path forward for any existing work that might be
based off of that head.  (I.e., maybe it wasn't a head at all, but
because it's a distributed system you didn't know that.)

In general, I am biased much more towards worrying about the data loss
scenario, than the accidental data survival scenario :-).  Bits, for
all their infinite replicability, are tenuous, fragile things, and it's
a lot easier to ignore something you've preserved, then to use
something you've lost.  So our first priority is making data immortal;
overpopulation is an easier problem :-).  I actually find the scenario
of some bits being lost for years, then accidentally promiscuously
replicated and saved for posterity to be heart-warming :-).

That's just me, of course, and overall, yeah, there are ways that kind
of scenario can be dealt with.

-- Nathaniel