From owner-svn-src-head@FreeBSD.ORG Sat Jan 3 10:24:14 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F24B106566C; Sat, 3 Jan 2009 10:24:14 +0000 (UTC) (envelope-from rik@inse.ru) Received: from mail.inse.ru (mail.inse.ru [144.206.128.1]) by mx1.freebsd.org (Postfix) with ESMTP id 43D898FC12; Sat, 3 Jan 2009 10:24:14 +0000 (UTC) (envelope-from rik@inse.ru) Received: from www.inse.ru (www.inse.ru [144.206.128.1]) by mail.inse.ru (Postfix) with ESMTPSA id DF98C33C51; Sat, 3 Jan 2009 13:24:12 +0300 (MSK) Message-ID: <495F3CE1.5070800@localhost.inse.ru> Date: Sat, 03 Jan 2009 13:24:33 +0300 From: Roman Kurakin User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Ivan Voras References: <200901011055.n01AtQaN052763@svn.freebsd.org> <495DB15B.8040908@FreeBSD.org> <495DB9B6.4030801@FreeBSD.org> <495DC5AF.3050908@FreeBSD.org> <495E91F8.3010706@FreeBSD.org> <18782.37537.775290.682466@hergotha.csail.mit.edu> <495E9E4B.8030905@FreeBSD.org> <9bbcef730901021955s254b2eb5j24f93127e84fb5ee@mail.gmail.com> <495EFF98.8080701@elischer.org> <9bbcef730901022357l1dc9205ahfa7db117e5aceb2a@mail.gmail.com> In-Reply-To: <9bbcef730901022357l1dc9205ahfa7db117e5aceb2a@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Doug Barton , svn-src-all@freebsd.org, Garrett Wollman , src-committers@freebsd.org, Julian Elischer , svn-src-head@freebsd.org Subject: Re: svn: head/usr.sbin/mergemaster X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 10:24:15 -0000 Ivan Voras wrote: > 2009/1/3 Julian Elischer : > >> Ivan Voras wrote: >> >> >>> And just how can upgrading all the non-user-modified files cause >>> serious damage here (serious=system not bootable, login not possible, >>> etc)? Please explain with examples, since from this and the old >>> current@ thread I only got the impression that "it's baaaad, m'kay". >>> Note that regular users will not upgrade -CURRENT, and most won't even >>> upgrade -STABLE, but will go from one -RELEASE to another. Speaking >>> for myself, mergemaster is a source of constant irritation because it >>> doesn't do auto-upgrades by default, and I'm often tempted to just not >>> start it rather than going through 15 minutes of "q, i, " (my >>> pages is less, thus the "q"). >>> >> Not to mention the times when it seems some large number of files >> get a change in CVS ID or whatever for some reason (and no other change (for >> example someone put a tem change in some subset of >> the rc.d files and then removed it) which seems to happen >> regularly, then you have to go i i i i i i i i i i i i i i i >> for 10 minutes, and then you get into finger-typeahead and >> it then goes right past the one file you DIDN'T want to change >> and you have lost /etc/master.passwd or something. >> > > Yes, I completely forgot to rant about the typeahead problem :) > > On the other hand, this might point to a user-interface problem. Maybe > if instead of constantly requesting user input it could be modified to > work differently - maybe it could generate a machine readable report > of files and autoload it in $EDITOR, in which the user could mark the > files en masse (in some easy way, for example by killing the lines > containing filenames he doesn't want to upgrade, prepending filenames > with "m" for merging, etc), which would then be processed by the > script? But again this would save irritation only if there's a quick > way to specify "just upgrade everything that wasn't changed by the > user". > The better way would be to specify path_to_cvs and do three way merging. >> The -U option goes part way towards this.. How does it know what files >> have not been user modified? Does it store hashes from the last run >> somewhere? >> > > I think that's what /var/db/mergemaster.mtree is used for. >