From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Fri, 6 Jun 2014 12:59:11 -0400 To: 9fans@9fans.net Message-ID: <5ae0b0ece962c5704c75a0fb88f2663d@brasstown.quanstro.net> In-Reply-To: <20140606164945.70A57B827@mail.bitblocks.com> References: <1706efdd3a7186cc1c2a54f2aba1c56e@brasstown.quanstro.net> <20140606164945.70A57B827@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] suicide message on vmware Topicbox-Message-UUID: f6d25cd0-ead8-11e9-9d60-3106f5b1d025 > What two databases? the divergent versions of /sys/lib/dist/replica/plan9.db and its log on the sources and 9atom. > Replica respects local changes at the file level. You still > have to do a manual merge if the server version changed as > well. that's what i said, but this is remove vs remote, and replica is unable to deal with this sort of issue. > The bigger issue is that the unit of update needs to be a > *set* of files that take a system from one consistent state to > another. If you update only a subset of files, you may be left > with an inconsistent system. it would be a great feature, but it's unrelated to this failure. i'm part of the way there with the patch system in atom. in theory a few scripts could allow one to add changes as required. unfortunately, it's pretty easy for this to go wrong, even with tools like hg. > For a foolproof update in case of incompatible kernel changes > (and if you're running the same distribution as you pulled > from), you should if one recalls back to the beginning of the 4th edition, the install cd would upgrade things as well as to initial installs. - erik