From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: The VC to-do list Date: Fri, 02 May 2008 22:59:59 -0400 Message-ID: References: <20080502211447.207E09F051D@snark.thyrsus.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1209784006 6778 80.91.229.12 (3 May 2008 03:06:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 3 May 2008 03:06:46 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Eric S. Raymond" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 03 05:07:19 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Js85m-00073I-T6 for ged-emacs-devel@m.gmane.org; Sat, 03 May 2008 05:07:19 +0200 Original-Received: from localhost ([127.0.0.1]:52512 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Js855-00020k-MU for ged-emacs-devel@m.gmane.org; Fri, 02 May 2008 23:06:35 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Js850-0001y5-Ij for emacs-devel@gnu.org; Fri, 02 May 2008 23:06:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Js84z-0001wt-QW for emacs-devel@gnu.org; Fri, 02 May 2008 23:06:30 -0400 Original-Received: from [199.232.76.173] (port=42985 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Js84z-0001wi-Jh for emacs-devel@gnu.org; Fri, 02 May 2008 23:06:29 -0400 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182] helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Js84z-0007ZW-0c for emacs-devel@gnu.org; Fri, 02 May 2008 23:06:29 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoICAItzG0jO+JghdGdsb2JhbACBU5AVASeZVQ X-IronPort-AV: E=Sophos;i="4.27,429,1204520400"; d="scan'208";a="19846101" Original-Received: from smtp.pppoe.ca (HELO smtp.teksavvy.com) ([65.39.196.238]) by ironport2-out.teksavvy.com with ESMTP; 02 May 2008 23:06:25 -0400 Original-Received: from ceviche.home ([206.248.152.33]) by smtp.teksavvy.com (Internet Mail Server v1.0) with ESMTP id JIJ42925 for ; Fri, 02 May 2008 23:06:25 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 71527705C4; Fri, 2 May 2008 22:59:59 -0400 (EDT) In-Reply-To: <20080502211447.207E09F051D@snark.thyrsus.com> (Eric S. Raymond's message of "Fri, 2 May 2008 17:14:47 -0400 (EDT)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:96362 Archived-At: > (6) ;; - figure out what to do with conflicts that are not caused by the > ;; file contents, but by metadata or other causes. > Example, please? File A gets renamed to B in one branch and to C in another and you merge the two branches. Or you locally add file FOO and then pull a change that also adds a new file FOO, ... > (8) ;; - vc-diff should be able to show the diff for all files in a > ;; changeset, especially for VC systems that have per repository > ;; version numbers. log-view should take advantage of this. > I thought we were already doing this, at least insofar as I understand > the specification here. What behavior is missing? Do a log on foo.el, then for one of the changes, try to get the full diff: that won't work, it'll only give you the foo.el part of that changeset, not the changes made to other files. > (10) ;; - make it easier to write logs. Maybe C-x 4 a should add to the log > ;; buffer, if one is present, instead of adding to the ChangeLog. > No. The real problem here is that the combination of Changelogs and > a fileset-oriented VCS's revision history is intrinsically duplicative > and bogus, and Changelogs should be shot through the head as soon as > we migrate off CVS. I don't understand this "No" since you follow it by 4 lines of text that seem 100% in agreement with point (10). Looks like just mentioning "ChangeLog" hits a nerve, even when the mention is going in the direction you want. > (14) ;; - a way to do repository wide log (instead of just per > ;; file/fileset) is needed. Doing it per directory might be enough... > See the notes on the dispatcher and the null-fileset problem above. > This really has nothing to do with version-control per se, it would be > a UI issue with the front-end design for *anything* that has (a) > per-file, (b) per-directory, and (c) global operations. How can the > user specify these contexts in an intuitive and consistent way? In PCL-CVS, I used different user commands with different key-bindings for global operations. Note that I only provided global operations for "update" and "refresh status", so maybe it's not that relevant. > I've already explained on-list why I don't intend to put any energy > into this until the rest of the todo list is clear. I (a) don't think > it's important, and (b) do fear the code bloat it seems likely to bring. I disagree. I think it may require a lot of changes, but no code bloat at all. It's just a matter of being careful of where we decide which backend to use. Currently we make this decision over-and-over again at many different places. And if one of those places makes a different decision, we have a bug. So dealing with multiple backends is mostly a matter of deciding which backend to use once and forall and then properly preserving this info, which will eliminate the bugs. Note that we've already seen such bugs for single-backend situations because one of the files selected happens to be managed by no backend, so we get bugs like "can't load vc-nil". This is not some hypothetical problem. The fact that it will correctly handle multi-backend situations is just the result of doing things right. > (22) ;; - backends that care about vc-stay-local should try to take it into > ;; account for vc-dir. Is this likely to be useful??? > I don't really understand stay-local or the hacks around it. I wish > somebody else would take this one. I think stay-local should ultimately go. It will be replaced by a distinction between "status" and "pull --dry-run". Another important thing: merge all the status-like backend operations. We should remove dir-status, state, dir-state, and dir-status-files, and replace them with just `status' which takes a fileset and a continuation (like dir-status) and returns a buffer in which the process(es) are run (or nil if it worked synchronously). Hopefully we can define the old 4 operations in term of this one. Stefan